I can't unlock my extern device. I have the followed crah report as I try to enter my password. The device was once used on a microsoft computer, idk if it's linked somehow. Does anyone know what to do ? Translated Report (Full Report Below) Process: WD Drive Unlock [1303] Path: /Volumes/VOLUME/WD Drive Unlock.app/Contents/MacOS/WD Drive Unlock Identifier: com.westerndigital.WDDriveUnlock Version: 2.0.0.45 (2.0.0.45) Code Type: X86-64 (Translated) Parent Process: launchd [1] User ID: 501 Date/Time: 2024-11-23 11:49:58.9117 +0100 OS Version: macOS 14.3.1 (23D60) Report Version: 12 Anonymous UUID: 867E7C29-A5F7-9384-C84A-E8DD7E31CF51 Time Awake Since Boot: 270 seconds System Integrity Protection: enabled Notes: PC register does not match crashing frame (0x0 vs 0x7FF80BA0BF60) Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [1303] VM Region Info: 0 is not in any region. Bytes before following region: 4294967296 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 100000000-100011000 [ 68K] r-x/rwx SM=COW ... Drive Unlock Error Formulating Crash Report: PC register does not match crashing frame (0x0 vs 0x7FF80BA0BF60)

We are reaching out to discuss an issue we have encountered with our app's activation process while running in the background. Currently, we are employing an iBeacon-based activation scheme, but we have noticed that after the app is activated, it is unable to receive UUID data from the scan-response while in the background. We are considering the possibility of embedding the UUID data into the advertisement so that the app can receive it once activated by the iBeacon. Additionally, we are preparing to use both Core Bluetooth’s “Performing Long-Term Actions in the Background” feature and the iBeacon scheme simultaneously for app activation. We would like to know if these two methods can coexist without any mutual interference. Currently, we are utilizing a method of updating the beacon advertisement after connection and disconnection to enhance the app's activation capability. However, in some scenarios where the signal is weak, the app does not detect the vehicle after being activated and will not be reactivated by the same beacon after going into sleep mode. Our current approach is to update the beacon advertisement every 10 seconds to improve this capability. We have outlined our proposed changes and would appreciate your confirmation on whether they could lead to better optimization: 1.Embedding the UUID from the scan-response into the advertisement. 2.Updating the iBeacon advertisement content every 10 seconds. 3. Simultaneously using Core Bluetooth's "Performing Long-Term Actions in the Background" feature along with the iBeacon scheme for app activation. Additionally, we would like to know if these changes could potentially cause any other issues. Thank you for your assistance, and I look forward to your insights on this matter.

target to mac，it seems not to be able to tried on ios，“import homekit”，but didnt find my device-homepod mini，which is new one with upgraded version

