Hello, I have 3 model versions and I'm trying to step through migration. Version 2 makes significant changes to v1. As a result, I've renamed the entities in question by appending _v2 to their name, as the data isn't important to retain. v3, remove's the appended version number from v2. Setting the .xcdatamodeld to v3 and the migrations steps array as follows causes the app to error [ NSLightweightMigrationStage([v1]), NSLightweightMigrationStage([v2]), NSLightweightMigrationStage([v3]), ] CoreData: error: : Attempting recovery from error encountered during addPersistentStore: 0x10770f8a0 Error Domain=NSCocoaErrorDomain Code=134110 An error occurred during persistent store migration. An error occurred during persistent store migration. Cannot merge multiple root entity source tables into one destination entity root table. I find this odd because if I run the migration independently across app launches, the migration appears to drop the no longer used tables in v2, then re-add them back in v3. So it seems to m
Search results for
LLDB crash
30,301 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I’m hoping to get some insight from Apple engineers or developers who have seen similar behavior. Background We previously had a React Native / Expo iOS app in production for several years. Recently, we rebuilt the app completely from scratch as a native SwiftUI app using WKWebView (no shared code, no RN runtime). The new app architecture is: Native SwiftUI container WKWebView loading a remote web app Firebase Analytics & Crashlytics Push notifications (APNs + FCM) No local database, no persistent native state Migration scenario Users update the app via the App Store: Old app: React Native / Expo New app: native SwiftUI + WKWebView For most users, the migration works fine. However, for a about 10% of users, the following happens: The issue After updating from the old React Native app to the new SwiftUI app: The app opens The native landing screen appears (solid black OR blue background, depending on which most recent version if being installed) The app never transitions to the WKWebView No crash
Topic:
UI Frameworks
SubTopic:
SwiftUI
Hello, after updating macOS to 26.2 and Xcode to 26.2 (Build 17C52), I am unable to build a Flutter iOS application for the simulator. Environment: macOS 26.2 (darwin-arm64) Xcode 26.2 (17C52) Flutter 3.38.7 (stable) Dart 3.10.7 CocoaPods 1.16.2 Target device: iPhone 16e Simulator (iOS 26.x) Issue: The build fails during the Flutter Xcode build phase with this error: Unhandled exception: Null check operator used on a null value #0 Context._embedNativeAssets (file:///opt/homebrew/share/flutter/packages/flutter_tools/bin/xcode_backend.dart:341) Command PhaseScriptExecution failed with a nonzero exit code. Additional info: Runner target uses Pods-Runner.debug/profile/release.xcconfig correctly SUPPORTED_PLATFORMS = iphoneos iphonesimulator SDKROOT resolves to iPhoneOS26.2.sdk even when building for simulator Build Settings and Run Script phases are default Flutter-generated Issue occurs both via flutter run and directly from Xcode Project worked before macOS/Xcode update It appears Xcode 26.2 may be resolving SD
Topic:
Developer Tools & Services
SubTopic:
Xcode
In our app, we implement a document picker using FilePickerManager+available.m, selecting different APIs based on the iOS version: if (@available(iOS 14.0, *)) { NSMutableArray *contentTypes = [NSMutableArray array]; for (NSString *uti in documentTypes) { UTType *type = [UTType typeWithIdentifier:uti]; if (type) { [contentTypes addObject:type]; NSLog(@iOS 14+ Adding type: %@, uti); } else { NSLog(@Warning: Unable to create UTI: %@, uti); } } UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypes]; documentPicker.delegate = self; documentPicker.allowsMultipleSelection = NO; [self.presentingViewController presentViewController:documentPicker animated:YES completion:nil]; } However, we've observed inconsistent symbol reference types to UTType in the final linked binaries: One build results in a strong reference to UTType. Another demo project (with seemingly identical code and build settings) results in a weak reference. Both object files
In our app, we implement a document picker using FilePickerManager+available.m, selecting different APIs based on the iOS version: if (@available(iOS 14.0, *)) { NSMutableArray *contentTypes = [NSMutableArray array]; for (NSString *uti in documentTypes) { UTType *type = [UTType typeWithIdentifier:uti]; if (type) { [contentTypes addObject:type]; NSLog(@iOS 14+ Adding type: %@, uti); } else { NSLog(@Warning: Unable to create UTI: %@, uti); } } UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypes]; documentPicker.delegate = self; documentPicker.allowsMultipleSelection = NO; [self.presentingViewController presentViewController:documentPicker animated:YES completion:nil]; } However, we've observed inconsistent symbol reference types to UTType in the final linked binaries: One build results in a strong reference to UTType. Another demo project (with seemingly identical code and build settings) results in a weak reference. Both object files
@DTS Engineer we believe we have found out the problem now... We created a TSI and Apple suggested that we tried find the crashing code by isolation, i.e., pulling our code until the crash disappeared. With some effort we managed to make a small demo app where the crash occurred. We realised that we have a UIView, which is backed by CATiledLayer. But for this view we also had backgroundColor = .clear. Even without the view's draw(rect:) method the app could crash! Apple's TSI engineer explained that if you have a view that implements draw(rect:) then you should not set the background color at the same time! But we needed the background to be transparent, and so we found that setting isOpaque = false instead of setting the background color made the crash disappear! We still believe that UIKit shouldn't crash if you set the background color, which it didn't do prior to iOS 26 :)
Topic:
App & System Services
SubTopic:
Networking
Tags:
Reply to
System Panic with IOUserSCSIParallelInterfaceController during Dispatch Queue Configuration
Hi Kevin, Thank you for your deep insight. Your theory matches our observed facts perfectly! I have just updated FB21636775 with the latest symbolicated crash log captured today (Jan 19). 1. Evidence of Concurrent Execution Conflict From the symbolicated backtrace, it is clear that at the moment of the crash: Thread 1 (AuxiliaryQueue): Is in the middle of executing UserCreateTargetForID (Frame 12). This RPC call has not yet returned to our DEXT. Thread 4 (Crashed Thread): Has already received the hardware interrupt for the first command (TEST UNIT READY) and is attempting to invoke the completion API. 2. Crash Characteristic Analysis The system encountered an Address size fault (Null dereference) at address 0x0000000000000008. This confirms your deduction: because UserCreateTargetForID is still pending on the AuxiliaryQueue and has not returned, the target-related objects or OSAction metadata in the kernel are not yet fully initialized. Attempting to invoke the action from
Topic:
App & System Services
SubTopic:
Drivers
Tags:
Same with me as well, both present in iOS 26.1 and 26.2. One of our top ones at 1,473 crash events total. Our happens on an XPCConnection update.
Topic:
UI Frameworks
SubTopic:
UIKit
Tags:
Hi everyone, I am working on a CarPlay integration, and need open a two level list opened from a root template. However, I am always receiving an error message when opening the 2nd pushed template. To narrow it down not to have an issue with some app specific code I created the CarPlay scene below. I am aware that there is a limit, but two levels I understand are supported on all CarPlay integrations, the maximum seems to be 5. The app is just crashing right after showing the 2nd template. Any ideas? Any hints are much appreciated. Thanks a lot! Regards, Michael class CarPlaySceneDelegate2: UIResponder, CPTemplateApplicationSceneDelegate { // [...] private func createRootTemplate() -> CPListTemplate { let pushToAItem = CPListItem(text: Push to Template A, detailText: Level 1 → Level 2) pushToAItem.handler = {[weak self] (pushToAItem, completion) in guard let self = self else { completion() return } self.interfaceController?.pushTemplate( self.pushTemplateA(), animated: true, completion: { (didPres
In a code signature, the certificates act as a chain of trust [1]. The first certificate is the leaf, the next is the one that issued the leaf, and so on until you get to a root. Ah I see, did not realize this before but it makes perfect sense, thank you. ...the next thing to check is whether this is the right type of profile. Turns out it is not a distribution profile and this was the problem all along. The error message Missing code-signing certificate was a red-herring this whole time. What is interesting is that it appears that it used to work even though it shouldn't have, by virtue of the fact that these app builds are present in Testflight and the profile it was using dates from before those builds. Alas am unable to confirm that for certain as CI history is too shallow and we no longer have a copy of the app bundle to verify. At some point altool has stopped returning non-zero exit codes on failure so CI has been blind to the failures for some months now (probably since Xcode 26 I'm guessing). Thanks
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Reply to
System Panic with IOUserSCSIParallelInterfaceController during Dispatch Queue Configuration
I have updated the Bug Report (FB21636775) with a new symbolicated crash log. OK. I have a totally new theory. Is it possible you're having an interrupt fire before you've completed full initialization, so you end up shuffling uninitialized data into the system? The crash log shows that you're in IOUserSCSIParallelInterfaceController::UserCreateTargetForID, so this is still very early in the startup process. I ask this, because an issue like this would explain both of these: (1) I attempted the over-retaining experiment you suggested (adding an extra retain() at the start of the loop and omitting release() in the ISR). Over retaining a valid object shouldn't actually do anything meaningful, as all you're doing is incrementing a simple integer counter. Eventually you might cause the counter to overrun, but that's not something that would happen immediately. It certainly shouldn't cause a kernel panic... The result was critical: it triggered an immediate Kernel Panic / Hard Reset every time. .
Topic:
App & System Services
SubTopic:
Drivers
Tags:
On my latest build I have 15 pannes French word for crash with ZERO session. It was the same for the previous build (2 days before): zero session and 498 pannes (crash). How is that possible ? And in Xcode/Organizer : No crash logs since 2 weeks. Who can it be possible ?
Topic:
App Store Distribution & Marketing
SubTopic:
TestFlight
Reply to
System Panic with IOUserSCSIParallelInterfaceController during Dispatch Queue Configuration
Hi Kevin, Thank you for your candid feedback. You are absolutely correct—the crash log I previously shared was from an experimental attempt where we mistakenly used the legacy ParallelTaskCompletion API for bundled commands. I apologize for the confusion. I have now strictly followed your guidance, and here is the latest update: 1. Corrected Bug Report & Logs I have updated the Bug Report (FB21636775) with a new symbolicated crash log. This log definitively captures the failure while invoking the correct BundledParallelTaskCompletion API (as shown in Frame 8 of the trace). Even with the correct API, the system still triggers an __assert_rtn followed by an Address size fault (ESR: 0x56000080). 2. Over-retaining Experiment Results (Hard Reset) I attempted the over-retaining experiment you suggested (adding an extra retain() at the start of the loop and omitting release() in the ISR). The result was critical: it triggered an immediate Kernel Panic / Hard Reset every time. Because the system
Topic:
App & System Services
SubTopic:
Drivers
Tags:
Reply to
System Panic with IOUserSCSIParallelInterfaceController during Dispatch Queue Configuration
Bug Report Filed I have filed a bug report via Feedback Assistant. Clarifying things, what I was specifically looking for here was a bug asking us to document exactly how the action for BundledParallelTaskCompletion should be managed. The issue here is that its usage semantics are somewhat... weird. You're given a single action pointer, but you're expected to use that action pointer multiple times (since individual commands won't complete at the same time), which makes its lifetime somewhat... odd. In practice, I don't think this actually matters. As you've noted, you always receive the same pointer so as long as you don't release it too many times everything will be fine. For maximum correctness, you could do something like this: Retain it once (or a few times) the first time you receive it in UserProcessBundledParallelTasks() Release it at some late point in the teardown process when you know all I/O is done. Add an assert in UserProcessBundledParallelTasks() to validate that it never changes (which would b
Topic:
App & System Services
SubTopic:
Drivers
Tags:
SOLUTION: Delete workspace user state files If Xcode crashes when opening the AI Intelligence tab in a specific project, the issue is corrupted UI state data in your workspace. Fix: Close Xcode completely Navigate to your project directory in Terminal and delete UserInterfaceState.xcuserstate: rm YourProject.xcodeproj/project.xcworkspace/xcuserdata/YOUR_USERNAME.xcuserdatad/UserInterfaceState.xcuserstate This resolved the crash for me in Xcode 26.2 on macOS 26.2. What this does: Deletes the corrupted workspace UI state (including Intelligence chat history). Xcode will recreate it fresh. You'll lose panel positions and open tabs, but all your code and project settings remain intact.
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags: