LLDB crash

For a long time our app had this creation of a URLRequest: var urlRequest = URLRequest(url: url, cachePolicy: .reloadIgnoringLocalAndRemoteCacheData, timeoutInterval: timeout) But since iOS 26 was released we started to get crashes in this call. It is created on a background thread. Thread 10 Crashed: 0 libsystem_malloc.dylib 0x00000001920e309c _xzm_xzone_malloc_freelist_outlined + 864 (xzone_malloc.c:1869) 1 libswiftCore.dylib 0x0000000184030360 swift::swift_slowAllocTyped(unsigned long, unsigned long, unsigned long long) + 56 (Heap.cpp:110) 2 libswiftCore.dylib 0x0000000184030754 swift_allocObject + 136 (HeapObject.cpp:245) 3 Foundation 0x00000001845dab9c specialized _ArrayBuffer._consumeAndCreateNew(bufferIsUnique:minimumCapacity:growForAppend:) + 120 4 Foundation 0x00000001845daa58 specialized static _SwiftURL._makeCFURL(from:baseURL:) + 2288 (URL_Swift.swift:1192) 5 Foundation 0x00000001845da118 closure #1 in _SwiftURL._nsurl.getter + 112 (URL_Swift.swift:64) 6 Foundation 0x00000001845d

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

Question: How to prevent Flutter app crash on iOS 18 during cold start when iOS traverses view hierarchy before Flutter engine is fully initialized? Help needed: Looking for a way to either delay iOS view hierarchy traversal or ensure Flutter is fully initialized before iOS lifecycle callbacks fire. Problem Summary Our Flutter app crashes on cold start for approximately 1-2% of iOS users. The crash occurs specifically on iOS and only under these exact conditions: When crash happens: User opens app and uses it normally ✅ User minimizes app (goes to background) ✅ User returns to app from background ✅ (works fine) User kills app from app switcher (swipe up to close) User taps app icon to launch again → CRASH ❌ Key observations: Crash is intermittent - app may open on 2nd, 3rd, or 5th attempt 100% reproducible on affected devices by repeating kill→launch cycle ~98% of users have no issues Environment Flutter: 3.38.3 Crash Logs (from Sentry) Crash

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

I have an iOS and macOS app that includes a file provider extension. on macOS is is perfect no issues anywhere. on iOS it works for small datasets or if I do read only operations. as soon as I try to do anything with larger files I quickly hit the 20MB limit. I have solved file transfers by using chunking but when it comes to listing a folder with a couple thousand files it instantly crashes the FPE with an OOM error. works ok up to 100 files but anything beyond that crashes. I know enumerate items supports batches however the initial load form say a webdav server that has no concept of pagination will always fail to load in pieces no matter what I do. This likely explains why WebDAV was never implemented on iOS. in any case can you possibly consider upgrading the memory limit for FPE's or provide some mechanism to call our full iOS app for more processing power in the background to handle requests on demand? I do not understand where 20MB is a reasonable number. even 100MB seems more reason

https://developer.apple.com/forums/thread/788293 In the above thread, I received the following response: When building with the SDK from the next major release after iOS 26, iPadOS 26, macOS 26 and visionOS 26, UIKit will assert that all apps have adopted UIScene life cycle. Apps that fail this assert will crash on launch. does this mean that there will be no app crashes caused by UIKit in iOS 26, but there is a possibility of app crashes when building with the SDK provided from iOS 27 onwards?

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 ?