I have two Dockkit anomolies to report. Hoping a DTS person has seen these and/or can comment. First, my setup: I am controlling the accessory by making repeated calls to set the angular velocity. And the first thing I do is make a call dockManager.setSystemTrackingEnabled(false) because I'm doing my own tracking. I would note that I tried calling track() on my own, with a bunch of observation rectangles (or even just one) but it didn't work well, even though I was calling at the correct rate. Instead, I measure the angular deviation to where I wish my camera was pointed, and set the angular velocity proportional to the error. First issue: in normal operation, the green tracking light is on, on the hardware (the Instaflow Pro 360 motorized dock). Squeezing the trigger toggles the green light on/off; only when the light is on will the dock accept my calls to set the angular velocity. Fine. But sometimes squeezing the trigger won't reactivate the green light. In this case, the ONLY thing that seems to work is switching to the Instaflow Pro 360 app, and activating the camera. Immediately the green light turns on, and I'm good (and can return to my own app, with the green light still on). So what hidden API call does Instaflow have, that I don't that can make this happen? Sure, it's their own app, but I imagine they don't have access to calls I don't, so how does their app manage to get the green light back on? It doesn't always happen. Would love to know how to snap out of this. Second issue: While I usually use rectangle from running the vision system to guide my camera position, sometimes I left the user directly control the angular "yaw" velocity (rotation around the vertical axis) directly (by issuing commands over the network). Sometimes, when the user sets a non-zero velocity, when they set a zero velocity a short time later, the camera doesn't immedately respond and stop. (It's not a network issue. I can verify the API sends a call to set the angular velocity to zero, and the camera keeps rotating for a good fraction of a second.) Most times the camera stops immediately, but sometimes it doesn't. Oddly, I never see this issue when letting the user set the angular velocity in the "pitch up/down" axis. Just the yaw axis. Anybody else seen this? I feel like it wasn't a problem till I got to iOS18 but I won't swear to it. Any advice/assistance/discussion greatly appreciated.

After update to MacOS Sonoma 14.7.1 (23H222) my external monitor immediately started to flicker (noticeable even on 100Hz refresh rate). During the update the external monitor was connected to the laptop. Flickering persist on personal Windows laptop too. Tried to connect/disconnect current cables, flickering persists. Tried to switch to another cable Display port to HDMI, flickering persists. Monitor now is basically unusable, the update damaged it.

I recently updated both my phones iPhone 14 Pro Max and iPhone 16 Pro Max on iOS 18.1, and after update when I open camera and go to SLO-MO the screen starts flickering, even though after recoding when I play the video. Video is playing the same with the flickering screen. is it iOS update issue or something else.

Hi, I made an earier post about this and unfortunately can’t locate it so I’m doing a new one with screenshots. After I click on the Done button, I can briefly see it already residing on my phone. Please see the attached photos. Is this normal? I have a iPhone 15 ProMax. Thank you, D

As of iOS 18.1 being released we are having issues with our users experiencing issues with our app that relies on strobing the device torch. We have narrowed this down to being caused on devices with adaptive true-tone flash and have submitted a radar: FB15787160. The issue seems to be caused by ambient light levels. If run in a dark room, the torch strobes exactly as effectively as in previous iOS versions, if run in a light room, or outdoors, or near a window, the strobe will run for ~1s and then the torch will get stuck on for half a second or so (less frequently it gets stuck off) and then it will strobe again for ~1s and this behaviour repeats indefinitely. If we go to a darker environment, and background and then foreground the app (this is required) the issue is resolved, until moving to an area with higher ambient light levels again. We have done a lot of debugging, and also discovered that turning off "Auto-Brightness" from Settings -> Accessibility -> Display & Text Size resolves the issue. We have also viewed logs from Console.app at the time of the issue occurring and it seems to be that there are quite sporadic ambient light level readings at the time at which the issue occurs. The light readings transition from ~100 Lux to ~8000 Lux at the point that the issue starts occurring (seemingly caused by the rear sensor being affected by the torch). With "Auto-Brightness" turned off, it seems these readings stay at lower levels. This is rendering the primary use case of our app essentially useless, would be great to get to the bottom of it! We can't even really detect it in-app as I believe using SensorKit is restricted to research applications and requires a review process with Apple before accessing? Edit: It's worth noting this is also affecting other apps with strobe functionality in the exact same way

Hello Apple Support Team, I'm experiencing an issue with my iPhone 15 Pro. Although the battery health shows 100%, the phone shuts down unexpectedly at various charge levels, sometimes as high as 70% or even 40%. My iPhone is currently on iOS 18.2 beta 2, but this issue began with iOS 18.2 beta 1. I’ve tried multiple troubleshooting steps: Formatted the iPhone Performed a force reboot Upgraded and then downgraded the software Unfortunately, none of these solutions resolved the problem. The panic report doesn’t appear to show anything conclusive. I'm attaching the panic report for further analysis, as I’m unsure if this is a software bug related to the beta or a hardware issue. Thank you for your assistance.

I have connected my Apple TV 4k to Sony Bravia TV using an HDMI Cable. Sometimes, all of a sudden, the screen starts blinking and Screen resolution (1080p) is displayed continuously. What is happening? I have tried different HDMI Cables, same result.

Hi everyone, I’m experiencing a frustrating issue with my iPhone 14 Plus after updating to iOS 18. Ever since the update, the rear camera has become almost completely unusable, while the front camera still works fine. Here’s a breakdown of the problems: Camera app shows a black screen - When I open the Camera app and switch to the rear camera, the screen is just black with no visibility of any objects or scenes. Limited photo capability - I can only take photos using the 0.5x zoom, and even then, the results are abnormal. Every photo taken with the rear camera has a strange green light at the lower bottom, just like the one in the attached photo. Unavailable features - All rear camera features, like video, panorama, portrait, and cinematic mode, don’t work at all. It’s like the camera is only partially functional. “Clips” app works normally - Interestingly, the “Clips” app is still able to take videos with the rear camera, so it seems like the camera hardware itself is fine. This issue seems specific to the Camera app and any functions within it. I waited for two updates—iOS 18.0.1 and 18.1—hoping Apple would resolve this, but unfortunately, these updates haven’t fixed the issue. I even went to the Apple Service Centre, but since my device is out of warranty, they told me that if I want it fixed, I’d have to pay MYR905 (around USD$200+) to replace the rear camera. They diagnosed it as a hardware issue, but I can’t help but feel it’s related to the iOS 18 update, as the problem started right after updating. I’ve always taken good care of my device, so this doesn’t seem to be due to any physical damage or misuse on my part. Is anyone else experiencing something similar? Could this be a software bug in iOS 18? Any help or insights would be greatly appreciated. Thanks!

iPadOS behavior with secondary displays is inconsistent. Firstly, Apple has not published what is the lower limit for supporting the extended display in non-mirrored mode. In iPadOS 16.1 beta even lower resolutions were supported, but it looks like the monitor must now support at least Full HD (1920x1080). Otherwise there will only be the possibility for mirroring the iPad screen and the Arrangement menu will not be visible in iPadOS Settings. This is the case with all iPadOS versions from 16.1 to 18.2 (beta). Secondly, even on monitors that do support Full HD or better resolution, iPadOS may still choose to only support mirroring with a strange resolution such as 1280x1024 even though 1920x1080 would be available. I have tested with various iPad Pro 11" models from gen 1 to gen 4, various USB-C adapters, and cables. Extended display does work properly with certain monitors, but the above issues still exist on others. I have filed feedbacks FB13576000 (Feb '24) and FB11467189 (Sep '22) on this bug. On the Support Community Forums there are a lot of users mentioning the same issues.

We have a USB dongle that would like to connect to the iPhone for power (using USB-C). Since it is not MFi, we will then use bluetooth for communication between the dongle and an app. When doing bluetooth pairing between the dongle and iPhone, it would be ideal to only see the dongle that is plugged into the iPhone listed in the app. This is to avoid connecting to other dongles that may be in the area. We think this could be possible using USB descriptors. We assume the iPhone can read the USB descriptors for non-MFi dongles. Our question is, can our app see the USB-descriptors of the dongle? Is iOS able to pass that info to the app? Then, we could have a unique USB descriptor for each dongle and the app could only list bluetooth devices with that descriptor (effectively filtering out any other dongles in the area). Any help and/or feedback is greatly appreciated :)

