When using iOS 26.2 (23C55) Safari, the following can occur. The current tab (A) opens a new tab (B) via window.open(url, target, windowFeatures). The user clicks the "back" button to close tab B, and returns to tab A. Tab A attempts to open tab B again at a later point, using the same "target" as before, and fails (no window object is returned by window.open). This bug only occurs when the target is the same as the previously closed tab (which was closed via the back button). If a new target is specified, the new tab opens as expected. This bug is also limited to the back button. If the user manually closes tab B, then it can be re-opened by tab A using window.open using the same target as before.

I'm stuck in an impossible situation with DeviceActivityReportExtension on iOS 18. THE ISSUE: Configuration that works on device (iOS 18.2): Info.plist has only NSExtensionPointIdentifier Swift code uses u/main attribute App installs and runs perfectly Extension works correctly App Store validation FAILS: "Missing NSExtensionPrincipalClass" Adding NSExtensionPrincipalClass (as validation requests): Device installation FAILS with Error 3002 Error says: "NSExtensionPrincipalClass key is not allowed for this extension point" Cannot test on device Validation would likely pass ENVIRONMENT: Xcode 16.2 iOS 18.2 Extension point: com.apple.deviceactivityui.report-extension EVIDENCE IT'S WIDESPREAD: Apple Forums (3 days ago): https://developer.apple.com/forums/thread/812380 Stack Overflow (1+ year): https://stackoverflow.com/questions/77866230/ ROOT CAUSE: iOS 18 changed this extension to use u/main pattern (no NSExtensionPrincipalClass needed). App Store validation hasn't been updated and still expects iOS 17 configuration. WHAT I'VE TRIED: ✅ All deployment targets set to iOS 18.3 ✅ Code follows Apple's WWDC 2022 guidance ✅ All entitlements correct ✅ Info.plist validated ✅ Clean builds ✅ Works perfectly on device No configuration satisfies both device runtime AND App Store validation. Has anyone successfully uploaded an app with DeviceActivityReportExtension to TestFlight on iOS 18? Any workarounds? This is blocking TestFlight deployment completely.

Hi, I am running build on ios 26.2 device, connected with cable (not wifi) and it crashes because files are not loaded or something. But when i turn off Debug Exetuble, it works just fine. Also, tried to run on ios 18.2 device, with Debug executable On - everything is ok, and breakpoints work. My guess, App crashes on reading and loading Assets and others app files like certificates. XCode run logs shows: **"Too many file errors". ** sample.txt xcode_run_logs.txt Also, exectued image list on lldb console, could not attach here, if needed i can add it with some url here.

