LLDB crash

Hi all, I'm encountering a strange crash issue during local iOS debugging on a real device, and I'm hoping someone can help explain it. The crash log contains unusually high offsets that are completely outside of any module address ranges listed in Binary Images. For example: 6 ??? 0x129ac0ee8 -[...:] + 1052 But the Binary Images section shows: 0x102358000 - 0x102363fff ChinaMobile arm64 ... 0x11bb2c000 - 0x11bdeffff ChinaMobile.debug.dylib arm64 ... ... There are two binaries for my app listed here, but neither matches that high crash address (0x129ac0ee8). Additionally, sometimes the Binary Images section doesn't even include my app's binary at all, which makes the crash logs even harder to analyze. This crash definitely happens inside my main app’s business code, yet the crash offset doesn’t match any listed binary range. Also, the crash logs contain many ??? module names and missing symbols, even though I'm running a Debug build locally, and I

Good afternoon, I have the latest version of Xcode. I am trying to debug why I am not able to Sign in with Apple Sign In on my app. After days of trying everything I just noticed today that the TeamID Xcode is using to automatically sign the app is not my current Team Id. I had a years hiatus and my code login expired. When I recreated my account I got a new Team Id and that is what is on all my certificates, profiles, etc. Old team id: Z82SJZ64R6 Current team id: 22649D52Q5. I take off automatically signing and select my Mac app bistro and iOS app distro and the app fully builds then Xcode crashes with an error that mentions security - Error code 5. Is there a way for me to change the old team id in Xcode? I've already tried logging out and back in through settings.

We are experiencing a crash in our application that only occurs on devices running iOS beta 26. It looks like a Beta problem. The crash appears to be caused by an excessive number of open File Descriptors. We identified this after noticing a series of crashes in different parts of the code each time the app was launched. Sometimes it would crash right at the beginning, when trying to load the Firebase plist file. That’s when we noticed a log message saying “too many open files,” and upon further investigation, we found that an excessive number of File Descriptors were open in our app, right after the didFinishLaunching method of the AppDelegate. We used the native Darwin library to log information about the FDs and collected the following: func logFDs() { var rlim = rlimit() if getrlimit(RLIMIT_NOFILE, &rlim) == 0 { print(FD LIMIT: soft: (rlim.rlim_cur), hard: (rlim.rlim_max)) } // Count open FDs before Firebase let openFDsBefore = countOpenFileDescriptors() print(Open

Hello since updating to beta 3 the sculpting sample app doesn't work it crashes on running. seems to be something in AnchorEntity or AccessoryAnchoringSource Referenced from: <00B81486-1A74-30A0-B75B-4B39E3AF57DF> /private/var/containers/Bundle/Application/3D2EBF59-19F0-4BF4-8567-6962AA36A2C6/delete.app/delete.debug.dylib Expected in: /System/Library/Frameworks/RealityFoundation.framework/RealityFoundation

hi , There is a crash when we run on an **iOS 16 real device ** if we set a .toggleButton trait for accessibilty . it has version check as apple doc refers (IOS 17 +) but it crashes so there is someinconsistency between availbility in ios 18 + , somehow other xcodes made it available from 17 for now we commented our code , but would like dto report this to be fixed cheers

I have this very simple PersistenceController setup. It's used in both the main app and widget target. struct PersistenceController { static let shared = PersistenceController() @MainActor static let preview: PersistenceController = { let result = PersistenceController(inMemory: true) let viewContext = result.container.viewContext return result }() let container: NSPersistentContainer /// The main context. var context: NSManagedObjectContext { return container.viewContext } init(inMemory: Bool = false) { container = NSPersistentContainer(name: Gamery) if inMemory { container.persistentStoreDescriptions.first!.url = URL(fileURLWithPath: /dev/null) } else { do { let storeURL = try URL.storeURL(forAppGroup: XXXXXXXXXX, databaseName: Gamery) let storeDescription = NSPersistentStoreDescription(url: storeURL) /// Enable history tracking for cloud syncing purposes. storeDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) print(### Persistent container location: (storeURL)) container.persi

Hi all, I’m testing the new PaperKit API following the sample code from WWDC 2025. The PKToolPicker appears and allows pen selection, and I can insert text and images as expected. However, whenever I attempt to draw or tap on the markup surface, the app immediately crashes. Here’s a simplified version of my setup: var paperViewController: PaperMarkupViewController! override func viewDidLoad() { super.viewDidLoad() let markupModel = PaperMarkup(bounds: view.bounds) paperViewController = PaperMarkupViewController(markup: markupModel, supportedFeatureSet: .latest) view.addSubview(paperViewController.view) addChild(paperViewController) paperViewController.didMove(toParent: self) becomeFirstResponder() let toolPicker = PKToolPicker() toolPicker.addObserver(paperViewController) pencilKitResponderState.activeToolPicker = toolPicker pencilKitResponderState.toolPickerVisibility = .visible toolPicker.accessoryItem = UIBarButtonItem(barButtonSystemItem: .add, target: self, action: #selector(plusButtonPressed(_:

after i updated to iOS 26.0 Beta3, UIScrollEdgeElementContainerInteraction crashed: let scrollInteraction = UIScrollEdgeElementContainerInteraction() scrollInteraction.edge = .bottom scrollInteraction.scrollView = webView?.scrollView bottomBar.addInteraction(scrollInteraction) i got this crash info:unrecognized selector sent to instance: UIScrollEdgeElementContainerInteraction setEdge: and UIScrollEdgeElementContainerInteraction setScrollView

About 4 months ago, I shipped the first version of my app with 4 versioned schemas that, unintentionally, had the same versionIdentifier of 1.2.0 in 2 of them: V1: 1.0.0 V2: 1.1.0 V3: 1.2.0 V4: 1.2.0 They are ordered correctly in the MigrationPlan, and they are all lightweight. Migration works, SwiftData doesn't crash on init and I haven't encountered any issues related to this. The app syncs with iCloud. Questions, preferable for anybody with knowledge of SwiftData internals: What will break in SwiftData when there are 2 duplicate numbers? Not that I would expect it to be safe, but does it happen to be safe to ship an update that changes V4's version to 1.3.0, what was originally intended?