I don't know what else to say other than the 18.0.1 update did not resolve my camera issue on my iPhone 16 pro. Still crashes a few times a week and I have to restart my phone every time. I heavily use my camera as I have 2 toddlers. C'mon, Apple! Get it together, I've owned my phone for a month now.

In October the 9th I had 97% battery health and after not even a month (on the 28th October) my battery health went down to 94%. Anyone knows why ? I haven’t been using my phone more or charging it more than usual. using an iPhone 15 pro max. This is really concerning !!! 3% in less than a month?

I've noticed an issue when using an iPhone or iPad that uses a USB-C port (such as the iPhone 15 Pro or iPad Pro 12.9" 6th generation) and a USB-C to USB-C cable on ARM Macs (such as the M2 Mini). After rebooting the Mac, the iOS device is no longer recognized despite the iOS device continuing to charge. I can temporarily resolve the issue by reseating the USB-C cable, which allows the device to be recognized again by applications like Finder. However, this isn't a practical solution due to the number of M2 Minis we have (each with an attached iPhone for testing) and the Mini's frequent automatic reboots throughout the day. Using a USB-A to USB-C cable (with USB-A connected to the Mac Mini) seems to avoid this problem altogether, as the iOS device remains consistently recognized after a reboot. As the title suggests, this issue appears to be specific to ARM-based Macs. We've encountered it on both the M2 Mini and a 2021 Macbook Pro with the M1 Max chip. Interestingly, we haven't been able to reproduce this behavior on Intel-based Macs (tested on an 8,1 Mac Mini and a 2019 16" Macbook), where the iOS devices remain connected after a reboot when using a USB-C to USB-C cable. Here are some additional details: iOS Devices & Versions: iPhone 15 Pro: Issue persists on both iOS 17.1 and iOS 18.0.1 iPad Pro 12.9" (6th generation): Issue persists on both iPadOS 17.6.1 and iPadOS 18.0.1 Cables: Apple's 60W USB-C Charge Cable (USB 2.0): Issue occurs Generic/Third-party USB-C cable (USB 3): Issue occurs

After updating the IOS to 18 currently running 18.2 apparently the front camera stopped working on all video call apps such as FaceTime, Google and when using the camera app itself the front camera does not display when selected via the the display button. The front camera does appear to operate with Face ID however

hi Question is in the title.. do we already know the length of the vectors? best regards

