If you need help investigating a crash, please include a crash report in your post. To smooth things along, follow these guidelines: For information on how to get a crash report, see Acquiring crash reports and diagnostic logs. Include the whole crash report as a text attachment (click the paperclip icon and then choose Add File). This avoids clogging up the timeline while also preserving the wealth of information in the crash report. If you’re not able to post your crash report as an attachment, see Can’t Post Crash Report as Attachment below. If you want to highlight a section of the report, include it in the main body of your post. Put the snippet in a code block so that it renders nicely. To create a code block, add a delimiter line containing triple backquotes before and after the block, or just click the Code Block button. If possible, post an Apple crash report. Third-party crash reporters are often missing critical information and have general reliability problems (for an explanation as to why, see Implementing Your Own Crash Reporter). Symbolicate your crash report before posting it. For information on how to do this, see Adding identifiable symbol names to a crash report. If you need to redact the crash report, do so consistently. Imagine you’re building the WaffleVarnish app whose bundle ID is com.example.wafflevarnish but you want to keep your new waffle varnishing technology secret. Replace WaffleVarnish with WwwwwwVvvvvvv and com.example.wafflevarnish with com.eeeeeee.wwwwwwvvvvvvv. This keeps the text in the crash report aligned while making it possible to distinguish the human-readible name of the app (WaffleVarnish) from the bundle ID (com.example.wafflevarnish). Finally, for information on how to use a crash report to debug your own problems, see Diagnosing issues using crash reports and device logs. Can’t Post Crash Report as Attachment Crash reports have two common extensions: .crash and .ips. If you have an .ips file, please post that [1]. DevForums lets you attach a .crash file but not an .ips file (r. 117468172). To work around this, change the extension to .txt. If DevForums complains that your crash report “contains sensitive language”, leave it out of your initial post and attach it to a reply. That often avoids this roadblock. If you still can’t post your crash report, upload it to a file sharing service and include the URL in your post. Post the URL in the clear, per tip 14 in Quinn’s Top Ten DevForums Tips. Getting a Crash Report from the Xcode Organiser The Xcode organiser shows crash reports from customers. If you’re investigating such a crash and want to post a crash report: Navigate to the crash in the Xcode organiser. Note If you can’t see the right crash, check the filter popups at the top. In the list of crashes, secondary click on your crash and choose Show in Finder. That reveals the Xcode crashpoint document (.xccrashpoint) in the Finder. Secondary click on that and choose Show Package Contents. In the resulting Finder window, find a crash report (.crash) that accurately represents the crash you’re investigating and attach that to your forums post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Because it’s easy to go from an .ips file to a .crash file. I usually do this by choosing File > Quick Look in the Finder. For more info about these file formats, see this post. Revision History: 2025-08-29 Added the Getting a Crash Report from the Xcode Organiser section. 2024-11-21 Added a recommendation to post the .ips format if possible. 2024-05-21 Added some advice regarding the “contains sensitive language” message. 2023-10-25 Added the Can’t Post Crash Report as Attachment section. Made other minor editorial changes. 2021-08-26 First posted.

General: DevForums tags: Debugging, LLDB, Graphical Debugger Xcode > Debugging documentation Diagnosing memory, thread, and crash issues early documentation Diagnosing issues using crash reports and device logs documentation Choosing a Network Debugging Tool documentation Testing a release build documentation Isolating Code Signing Problems from Build Problems DevForums post What is an exception? DevForums post Language Exception from RCTFatal DevForums post Standard Memory Debugging Tools DevForums post Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem DevForums post Posting a Crash Report DevForums post Creating a test project DevForums post Implementing Your Own Crash Reporter DevForums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi team, I'm looking for the RealityKit debugger in Xcode 26 beta 3. I'm running a RealityKit app on my iPad running iPadOS 26 b3, but the debugger option is not there in Xcode.