My application always crashes at the same position when I open it on my iPad Air. It doesn't crash in debug mode which makes it very difficult for me to find the issue. My crash report from TestFlight: Exception Subtype: KERN_INVALID_ADDRESS at 0x000000016d5f26f0 Exception Codes: 0x0000000000000001, 0x000000016d5f26f0 VM Region Info: 0x16d5f26f0 is not in any region. Bytes after previous region: 546219761 Bytes before following region: 399632 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL MALLOC_LARGE 14c000000-14cd08000 [ 13.0M] rw-/rwx SM=PRV ---> GAP OF 0x2094c000 BYTES Stack Guard 16d654000-16d658000 [ 16K] ---/rwx SM=NUL Termination Reason: SIGNAL 4 Illegal instruction: 4 Terminating Process: ProjectiOS [745] Triggered by Thread: 0 Thread 0 name: Thread 0 name: Thread 0 Crashed: 0 ProjectiOS 0x0000000107abf3b4 0x1026ac000 + 88159156 1 ProjectiOS 0x000000010e7d3be4 0x1026ac000 + 202537956 2 ProjectiOS 0x000000010e96c45c 0x1026ac000 + 204211292 3 ProjectiOS 0x000000010e96cadc 0x1026ac000 + 204212956 4 ProjectiOS 0x000000010e7d7ba4 0x1026ac000 + 202554276 5 ProjectiOS 0x00000001079cccc0 0x1026ac000 + 87166144 6 ProjectiOS 0x000000010945f33c 0x1026ac000 + 115028796 7 ProjectiOS 0x000000010945b648 0x1026ac000 + 115013192 8 ProjectiOS 0x0000000109458510 0x1026ac000 + 115000592 9 ProjectiOS 0x0000000107530430 0x1026ac000 + 82330672 10 ProjectiOS 0x0000000109459290 0x1026ac000 + 115004048 11 ProjectiOS 0x0000000109457584 0x1026ac000 + 114996612 12 ProjectiOS 0x00000001094b961c 0x1026ac000 + 115398172 13 ProjectiOS 0x00000001094bb8a0 0x1026ac000 + 115407008 14 ProjectiOS 0x00000001094c0340 0x1026ac000 + 115426112 15 ProjectiOS 0x000000010971e698 0x1026ac000 + 117909144 16 ProjectiOS 0x000000011104f7a4 0x1026ac000 + 244987812 17 QuartzCore 0x00000001879f4548 CA::Display::DisplayLinkItem::dispatch_(CA::SignPost::Interval<(CA::SignPost::CAEventCode)835322056>&) + 64 (CADisplay.mm:6671) 18 QuartzCore 0x00000001879d1c64 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 880 (CADisplay.mm:5794) 19 QuartzCore 0x00000001879e5394 CA::Display::DisplayLink::dispatch_deferred_display_links(unsigned int) + 360 (CADisplay.mm:4886) 20 UIKitCore 0x000000018c936afc _UIUpdateSequenceRunNext + 128 (_UIUpdateSequence.mm:189) 21 UIKitCore 0x000000018c935f8c schedulerStepScheduledMainSectionContinue + 60 (_UIUpdateScheduler.m:1197) 22 UpdateCycle 0x000000027364b560 UC::DriverCore::continueProcessing() + 84 (UCDriver.cc:288) 23 CoreFoundation 0x0000000186f8c4cc __CFMachPortPerform + 168 (CFMachPort.c:604) 24 CoreFoundation 0x0000000186fbc0b0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 60 (CFRunLoop.c:2045) 25 CoreFoundation 0x0000000186fbbfd8 __CFRunLoopDoSource1 + 508 (CFRunLoop.c:2184) 26 CoreFoundation 0x0000000186f93c1c __CFRunLoopRun + 2168 (CFRunLoop.c:3205) 27 CoreFoundation 0x0000000186f92a6c _CFRunLoopRunSpecificWithOptions + 532 (CFRunLoop.c:3462) 28 GraphicsServices 0x000000022790d498 GSEventRunModal + 120 (GSEvent.c:2049) 29 UIKitCore 0x000000018c956ba4 -[UIApplication _run] + 792 (UIApplication.m:3902) 30 UIKitCore 0x000000018c8ffa78 UIApplicationMain + 336 (UIApplication.m:5577) 31 ProjectiOS 0x0000000110d93700 0x1026ac000 + 242120448 32 ProjectiOS 0x00000001109068f0 0x1026ac000 + 237349104 33 ProjectiOS 0x000000010f5885d4 0x1026ac000 + 216909268 34 ProjectiOS 0x000000010f588908 0x1026ac000 + 216910088 35 ProjectiOS 0x0000000107cf95b8 0x1026ac000 + 90494392 36 ProjectiOS 0x000000010e85dce8 0x1026ac000 + 203103464 37 ProjectiOS 0x0000000110fadbd4 0x1026ac000 + 244325332 38 ProjectiOS 0x0000000110f48e64 0x1026ac000 + 243912292 39 ProjectiOS 0x0000000110f50004 0x1026ac000 + 243941380 40 ProjectiOS 0x0000000110fb54f4 0x1026ac000 + 244356340 41 ProjectiOS 0x0000000110de715c 0x1026ac000 + 242463068 42 ProjectiOS 0x000000011102e55c 0x1026ac000 + 244852060 43 dyld 0x0000000183faae28 start + 7116 (dyldMain.cpp:1477) Then I symbolicated all the lines starting with "ProjectiOS" in my crash report but I cannot find the issue. Which lines in my crash report cause the crash? Lines 0-16: alcCaptureSamples (in ProjectiOS) + 202259184 alcCaptureSamples (in ProjectiOS) + 203932520 alcCaptureSamples (in ProjectiOS) + 203934184 alcCaptureSamples (in ProjectiOS) + 202275504 alcCaptureSamples (in ProjectiOS) + 86887372 alcCaptureSamples (in ProjectiOS) + 114750024 alcCaptureSamples (in ProjectiOS) + 114734420 alcCaptureSamples (in ProjectiOS) + 114721820 alcCaptureSamples (in ProjectiOS) + 82051900 alcCaptureSamples (in ProjectiOS) + 114725276 alcCaptureSamples (in ProjectiOS) + 114717840 alcCaptureSamples (in ProjectiOS) + 115119400 alcCaptureSamples (in ProjectiOS) + 115128236 alcCaptureSamples (in ProjectiOS) + 115147340 alcCaptureSamples (in ProjectiOS) + 117630372 BrotliEncoderHasMoreOutput (in ProjectiOS) + 2126968 Lines 31-42: alcCaptureSamples (in ProjectiOS) + 237070332 alcCaptureSamples (in ProjectiOS) + 216630496 alcCaptureSamples (in ProjectiOS) + 216631316 alcCaptureSamples (in ProjectiOS) + 90215620 alcCaptureSamples (in ProjectiOS) + 202824692 BrotliEncoderHasMoreOutput (in ProjectiOS) + 1464488 BrotliEncoderHasMoreOutput (in ProjectiOS) + 1051448 BrotliEncoderHasMoreOutput (in ProjectiOS) + 1080536 BrotliEncoderHasMoreOutput (in ProjectiOS) + 1495496 xamarin_get_original_working_directory_path (in ProjectiOS) + 4032 BrotliEncoderHasMoreOutput (in ProjectiOS) + 1991216