I added some AVCaptureControl, then removed all of it. The phenomenon is that AVCaptureSession controls are 0 in number, but the keys can still display the previous AvcaptureControls guard(_session.supportsControls) else return; for (AVCaptureControl *control in _session.controls) { [_session removeControl:control]; } @weakify(self); if (self.captureControl.zoom) { if (self.zoomScaleControl) { self.zoomScaleControl.enabled = false; [_session removeControl:self.zoomScaleControl]; } AVCaptureSlider *zoomSlider = [self.captureControl.zoom fetchCaptureSlider]; [zoomSlider setActionQueue:dispatch_get_main_queue() action:^(float zoomFactor) { @strongify(self); if ([self.dataOutputDelegate respondsToSelector:@selector(videoCaptureSession:tryChangeZoomScale:)]) { [self.dataOutputDelegate videoCaptureSession:self tryChangeZoomScale:zoomFactor]; } }]; self.zoomScaleControl = zoomSlider; } else { self.zoomScaleControl = nil; } if (self.captureControl.exposure) { if (self.exposureBiasControl) { self.exposureBiasControl.enabled = false; [_session removeControl:self.exposureBiasControl]; } AVCaptureSlider *exposureSlider = [self.captureControl.exposure fetchCaptureSlider]; [exposureSlider setActionQueue:dispatch_get_main_queue() action:^(float bias) { @strongify(self); if ([self.dataOutputDelegate respondsToSelector:@selector(videoCaptureSession:tryChangeExposureBias:)]) { [self.dataOutputDelegate videoCaptureSession:self tryChangeExposureBias:bias]; } }]; self.exposureBiasControl = exposureSlider; } else { self.exposureBiasControl = nil; } if (self.captureControl.len) { if (self.lenControl) { self.lenControl.enabled = false; [_session removeControl:self.lenControl]; } ORLenCaptureControlCustomModel *len = self.captureControl.len; AVCaptureIndexPicker *picker = [len fetchCaptureSlider]; [picker setActionQueue:dispatch_get_main_queue() action:^(NSInteger selectedIndex) { @strongify(self); if ([self.dataOutputDelegate respondsToSelector:@selector(videoCaptureSession:didChangeLenIndex:datas:)]) { [self.dataOutputDelegate videoCaptureSession:self didChangeLenIndex:selectedIndex datas:self.captureControl.len.indexDatas]; } }]; self.lenControl = picker; } else { self.lenControl = nil; } if ([_session canAddControl:self.zoomScaleControl]) { [_session addControl:self.zoomScaleControl]; } else { self.zoomScaleControl = nil; } if ([_session canAddControl:self.lenControl]) { [_session addControl:self.lenControl]; } else { self.lenControl = nil; } if ([_session canAddControl:self.exposureBiasControl]) { [_session addControl:self.exposureBiasControl]; } else { self.exposureBiasControl = nil; } [_session setControlsDelegate:self queue:GetCaptureControlQueue()];

My phone keeps restarting randomly every few seconds to every few minutes at random. It also feels like its overheating at the same time. Heres the panic log: bug_type":"210","timestamp":"2024-10-22 12:23:26.00 -0400","os_version":"iPhone OS 18.0.1 (22A3370)","roots_installed":0,"incident_id":"E2DC5427-D751-4339-827B-181625987FCF"} { "build" : "iPhone OS 18.0.1 (22A3370)", "product" : "iPhone15,3", "socId" : "8120", "socRevision" : "11", "incident" : "E2DC5427-D751-4339-827B-181625987FCF", "crashReporterKey" : "df026d01d48e533d7258182dafc82a95473d59d4", "kernel" : "Darwin Kernel Version 24.0.0: Thu Aug 8 01:15:37 PDT 2024; root:xnu-11215.2.562/RELEASE_ARM64_T8120", "date" : "2024-10-22 12:23:26.77 -0400", "panicString" : "panic(cpu 0 caller 0xfffffff040697444): AOP PANIC - !pulse pearl@0x1173490 - power(2) OUTBOX3 not ready - \nuser handlers:\nEiger::probe=0 [e4 30 1] conn=0\n\nPrAS Comp = stat [0, 0], dbg [205452, 41680, 416832, 0, 12665, 404163, 1, 9973, 4] \n\n\n!pulse pearl@0x1173490\nRTKit: RTKit-2758.2.1.debug - Client: iphone15aop:DEBUG:AppleSPUFirmwareBuilder-632.0.717199\n!UUID: 26e83ac2-7536-30ff-9f4c-57d91477a498\nASLR slide: 0x0000000000000000\nTime: 0x000000025b5db6d5\n\nFaulting task 2 Call Stack: 0x00000000011078c4 0x0000000001107250 0x0000000001107064 0x000000000110acf4 0x000000000110adb4 0x00000000010ef884 0x00000000010f3c38 0x00000000010e9438 0x00000000010148cc 0x00000000010e93a8 0x00000000011069b4 0x0000000001106730