LLDB crash

I’m facing an issue where iOS Simulator versions 18.6 and above (including iOS 26.0.1) fail to boot, while older simulators like iOS 18.0 / 18.2 work fine on the same machine. Environment macOS 26.2 (Build 25C56) Xcode 26.0 (Build 17A324) iOS Simulator runtimes: iOS 18.0 – works iOS 18.6 – fails to boot iOS 26.0.1 – fails to boot Error observed Unable to boot the Simulator NSPOSIXErrorDomain Code: 4 (Interrupted system call) Failed to start launchd_sim: could not bind to session, launchd_sim may have crashed or quit responding This happens even when launching the Simulator app directly (without running any app). Steps already tried (no success) Shut down and erased all simulators: xcrun simctl shutdown all xcrun simctl erase all Deleted CoreSimulator data: rm -rf ~/Library/Developer/CoreSimulator killall -9 com.apple.CoreSimulator.CoreSimulatorService Rebooted macOS multiple times Reinstalled simulator runtimes via Xcode → Settings → Platforms Attempted runtime deletion using: xcrun simctl runtime de

The last line of the message says: Please file a bug report against lldb reporting this failure log, and as many details as possible Let's start there — what is the FB of your report in Feedback Assistant? Further, make sure to include things like the Xcode version and the OS version you are debugging on, and to see if this reproduces with the latest Xcode version, currently Xcode 26.2. — Ed Ford,  DTS Engineer

I'm having the exact same issue. I took out my IDs and then the developer app crashed each time I got to this point. I called apple support and they said there is nothing that can be done because they cannot verify my identity. So let me verify, I'm ready to verify. I called in multiple times and they told me the same thing each time.

I encountered another bug with SwiftData and inheritance and reported it (FB21837287). This one is not related to CloudKit. Briefly, SwiftData crashes during auto-save when the schema contains: A base @Model class with at least one subclass (inheritance) A separate @Model class with a reference to the base class The crash occurs specifically when: There is a class inheritance hierarchy (Beta: Alpha) A separate class (Standalone) has a reference typed as the base class (Alpha?) Changing the reference from var ref: Alpha? to var ref: Beta? (subclass) eliminates the crash.

I had the same problem with my M2 iPad Air, and ChatGPT told me to do this instantly worked. but you have to follow the instructions Yes — here’s the clean, repeatable fix for an iPad stuck in a reboot loop (Apple logo → restarts → logo again). Start at Step 1 and only move on if it doesn’t work. ⸻ Step 1 — Force restart (fastest, safest) This fixes temporary system crashes. If your iPad has Face ID (no Home button): 1. Quickly press Volume Up → release 2. Quickly press Volume Down → release 3. Press and HOLD Power 4. Keep holding until you see the Apple logo, then let go If your iPad has a Home button: 1. Hold Home + Power together 2. Keep holding until the Apple logo appears 👉 If it boots normally, you’re done. ⸻ Step 2 — Recovery Mode (most common real fix) Use this if it keeps looping. What you need • A Mac or Windows PC • A cable • Finder (Mac) or iTunes (Windows / older macOS) Steps 1. Connect iPad to the computer 2. Force-restart but DO NOT release when the Apple logo appears 3. Keep holding

Thanks for providing the reproducible case, which will greatly help the TextKit folks to address the issue from the framework side. As the reproducible case shows, the crash is triggered by a specific combination of attributes. Unless you can identify the cases and avoid them, I unfortunately don't see anything from the app side that can fix / work around the issue. I have added my comment to the feedback report (FB16905066). Thank you all again for making the feedback much more actionable by providing the project that reproduces the crash. Best, —— Ziqiao Chen  Worldwide Developer Relations.

For your first approach, are you able to provide information about the crash, like a crash log? For your second approach, it is common to see initial view hierarchy setup for a window in your window controller subclass’s overridden windowDidLoad method. For a view that just needs to display a solid color, NSBox can be used for this purpose: let box = NSBox() box.boxType = .custom box.borderWidth = 0.0 box.fillColor = NSColor.systemRed

This got even weirder. One is that sometimes the use of cos() would cause a compiler error, which was fixed by using Darwin.cos(). This may be fixed in Swift 6.3. The other thing is that in my much more complex code, the crash seemed to be caused by both the cos() call evaluating to 0, but only when the line being drawn with that result had a StrokeStyle applied to it. In anycase, I have filed Feedbacks explaining this, and I'm told the WindowServer team has had it brought to their attention.