After having used Obj-C and C++ for years, I recently (~6 months) moved to Swift, which is hard for me but most often sends less obscure error messages (not always). My trouble is 1- why is it soooooo long (sometimes up to 20s - that's horrible) to get an object's variables accessible in the debugger? 2- In Xcode 16 why is it no longer possible to arrange my files as I did before (organised into folders from within Xcode - horrible when you get a bigger and bigger project)? 3- Why has it become impossible to see the retention cycles and retaining objects from with the memoryGraph (it's worth ~nothing) now !

I am fixing bugs / extending a macOS app written by somebody else in Swift. I’ve made changes to it and debugging it, so breakpoints/rebuilding/debug print/change/rerun it isn’t a problem. But it is a multi-threaded, async app, and when I pause the running app, it will not display source code location in each thread where it is. I only get assembly. [and, yes, "Always Show Assembly" in OFF] It is inherent to async apps and threading that they spend most of their time waiting for the user to do something. Hence if you stop an app, you’ll almost always be in system code somewhere. But I think wanting to see the origin of completions that are pending is a legitimate question for somebody debugging (and trying to understand how the app works). Am I not aware some feature in Xcode / LLDB to reveal this?

After the iOS 26 update, unwanted animations appear on UIButton. I'm using the attributedTitle property of UIButton.Configuration to change the button's text, and an animation appears after iOS 26. (It's unclear whether it's after iOS 26.0 or iOS 26.1, but it likely started with 26.1.) The peculiar thing is that the animation only starts appearing on buttons that have been pressed once. I tried using UIView.performWithoutAnimation and CATransaction's begin(), setDisableActions(true), commit(), but it didn't work. How should I solve this? Below is the code for changing the button's text. func updateTitle() { let keys = type.keys if keys.count == 1 { guard let key = keys.first else { return } if key.count == 1 { if Character(key).isLowercase { self.configuration?.attributedTitle = AttributedString(key, attributes: AttributeContainer([.font: UIFont.systemFont(ofSize: 24, weight: .regular), .foregroundColor: UIColor.label])) } else if Character(key).isUppercase { self.configuration?.attributedTitle = AttributedString(key, attributes: AttributeContainer([.font: UIFont.systemFont(ofSize: 22, weight: .regular), .foregroundColor: UIColor.label])) } else { self.configuration?.attributedTitle = AttributedString(key, attributes: AttributeContainer([.font: UIFont.systemFont(ofSize: 22, weight: .regular), .foregroundColor: UIColor.label])) } } else { self.configuration?.attributedTitle = AttributedString(key, attributes: AttributeContainer([.font: UIFont.systemFont(ofSize: 18, weight: .regular), .foregroundColor: UIColor.label])) } } else { let joined = keys.joined(separator: "") self.configuration?.attributedTitle = AttributedString(joined, attributes: AttributeContainer([.font: UIFont.systemFont(ofSize: 22, weight: .regular), .foregroundColor: UIColor.label])) } }

Currently, if as a library author you are shipping dependencies as code, you can use the #if DEBUG preprocessor check to execute logic based on whether app is being built for Debug or Release. My concern is more about the approach that should be taken when distributing frameworks/xcframeworks. One approach I am thinking of using is checking the presence of {CFBundleName}.debug.dylib in the main bundle. Is this approach reliable? Do you suggest any other approach?

When xcode is installed on a mobile phone, the first run always fails. The second run usually works normally.The certificate signatures have been checked and all are normal。This problem will also occur if you stop the running xcode and then run it again。please help me. Mac mini:Apple M2 Pro mas os 15.2 (24C101) Xcode: Version 16.2 (16C5032a) The first failed print is as follows: 无法安装“xxx” Domain: IXUserPresentableErrorDomain Code: 14 Recovery Suggestion: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.uRA3Gt/extracted/Payload/xxx.app : 0xe8008001 (An unknown error has occurred.) User Info: { DVTErrorCreationDateKey = "2025-11-20 02:50:17 +0000"; IDERunOperationFailingWorker = IDEInstallCoreDeviceWorker; } Failed to install the app on the device. Domain: com.apple.dt.CoreDeviceError Code: 3002 User Info: { NSURL = "file:///Users/shenchunxing/Library/Developer/Xcode/DerivedData/VideoGo-dwhfrhswidapcydbmfuamplrtvso/Build/Products/Debug-iphoneos/xxx.app"; } 无法安装“xxx” Domain: IXUserPresentableErrorDomain Code: 14 Failure Reason: 无法安装此App，因为无法验证其完整性。 Recovery Suggestion: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.uRA3Gt/extracted/Payload/xxx.app : 0xe8008001 (An unknown error has occurred.) Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.uRA3Gt/extracted/Payload/xxx.app : 0xe8008001 (An unknown error has occurred.) Domain: MIInstallerErrorDomain Code: 13 User Info: { FunctionName = "+[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:]"; LegacyErrorString = ApplicationVerificationFailed; LibMISErrorNumber = "-402620415"; SourceFileLine = 79; } Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { "device_identifier" = "00008120-0009758221C2201E"; "device_isCoreDevice" = 1; "device_model" = "iPhone15,4"; "device_osBuild" = "18.2 (22C152)"; "device_platform" = "com.apple.platform.iphoneos"; "device_thinningType" = "iPhone15,4"; "dvt_coredevice_version" = "397.28"; "dvt_coresimulator_version" = "993.7"; "dvt_mobiledevice_version" = "1759.60.7"; "launchSession_schemeCommand" = Run; "launchSession_state" = 1; "launchSession_targetArch" = arm64; "operation_duration_ms" = 13228; "operation_errorCode" = 14; "operation_errorDomain" = IXUserPresentableErrorDomain; "operation_errorWorker" = IDEInstallCoreDeviceWorker; "operation_name" = IDERunOperationWorkerGroup; "param_debugger_attachToExtensions" = 0; "param_debugger_attachToXPC" = 1; "param_debugger_type" = 3; "param_destination_isProxy" = 0; "param_destination_platform" = "com.apple.platform.iphoneos"; "param_diag_113575882_enable" = 0; "param_diag_MainThreadChecker_stopOnIssue" = 0; "param_diag_MallocStackLogging_enableDuringAttach" = 0; "param_diag_MallocStackLogging_enableForXPC" = 1; "param_diag_allowLocationSimulation" = 1; "param_diag_checker_tpc_enable" = 1; "param_diag_gpu_frameCapture_enable" = 0; "param_diag_gpu_shaderValidation_enable" = 0; "param_diag_gpu_validation_enable" = 0; "param_diag_guardMalloc_enable" = 0; "param_diag_memoryGraphOnResourceException" = 0; "param_diag_mtc_enable" = 1; "param_diag_queueDebugging_enable" = 1; "param_diag_runtimeProfile_generate" = 0; "param_diag_sanitizer_asan_enable" = 0; "param_diag_sanitizer_tsan_enable" = 0; "param_diag_sanitizer_tsan_stopOnIssue" = 0; "param_diag_sanitizer_ubsan_enable" = 0; "param_diag_sanitizer_ubsan_stopOnIssue" = 0; "param_diag_showNonLocalizedStrings" = 0; "param_diag_viewDebugging_enabled" = 1; "param_diag_viewDebugging_insertDylibOnLaunch" = 1; "param_install_style" = 2; "param_launcher_UID" = 2; "param_launcher_allowDeviceSensorReplayData" = 0; "param_launcher_kind" = 0; "param_launcher_style" = 99; "param_launcher_substyle" = 0; "param_runnable_appExtensionHostRunMode" = 0; "param_runnable_productType" = "com.apple.product-type.application"; "param_structuredConsoleMode" = 1; "param_testing_launchedForTesting" = 0; "param_testing_suppressSimulatorApp" = 0; "param_testing_usingCLI" = 0; "sdk_canonicalName" = "iphoneos18.2"; "sdk_osVersion" = "18.2"; "sdk_variant" = iphoneos; }

I am using a ScrollViewReader, ScrollView, LazyVStack to organize a list of elements I want to be able to scroll to a specific location so i use elementID in the list and a UnitPoint value. But the y value for unitpoint uses -0.1 to represent 100%. Is this intended behavior, a bug, or am i using something incorrectly? I could not find this in the docs and it was only after debugging I found that proxy.scrollTo(id, UnitPoint(x:0, y:-0.1)) is how you scroll to the end of an item or proxy.scrollTo(id, UnitPoint(x:0, y:-0.05)) to scroll to the center. Am I accessing the scrollTo property wrong or is this just how we use it? Also it seems .bottom is broken due to this aswell (as it uses 1 but the actual value that scrolls to the bottom is -0.1). This seems like unintended behvaior as UnitPoints are supposed to be have values of 0-1 Here is a view which reproduces this behavior struct ScrollTestView: View { @State private var scrollToId: String = "" @State private var scrollToAnchorY: String = "0.0" @State private var scrollProxy: ScrollViewProxy? var body: some View { VStack { HStack(spacing: 12) { TextField("Enter ID (1-30)", text: $scrollToId) .frame(width: 120) .padding(8) .background(Color.gray.opacity(0.1)) .cornerRadius(8) TextField("Anchor Y (0-1)", text: $scrollToAnchorY) .frame(width: 120) .padding(8) .background(Color.gray.opacity(0.1)) .cornerRadius(8) Button { guard let targetId = Int(scrollToId), let anchorY = Double(scrollToAnchorY), let proxy = scrollProxy else { return } let anchorPoint = UnitPoint(x: 0.5, y: anchorY) proxy.scrollTo(targetId, anchor: anchorPoint) } label: { Text("Scroll") .font(.subheadline) .padding(.horizontal, 16) .padding(.vertical, 8) .background(Color.blue) .foregroundColor(.white) .cornerRadius(8) } Spacer() } .padding(.horizontal, 16) .padding(.vertical, 8) ScrollViewReader { proxy in ScrollView { LazyVStack { ForEach(1...30, id: \.self) { itemId in VStack { HStack { Text("Item \(itemId)") .font(.title2) .bold() Spacer() } .padding(.vertical, 16) Divider() .background(Color.gray.opacity(0.6)) } .id(itemId) } } .padding() } .onAppear { scrollProxy = proxy } } } } }

After updating my system to macOS Tahoe 26.1 and Xcode 26.1, all breakpoints in my project fail to work. When I run the application in Debug mode, any enabled breakpoint (blue) immediately becomes disabled (grayed out) the moment the app launches. The application runs, but the debugger never stops. This issue occurs in any location, including in the application's init() method, which should always be hit. This behavior suggests that the LLDB debugger is failing to attach to the process at launch or is being instructed not to enable breakpoints. System Configuration: Mac Model: MacBook Pro 14" (2021), Apple M1 Pro macOS Version: Tahoe 26.1 Xcode Version: 26.1 Project Type: SwiftUI App for macOS Troubleshooting Steps Performed (All Unsuccessful): We have performed an extensive series of troubleshooting steps to resolve the issue, none of which have worked. These steps include: Basic Project Cleaning: Cleaned the build folder (Product > Clean Build Folder). Deleted the entire DerivedData directory. Deleted the project's xcuserdata folder. Xcode & System Procedures: Restarted Xcode multiple times. Rebooted the Mac multiple times. Reinstalled Xcode Command Line Tools using xcode-select --install. Reset the Xcode path using sudo xcode-select --reset and sudo xcode-select -s /Applications/Xcode.app/Contents/Developer. Forced an update of the system's shared cache with xcrun simctl runtime dyld_shared_cache update --all. Project Build Settings Verification (for Debug configuration): Build Configuration: Verified that the "Run" scheme is set to Debug. Optimization Level: Confirmed it is set to No Optimization [-O0]. Debug Information Format: Confirmed it is set to DWARF with dSYM File. Strip Swift Symbols: Confirmed it is set to No. (This was a new setting noticed after the Xcode update). Enable Hardened Runtime: Attempted setting this to both Yes and No. The issue persists in both cases. Validate Workspace: Confirmed it is set to Yes. Code Signing: Verified that "Automatically manage signing" is enabled with a valid team. Manually deleted and re-created the "Apple Development" certificates via Xcode's Accounts settings. Direct LLDB Testing: Created a ~/.lldbinit file. Using breakpoint list, confirmed that LLDB starts with "No breakpoints currently set," indicating that Xcode is likely not passing the breakpoints to the debugger. Using settings set target.process.stop-on-entry true, confirmed that the app still does not stop on entry, suggesting the debugger is failing to attach to the process at all. Conclusion: Given that all standard and advanced troubleshooting steps have failed, and the issue started immediately after updating both macOS and Xcode to a non-public release (Tahoe 26.1 / Xcode 26.1), this appears to be a regression or a bug in the new development environment. The failure of stop-on-entry strongly suggests a fundamental issue with the debugger attachment process on this specific OS and Xcode combination.

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 0x00000001845da160 partial apply for closure #1 in _SwiftURL._nsurl.getter + 20 (<compiler-generated>:0) 7 Foundation 0x00000001845da0a0 closure #1 in _SwiftURL._nsurl.getterpartial apply + 16 8 Foundation 0x00000001845d9a6c protocol witness for _URLProtocol.bridgeToNSURL() in conformance _SwiftURL + 196 (<compiler-generated>:974) 9 Foundation 0x000000018470f31c URLRequest.init(url:cachePolicy:timeoutInterval:) + 92 (URLRequest.swift:44)# Live For Studio Any idea if this crash is caused by our code or if it is a known problem in iOS 26? I have attached one of the crash reports from Xcode: 2025-10-08_10-13-45.1128_+0200-8acf1536892bf0576f963e1534419cd29e6e10b8.crash

When I use Xcode 26 (0.1, 1) for debugging and hit a breakpoint, using "step over" causes the debugger to freeze at a random line of code. Clicking "Pause program execution" indicates that the line is being executed, but the breakpoint never exits, seemingly causing a freeze. The application on the simulator also becomes unresponsive. However, when I do not use breakpoints, my program runs smoothly, and debugging on a physical device does not cause any freezes. This issue only occurs with the simulator. I am using Xcode on Apple Silicon, and due to some third-party SDKs that depend on Rosetta, our app can only run on the Rosetta simulator. We did not encounter this issue when using Xcode 16.x for simulator debugging. The current situation with Xcode 26.x significantly reduces our development efficiency. What could be causing this, and is there a solution?

The Center for Innovation in Education created a reading program designed to teach every single child to read, regardless of any supposed difficulty in learning. The Center conducted a ten-year study of its Reading Program’s effectiveness. Over those ten years, the Center placed 2,048 Reading Program kits in classrooms across America. More than 300,000 children took part in the Center’s study. Results: The Reading Program taught every single child to read in every single classroom, every single year, regardless of any child’s supposed reading readiness - including dyslexic, autistic, and even Down syndrome children. No failures then or in any of the many years that have followed. Despite the Program’s success, educational publishers refused to publish it. Their refusals will be explained and hopefully counteracted in a book that is scheduled to be published in 2026. In response to publishers’ refusal to make the program available, the Center made it available as a free download from its website. The Center also made its program available as 14 free iPad apps. While the apps can be searched for individually by their unique names, since the apps are interrelated and meant to complement one another, the first keyword assigned to all 14 apps was the same. That same keyword is still in its first position for every app. The first keyword listed for each of the 14 apps is the word “Dekodiphukan”. That meant-to-be hard-to-read search word has worked well every year since the apps were introduced. However, in June of this year, that search term could find only 1 of the 14 apps. We reported this problem to Apple Support on June 26th. It is now November, and the problem remains unresolved. The only response we receive each time we ask for an update on the resolution of this problem the answer every time is: Reported search issues of this type require extensive review by Apple to determine whether it is valid and to confirm the appropriate action. There is no other response. No update has ever been sent to us. There is no phone number I can find to call. It was suggested to me by someone I spoke with in a different department at Apple Developers that I post my problem on the Developer Forum, in hopes that someone here can provide a suggestion for a way around this problem. Parents and teachers wishing to use our Reading Program with their children should not have to enter 14 different names to access our Reading Program.

I often use a Wi-Fi network where: Whatever mechanism Xcode uses to automatically discover a previously paired iOS device seems to be blocked (the Devices and Simulators window shows "Browsing on the local area network for [iPhone]" and never proceeds), but I can connect to the iOS device from my Mac if I know its IP address, such as by pinging it The same hardware/software configuration works with wireless Xcode connections on a different Wi-Fi network. Thus I'm wondering if there's any functionality that allows the IP address to be manually entered into Xcode to avoid needing to connect a cable from my Mac to my iPhone during development. Searching around seems to suggest this existed at some point in the past but I can no longer find this in a current version of Xcode. Or if there are any other workarounds, although I can't modify the network itself as it's not my network.

Hi, We began to get this new crash in codes that exist years ago from our recent released version, it crashed after a view removed itself from superview. We tried to look at the assembly code of NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex, find out that d0 <= 0 would branch to NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1. We believe that it's related with Autolayout, but setting a negative value for width or height constraints can't reproduce this crash. Here is the crash log Exception Type: NSInternalInconsistencyException Invalid parameter not satisfying: placeValue > 0 Exception Codes: fault addr: (null) Crashed Thread: 0 0 CoreFoundation ___exceptionPreprocess + 164 1 libobjc.A.dylib _objc_exception_throw + 88 2 Foundation -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 CoreAutoLayout NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1 + 100 4 CoreAutoLayout _NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex + 848 5 CoreAutoLayout _NSISSparseVectorAddVectorTimesScalar + 72 6 CoreAutoLayout -[NSISObjectiveLinearExpression replaceVar:withExpression:processVarNewToReceiver:processVarDroppedFromReceiver:] + 200 7 CoreAutoLayout ____substituteOutAllOccurencesOfBodyVar_block_invoke + 504 8 CoreAutoLayout __substituteOutAllOccurencesOfBodyVar + 340 9 CoreAutoLayout __pivotToMakeColNewHeadOfRow + 960 10 CoreAutoLayout -[NSISEngine removeConstraintWithMarker:] + 748 11 CoreAutoLayout -[NSLayoutConstraint _removeFromEngine:] + 140 12 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke + 164 13 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 14 UIKitCore -[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:] + 212 15 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke_2 + 148 16 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke + 544 17 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 18 UIKitCore -[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:] + 212 19 UIKitCore ___45-[UIView(Hierarchy) _postMovedFromSuperview:]_block_invoke + 84 20 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 21 UIKitCore -[UIView _postMovedFromSuperview:] + 512 22 UIKitCore ___UIViewWasRemovedFromSuperview + 136 23 UIKitCore -[UIView(Hierarchy) removeFromSuperview] + 244 Assembly of NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex CoreAutoLayout`NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex: -> 0x1ec1a2124 <+0>: pacibsp 0x1ec1a2128 <+4>: stp d11, d10, [sp, #-0x60]! 0x1ec1a212c <+8>: stp d9, d8, [sp, #0x10] 0x1ec1a2130 <+12>: stp x24, x23, [sp, #0x20] 0x1ec1a2134 <+16>: stp x22, x21, [sp, #0x30] 0x1ec1a2138 <+20>: stp x20, x19, [sp, #0x40] 0x1ec1a213c <+24>: stp x29, x30, [sp, #0x50] 0x1ec1a2140 <+28>: add x29, sp, #0x50 0x1ec1a2144 <+32>: mov x19, x1 0x1ec1a2148 <+36>: fmov d9, d2 0x1ec1a214c <+40>: fmov d10, d1 0x1ec1a2150 <+44>: fmov d8, d0 0x1ec1a2154 <+48>: mov x20, x0 0x1ec1a2158 <+52>: fcmp d0, #0.0 0x1ec1a215c <+56>: b.le 0x1ec1a2470 ; <+844> 0x1ec1a2160 <+60>: fcmp d10, #0.0 0x1ec1a2164 <+64>: adrp x8, 112778 .... 0x1ec1a2468 <+836>: ldp d11, d10, [sp], #0x60 0x1ec1a246c <+840>: retab 0x1ec1a2470 <+844>: bl 0x1ec1cac18 ; NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1 0x1ec1a2474 <+848>: b 0x1ec1a2160 ; <+60>

Since the beta releases of iPadOS 26 we have been having some crashes about Invalid parameter not satisfying: parentEnvironment != nil We got to contact a couple of users and we found out that the crash appears when entering a screen in a UINavigationController with the iPad device connected to a Magic Keyboard. If the device is not connected to the keyboard then nothing happens and everything works ok. From our end we haven't managed to reproduce the crash so I am pasting part of the stacktrace if it can be of any help. 3 UIKitCore 0x19dfd2e14 -[_UIFocusContainerGuideFallbackItemsContainer initWithParentEnvironment:childItems:] + 224 (_UIFocusContainerGuideFallbackItemsContainer.m:23) 4 UIKitCore 0x19dae3108 -[_UIFocusContainerGuideImpl _searchForFocusRegionsInContext:] + 368 (_UIFocusGuideImpl.m:246) 5 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 6 UIKitCore 0x19db28900 -[_UIFocusMapSnapshot addRegionsInContainers:] + 160 (_UIFocusMapSnapshot.m:545) 7 UIKitCore 0x19d1313dc _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 632 (_UIFocusRegion.m:143) 8 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 9 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 10 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 11 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 12 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 13 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 14 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 15 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 16 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 17 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 18 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 19 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 20 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 21 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 22 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 23 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 24 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 25 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 26 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 27 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 28 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 29 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 30 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 31 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 32 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 33 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 34 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 35 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 36 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 37 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 38 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 39 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 40 UIKitCore 0x19d132e08 -[_UIFocusMapSnapshot _capture] + 424 (_UIFocusMapSnapshot.m:403) 41 UIKitCore 0x19db2675c -[_UIFocusMapSnapshot _initWithSnapshotter:mapArea:searchArea:] + 476 (_UIFocusMapSnapshot.m:171) 42 UIKitCore 0x19d130dcc -[_UIFocusMapSnapshotter captureSnapshot] + 192 (_UIFocusMapSnapshotter.m:137) 43 UIKitCore 0x19db2045c -[_UIFocusMap _inferredDefaultFocusItemInEnvironment:] + 136 (_UIFocusMap.m:168) 44 UIKitCore 0x19daffd2c -[_UIFocusEnvironmentPreferenceEnumerationContext _inferPreferencesForEnvironment:] + 140 (_UIFocusEnvironmentPreferenceEnumerator.m:313) 45 UIKitCore 0x19d127ab4 -[_UIFocusEnvironmentPreferenceEnumerationContext _resolvePreferredFocusEnvironments] + 104 (_UIFocusEnvironmentPreferenceEnumerator.m:250) 46 UIKitCore 0x19d127394 -[_UIFocusEnvironmentPreferenceEnumerationContext preferredEnvironments] + 36 (_UIFocusEnvironmentPreferenceEnumerator.m:184) 47 UIKitCore 0x19d126e94 _enumeratePreferredFocusEnvironments + 400 (_UIFocusEnvironmentPreferenceEnumerator.m:503)

Since around September (iOS 26 release), i'm unable to test my app normally. It says "internet connection is required to verify [my certificate id]", or just crashing. All terms and conditions accepted, everything is valid, certificates are OK. Reinstallation via xcode does not help. Removal of provisioning profile, generating new does not help. Revoking of certificate and generating new does for around week, then it happens again, but do i need to do it every week now? In logs i see the following: default amfid validation failed because of missing trust and/or authorization (0xe8008026) error amfid not valid: 0xe8008026: The provisioning profile requires online authorization. error amfid Unexpected MISError (0xe8008026): The provisioning profile requires online authorization. default +0300 amfid /private/var/containers/Bundle/Application/5B8E560E-75B2-46EF-8606-02072D99E9CF//Frameworks/oss.dylib not valid: Error Domain=AppleMobileFileIntegrityError Code=-400 "An unknown error was encountered" UserInfo={NSURL=file:///private/var/containers/Bundle/Application/5B8E560E-75B2-46EF-8606-02072D99E9CF//Frameworks/oss.dylib, NSLocalizedDescription=An unknown error was encountered} default kernel AMFI: code signature validation failed. It looks like apple validation servers are not working, or is it iOS bug? All provisioning profiles are showing like "valid" in apple developer center. My network is not behind a proxy, connection is direct. If use EXACTLY the same app, signed with the same provisioning, same signature, on another test device, it works! When i reset current device to default settings and installing the EXACTLY same app after it, it works as well. Looking for a help from apple developer support

I have an odd issue I'm trying to troubleshoot. I have an app that is deployed to our enterprise and works on almost all of our devices. Lately, I have devices (very small number) where the app installs from our MDM and it crashes upon launch, it does not get past the launch screen. If I remove and reinstall the app from the MDM it still crashes. I decided to put the devices in developer mode and if I run the App from Xcode on the device it works fine. If I stop it and run it right from the device it also works. If I do a final build of the app and install it using "Devices and Simulators", the app crashes upon launch. Using "Devices and Simulators" I check for crash log for the app and no file. I am stumped as to whats going on.

Note This issue has already been reported via Feedback Assistant as FB20512074, but the status is Investigation Complete – Unable to Diagnose with Current Information. Since this bug does not produce a crash log and is therefore difficult to capture through Feedback, I am also posting it here on the Developer Forum to provide additional details and to open discussion. ⸻ Description When formatting floating-point numbers with %a or %A, macOS libc sometimes rounds incorrectly when the guard digit equals 8. This leads to non-conformance with C99’s round-to-nearest, ties-to-even rule. ⸻ Steps to Reproduce #include <stdio.h> int main(void) { // precision 0 printf("%.0a\n", 1.5); printf("%.0a\n", 1.53); printf("%.0a\n", 1.55); printf("%.0a\n", 1.56); // precision 1 printf("%.1a\n", 0x1.380p+0); printf("%.1a\n", 0x1.381p+0); printf("%.1a\n", 0x1.382p+0); printf("%.1a\n", 0x1.383p+0); return 0; } Expected Results (per C99/C11) %.0a with inputs (1.5, 1.53, 1.55, 1.56): 0x2p+0 0x2p+0 0x2p+0 0x2p+0 %.1a with inputs (0x1.380p+0, 0x1.381p+0, 0x1.382p+0, 0x1.383p+0): 0x1.4p+0 0x1.4p+0 0x1.4p+0 0x1.4p+0 Actual Results (macOS observed) %.0a with inputs (1.5, 1.53, 1.55, 1.56): 0x1p+0 0x2p+0 0x1p+0 0x2p+0 %.1a with inputs (0x1.380p+0, 0x1.381p+0, 0x1.382p+0, 0x1.383p+0): 0x1.3p+0 0x1.4p+0 0x1.3p+0 0x1.4p+0 This shows that values slightly above half are sometimes treated as ties and rounded down incorrectly. ⸻ Root Cause Analysis Inside Libc/gdtoa/FreeBSD/_hdtoa.c, rounding is decided in dorounding(): if ((s0[ndigits] > 8) || (s0[ndigits] == 8 && (s0[ndigits + 1] & 1))) adjust = roundup(s0, ndigits); This logic has two mistakes: Half detection Correct: When the guard nibble is 8, all lower discarded digits must be checked. Current: Only the LSB of the next nibble is checked (& 1). Consequence: Cases like ...8C... (e.g. 1.55 ≈ 0x1.8C…) are strictly greater than half, but are treated as exact halves and rounded down. Tie-to-even parity check Correct: For a true half (all lower digits zero), rounding should use the parity of the last kept digit. Current: The code incorrectly uses the parity of the next discarded nibble instead. Consequence: True ties are not rounded to even reliably. ⸻ Proposed Fix (behavioral) if (s0[ndigits] > 8) { adjust = roundup(...); // strictly > half } else if (s0[ndigits] == 8) { if (any_nonzero_tail(s0 + ndigits + 1)) { adjust = roundup(...); // > half } else { // exact tie: round-to-even if (s0[ndigits - 1] & 1) adjust = roundup(...); } } ⸻ Impact This bug is not limited to %.0a; it occurs for any precision when the guard nibble is 8. It causes exact halves to round incorrectly and greater-than-half values to be rounded down. The effect is alternating outputs (zigzag) instead of consistent monotonic rounding. This is a C99 compliance violation.