Fatal safeAreaInsets Error on Certain iOS/iPadOS 26 Devices On certain devices that have updated to iOS/iPadOS 26, the safeAreaInsets value is displayed incorrectly when rotating. On the iPhone SE3, the safeAreaInsets.top value is displayed inverted when rotating. It should return 20.0 when rotated vertically and 0.0 when rotated horizontally. Currently, the value is reversed. (0.0 when rotated horizontally and 20.0 when rotated vertically.) On iPad Pro devices, the safeAreaInsets.top value is always returned as 0.0 when the app is first launched. (This issue is believed to occur on all iPad devices, including the iPad Pro.) If the user subsequently rotates the iPad, the safeAreaInsets value is returned correctly. On the iPhone 17 with dynamic islands, the safeAreaInsets value is displayed correctly. My guess is that all devices running iOS/iPadOS 26 without dynamic islands will experience an issue where the safeAreaInsets value is displayed incorrectly. This issue occurs when building with Xcode 26. Apple, please issue an OS update as soon as possible. Or, if this is an Xcode issue, please update Xcode.

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.

After updating to Xcode 26 RC on Tahoe 26 RC and iOS 26 RC (and now final version of both Tahoe and iOS). I'm still unable to debug on device. I've tried rebooting, resetting settings, cleaning trusted computers. I ran out of ideas, I was expecting that final versions would fix this but they didn't.

As of now, there is no Kernel Debug Kit (KDK) available for macOS 26.0 Developer Betas after the first build. Kernel Debug Kits are crucial for understanding panics and other bugs within custom Kernel Extensions. Without the KDK for the corresponding macOS version, tools like kmutil fail to recognize a KDK and certain functions are disabled. Additionally, as far as I am aware, a KDK for one build of macOS isn't able to be used on a differing build. Especially since this is a developer beta, where developers are updating their software to function with the latest versions of macOS, I'd expect a KDK to be available for more than one build.

"Build input file cannot be found" error occurs in Archive. When running Archive to generate a build file, the build file generation fails with a "Build input file cannot be found: ..." error. When debugging, the build runs fine on the actual device without any errors. Comparing and modifying the Build Settings with other projects doesn't fix the issue. Deleting the Swift file and attempting to Archive results in a crash due to the missing file. Even after deleting and adding the Swift file, the same error persists when attempting to Archive. Even after deleting and re-adding the Swift file, the issue persists even after deleting all DerivedData file space on my Mac and restarting Xcode. Can you help me with this issue? It worked fine before the recent macOS update, and I successfully archived and published it to the App Store a few days ago. I believe this issue occurred after updating macOS to 26.0.1. My Xcode version is 26.0.1.

Hi, I recently upgraded my device OS to 26.0 and XCode is on Version 26.0.1 (17A400) My XCode log is getting spammed with these types of errors all of a sudden. And filtering is so limited (filter a single item at a time) I can't remove them. It says to file a bug, can you folks PLEASE fix this it is making debugging really hard with all its noise. Unable to update Font Descriptor's weight to Weight(value: 0.3): UICTFontDescriptor <0x110e40180> = { NSFontNameAttribute = "SF Pro Display"; NSFontSizeAttribute = 16; } - SwiftUICore/Logging.swift:84 - please file a bug report. and UICTFontDescriptor <0x1181062e0> = { NSFontNameAttribute = "Inter Display"; NSFontSizeAttribute = 28; } - SwiftUICore/Logging.swift:84 - please file a bug report.

I have published a number of games that use SpriteKit for everything important. Since the release of macOS Tahoe, I've had a lot of end user reports saying that sound effects have stopped working in many (but not all) of my titles. I'm not doing anything unusual here – typical code is: sndGameOver = [SKAction playSoundFileNamed:@"Audio/GameOver.wav" waitForCompletion:YES]; Then at the appropriate time: [self runAction:sndGameOver]; Has anyone else encountered this? The code still works fine on previous operating systems, and appears to be fine on iOS too. Has something changed in macOS Tahoe? I'm at a bit of a loss. There's nothing obviously different between the titles that do work and the titles that don't. Suggestions welcomed! Thanks

When utilizing Paperkit in its simplest form, PaperMarkupViewController does not show the option to add images. Furthermore, trying to add images directly to the PaperMarkup's insertNewImage() function does not display anything. It seems like image functionality is entirely broken on Xcode 26. This can be seen through the following example done by a fellow member here on the forums: https://gist.github.com/clarkezone/68eb3ee13b5607782ceb2e20cece4ab3

