LLDB crash

Also CFURL is documented to have different behavior but CFURL and NSURL aren't they 'toll free bridged' so how does that work if you cast a CFURL to a NSURL? So I just did a dumb little test to answer this. I created a CFURLRef and read kCFURLIsHiddenKey and got false (as expected) so it would cache it. Then on another CFURL instance (that points to the same file) I did the same thing (so it was cache the value). After that I set hidden to YES: NSURL *toNSURL = (__bridge NSURL * _Nonnull)cfURL; [toNSURL setResourceValue:@(YES) forKey:NSURLIsHiddenKey error:nil]; Then back to the other instance I cast that one to another NSURL: NSURL *nsCastCopiedVersion = (__bridge NSURL * _Nonnull)aCopiedCFURL; And read isHidden and it is NO. Read aCopiedCFURL hidden and it is also NO. Then dispatch after dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{ [URLPrinter printCF:aCopiedCFURL]; [URLPrinter printNS:nsCastCopiedVersion]; }); And got: Print copied CF Not hidde

Other than what @Tomato said, you can also try to reset the simulator by running the simulator's Device > Restart or Device > Erase all Contents and Settings menu. This helps rule out that the crash is caused due to unintentional changes on the simulator. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Having the same issue, Macos Tahoe 26.2, i tried everything i found on net: deleting caches, all xcode files, reinstalling it, rebooting my computer, deleting all simalator devices, deleting IOS from Xcode => setting components, downloading it again. I tried installing older IOS, no help, when starting emulator i have this error: Unable to boot the Simulator And this error, when i'm trying to do this from terminal == Devices == -- iOS 26.2 -- iPhone 17 Pro (1FC8FFC9-A04D-434B-85F0-F5AE2DB4CDAC) (Shutdown) iPhone 17 Pro Max (71761C54-D406-496E-A552-CD72FACD10DA) (Shutdown) iPhone Air (64607ACA-F580-4A6A-A816-1AD1E8BEBC32) (Shutdown) iPhone 17 (7ECEC4C0-0DC9-4B5A-A9A0-05E4B1038C68) (Shutdown) iPhone 16e (A175B467-438D-41A7-B537-D7E23B4FFF21) (Shutdown) iPad Pro 13-inch (M5) (FA74F9C7-93C9-40D6-86F5-74E46FCCF7EC) (Shutdown) iPad Pro 11-inch (M5) (73A17C77-DBFA-4748-880D-15FBBE43E57E) (Shutdown) iPad mini (A17 Pro) (09BF89D2-640C-4083-937A-4859633BB69E) (Shutdown) iPad (A16) (5FF5869B-042F-4886-A5E3-AD333550F9

Please post a full Apple crash report, per the instructions in Posting a Crash Report. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for responding. I haven't yet been able to reproduce the issue in a small test project so either they made changes in a macOS update or there is some timing issue and/or way the NSURL is initialized in my real project teases the issue out. But I promise I got stale value for nonexistent NSURLIsHiddenKey until I started explicitly dumping it. In my real project the URL comes for -fileURLWithPath: (and initially created on a background thread). My real project is large and complex so when I have more time I'll have to see if I can isolate the issue in a small sample. Due the request by iOS and the server cache the user may see some discrepancies or additional nuances in how and caching behave, particularly regarding stale values. I'm on macOS. Explicit cache management is recommended, especially when dealing with URLs that may have changed state (e.g., deleted or modified), to ensure your application behaves predictably across different environments and runtime sessions. Also CFURL is documented to have

The challenge we are facing is that certain functionality does not behave correctly when the app resumes the next day without a normal cold start. The primary issue is with the SLM (Sound Level Meter) framework, which relies on audio sessions. In these resumed states, the audio session is not always reinitialized cleanly, causing our calibration process to fail and leading to the core issue we observed. If you haven't already, this sounds like something worth filing a bug about. Have you, and if so, what's the bug number? More recently, we encountered a case where we did not even receive the applicationDidEnterBackground callback. We extended the same force-exit handling to cover this scenario as well. Do you have any more information/context about this case? There are cases where apps aren't formally put into the background (for example, I believe swiping control center down will trigger applicationWillResignActive but NOT applicationDidEnterBackground), but all of these cases should also mean that the app i

It’s hard to offer insight here without a full Apple crash report. Does anyone have one of those? If so, please post it here. See Posting a Crash Report for advice on how to do that. [quote='870052022, brianindeed, /thread/810678?answerId=870052022#870052022, /profile/brianindeed'] Do these [iOS] versions correspond to the RC or the GM? [/quote] You can tell that from the format of the build numbers. For example, in 23C5027f you have: 23 — This maps to the major version number, in this case iOS 26. C — This maps to the minor version number [1], making it iOS 26.2. 50 — This contains the build number prefix; see below for more on that. 27 — This is the actual build number. f — This is something internal that I’m not going to go in to. In seed builds we prefix the build number with a digit indicating the type of build, padding it up to three digits with leading zeroes. So 5027 is build 27 with a build type of 5 [2]. In released builds we don’t do this padding. For example, the release build of

I've been seeing this crash occurring as well in crash reports. Does anyone know what could be causing or possible solution on this?

Hello Allen, Thanks for filing the crash report with the full crash log. Just to confirm, are you overriding viewWillTransitionToSize:withTransitionCoordinator:, and if so, can you please provide the relevant code in the method? Thank you for your patience, Richard Yeh  Developer Technical Support