I recently installed Xcode 26.0.1. (MacBook Pro 16, M2 Max, 64GB memory, macOS 26.0 (25A354)) Normally, when debugging, a red error appears in the left-hand Issues navigation, and you can click on it to access the location of the error. However, currently, when debugging, the red error does not appear in the "Issue Navigation" on the left-hand side of the Xcode screen. There is an error, but it isn't displayed. It does appear, but disappears after 1 second. (It disappears before I can click on it.) The error doesn't appear or disappears after 1 second, so I can't pinpoint the exact location. Please help me resolve this issue. Additionally, I deleted all Xcode development-related files inside my Mac and restarted my MacBook, but the symptom still persists.

I'm developing a web extension for Safari on iOS using MV3. The extension is working fine in Chrome, but in Safari I experience some seemingly random issues. I would like to debug it, but here is my problem. I have my iPhone connected via cable to Mac, and it works fine with XCode, so I assume this part is OK. I open Safari or Safari Tech Preview (doesn't matter) on my Mac, developers options are enabled, and in the Develop menu, under my iPhone section, there are things I can debug. There is an entry "[Ext name] - Extension Service Worker" but when I click it, it's empty. Web inspector pops up, but there are no network requests, no logs, nothing. I know the extension is working, because I can stream log to my HTTP server, but I don't see them here at all. I can use console to trigger commands like chrome.storage.local.get(null, console.log) and it shows my local store, so why I don't see any logs? Also, the background script is not visible in the Sources tab, just one weird request: navigator.serviceWorker.register('safari-web-extension://E3449EA7-EC25-4696-8E6C-[ID HERE]/background.js'); </script> Any ideas what went wrong? The entire team of 4 people has the same issue and we can't move forward because of that. Also, the Develop => Service workers or any other menu section doesn't show my service worker. Logs for websites running on my phone are visible and in general web inspector for them works fine.

Hello, I'm trying to use Xcode's ARKit Session replay functionality. I have a capture I made using Reality Composer and when trying to use it with Xcode's replay functionality the installation and debugging process seems stalled forever. I've gotten it to work once so I know the capture file is functional but I have never gotten it to work a second time, even though I didn't change any settings. No amount of restarting Xcode, the Mac, or the iPhone seem to work. I have also tried cleaning build folders, reinstalling the app, and clearing DerivedData. I can confirm from the Xcode logs that the app installs correctly but the app never launches. If I unselect the checkbox for "ARKit Replay Data", the app launches and debugs nearly instantly. I have tried letting it "attach" for up to 10 minutes to no avail.

Our app has an old codebase, originating in 2011, which started out as purely Objective-C (and a little bit of Objective-C++), but a good amount of Swift has been added over time as well. Lots of Objective-C and Swift inter-op, but in general very few 3rd party libraries/frameworks. Like many other codebases of this size and age, we have a good amount of accumulated tech debt. In our case, that mostly comes in the form of using old/deprecated APIs (OpenGL primary amongst them), and also using some ‘tricks’ that allowed us to do highly customized UI popups and the like before they were officially supported by iOS, but unfortunately are still in use to this day (i.e. adding views directly to the UIWindow such that that are ‘on top’ of everything, instead of presenting a VC). Overall though, the app is very powerful and capable, and generally has a relatively low crash rate. About two months ago, we started seeing some new crashes that seemed to be totally unrelated to the code changes that were made at the time. Moreover, if a new branch with a feature or bug fix was merged in, the new crash would either disappear entirely, or move somewhere else. These were not ‘normal’ crashes either - when hooked up to the debugger in Xcode, often times the crashes would happen when calling into system library (e.g. initializing a UIColor object). Some of the steps taken to try and mitigate or eliminate these crashes include: Rolling back merges Often worked, but then most future merges would cause a new and different crash to appear Using the TSan and ASan tools to try and diagnose thread or memory issues TSan reported a couple of issues near launch that have been fixed, and there are others in some areas of the app, but they have been around a long time and don’t appear to correlate with any recent changes, nor did fixing the ones at launch (and throughout testing to try and reproduce crashes) result in elimination of the new crashes ASan does not identify any issues Modifying the code changes in a branch before merging it in In one case where the changes were limited to declaring ‘@objc static var: Bool’ in a Swift class and setting a value to it in a couple of places, simply removing the @objc from the declaration would result in the crash going away. Since the var had to be exposed to Objective-C, it was eventually moved to a pure Objective-C class that already existed and is a singleton (not ideal, but it’s been around a long time and has not yet been refactored) in order to preserve the functionality and the crash was no longer reproducible Removing all 3rd party libraries or frameworks Not a long-term solution, and this mostly worked in that the crashes went away, but it also resulted in removal of long-existing features expected by our users Updating 3rd party libraries and frameworks when possible (there were some very old ones) Updating these did not have any effect on the crashes, except that the crashes moved around in the same way as when merging in a branch, and again, where the crash actually occurred was uncorrelated with the library/framework that was updated Changes to the App’s Build Settings in Xcode Set supported/valid architectures to arm64 exclusively Stripping of all architectures other than arm64 from 3rd party binaries Cleaning up of old/outdated linker flags Removal of other custom build flags that were needed at one point, but are no longer relevant Generally trying to make all the build settings in our (quite old/outdated) app match those of a newly created iOS app Code signing inject base entitlements is set to YES Removal of old/deprecated BitCode flag These changes seemed to help and the codebase was more ‘stable’ (non-crashing) for a while, but as we tried to continue development, the crashes would reappear Getting crash reports off of test devices and analyzing them based on the various documents about crash reports provided by Apple This was helpful and pointed to new things to investigate, but ultimately did not help to identify the root cause of these crashes Throughout all of the above, the crashes would come and go, very reproducibly for a given branch being merged in, but if a subsequent branch is merged in, the crash may go away, or simply move somewhere else - sometimes it would crash in our code that calls other parts of our code, and other times when calling system frameworks (like the UIColor example above). One thing that is consistent though, is that the crash would never happen anywhere near the code that was changed or added by a branch that was merged in. Additional observations when trying to figure out the cause of these crashes: Sometimes the smallest code change would result in a crash happening or not The crash reports generated on-device vary quite a bit in terms of the type and reason for the crash All crashes have an Exception Type of EXC_BAD_ACCESS, but vary between (SIGABRT) (SIGBUS) (SIGKILL) (SIGSEV) The crashing thread is often (but not always) on Thread 0 (main thread), and often the first line in the backtrace would be just ‘???’, sometimes followed by a valid memory address and file, but often times just ‘0x0 ???’ Most crash reports have an exception subtype of KERN_PROTECTION_FAILURE Many also state that the Termination Reason is ‘CODESIGNING 2 Invalid Page’ This in particular was investigated thoroughly, including looking at the Placing Content In A Bundle document but after further changes to ensure that everything is in the right place, the crashes were still observed Another odd thing in most of the crash reports is in the Binary Images section, there is a line that once again is mostly ???s or 000s - specifically ‘0x0 - 0xffffffffffffffff ??? unknown-arch <00000000000000000000000000000000> ???’ The crashes occur on different physical devices, typically the same crash for a given branch, and regardless of iOS version This includes building from different Macs. We did observe some differences between versions of Xcode (crashed similarly when built from an older version of Xcode, but not from a newer one), but we recently had all developers ensure they are running Xcode 16.4 - we also tried Xcode 26, but the crashes were still observed Overall, it seems like there is something very strange going on in terms of how the App binary is constructed such that a small code change somehow affects the binary in such a way that memory is not being accessed correctly, or is not where it is expected to be. This level of what appears to be a build-time issue that manifests in very strange run-time crashes is both confusing and difficult to diagnose. Despite the resources provided by Apple for investigation and diagnosis, we cannot seem to find a root cause for these crashes and eliminate them for good.

Hello - Upon enabling debug mode for GameKit configuration for my iOS app, I do not see any devices (my iPhone or simulators) in the device list within the "Manage Game Progress" debug tool. I only see my Mac as a device. Is there any trick to this or a way to add devices to this list? Thank you

Hello. I am using Xcode 26.0 (17A324) with an iPhone 13 mini with iOS 26.0 (23A341). Due the network policies where my computer is at this moment, I am not able to prepare this iPhone to debug applications with Xcode over WiFi. There is no way to connect my computer to this iPhone over Wifi, just using the USB cable. My question is: how to debug applications in this situation, only using the USB cable? Every time I try to prepare this iPhone to be a available device to Xcode I received this error: " Browsing on the local area network for iPhone (2), which has previously reported preparation errors. Ensure the device is unlocked and attached with a cable or associated with the same local area network as this Mac. The device must be opted into Developer Mode to connect wirelessly. Unable to copy shared cache files Domain: com.apple.dt.deviceprep Code: -33 User Info: { DVTErrorCreationDateKey = "2025-09-22 11:57:35 +0000"; NSLocalizedRecoverySuggestion = ""; "com.apple.dt.DVTCoreDevice.operationName" = dtfetchsymbols; } The operation couldn’t be completed. No route to host Domain: NSPOSIXErrorDomain Code: 65 Failure Reason: No route to host System Information macOS Version 15.6.1 (Build 24G90) Xcode 26.0 (24228) (Build 17A324) Timestamp: 2025-09-22T08:57:35-03:00 " Thank you!

We are building a CarPlay app and have run into an issue with data updates. When the app is running on the CarPlay display and the iPhone screen is locked, no data updates are shown on the CarPlay screen. As soon as the phone is unlocked, the data updates appear instantly on the CarPlay display. Has anyone encountered this behavior before? Is there a specific setting, entitlement, or background mode we need to enable in order to ensure the CarPlay app continues to receive and display data while the iPhone is locked? Any guidance would be greatly appreciated.

When I run my app from Xcode on a device running iOS 26, the roomplan capture is corrupted and the recording is green and purple. This issue does not occur when I use an older version of iOS or when I run the app via testFlight or the App Store.

I’ve noticed a strange bug in Xcode 16 and Swift. When a preview is rendering and hasn’t finished yet and you run an app to debug, Xcode is launching two instances of the app. Has anyone else noticed this issue? If you let the preview finish rendering before running the app, this doesn’t happen. Very odd.

Hi! I've encountered strange bug in iOS 26. The MultiDatePicker component exhibits unreliable behavior when attempting to deselect previously chosen dates. Users often need to tap a selected date multiple times (e.g., tap to deselect, tap to re-select, then tap again to deselect) for the UI to correctly register the deselection and update the displayed state. This issue does not occur on iOS 18 or Xcode 26 previews, where MultiDatePicker functions as expected, allowing single-tap deselection. The bug only occurs on physical device or simulator. I can't lie, I have multidatepicker as crucial component in my larger app and can't really find a solution to this. Has anyone encountered this problem before? Here is the code to replicate the issue: import SwiftUI struct ContentView: View {     @ State private var selectedDates: Set = []     var body: some View {         NavigationStack {             Form {                 Section {                     MultiDatePicker("Select Dates", selection: $selectedDates)                 } header: {                     Text("MultiDatePicker Bug Test")                 }                 Section {                     Text("Selected Dates Count: (selectedDates.count)")                     ForEach(Array(selectedDates).sorted(by: {                         Calendar.current.date(from: $0)! < Calendar.current.date(from: $1)!                     }), id: .self) { dateComponent in                         if let date = Calendar.current.date(from: dateComponent) {                             Text(date.formatted(date: .long, time: .omitted))                         }                     }                 } header: {                     Text("Current State of Selected Dates")                 }             }             .navigationTitle("Date Picker Bug")         }     } } #Preview {     ContentView() }

I got users feed back, sometimes they seem the launch screen after active from background, and the launch screen show more longer than the cold launch. I check the app's log, when this issue happens, it displays a view controller named 'STKPrewarmingViewController', and disappears after about 5 seconds. And form the normal users, app don't have same behavior. It seems app need prewarming after back from background, why? Devices System version: iOS 18.4, app build with Xcode 16. How to fixed this issues? Thanks!