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!

Hey all! in my personal quest to make future proof apps moving to Swift 6, one of my app has a problem when setting an artwork image in MPNowPlayingInfoCenter Here's what I'm using to set the metadata func setMetadata(title: String? = nil, artist: String? = nil, artwork: String? = nil) async throws { let defaultArtwork = UIImage(named: "logo")! var nowPlayingInfo = [ MPMediaItemPropertyTitle: title ?? "***", MPMediaItemPropertyArtist: artist ?? "***", MPMediaItemPropertyArtwork: MPMediaItemArtwork(boundsSize: defaultArtwork.size) { _ in defaultArtwork } ] as [String: Any] if let artwork = artwork { guard let url = URL(string: artwork) else { return } let (data, response) = try await URLSession.shared.data(from: url) guard (response as? HTTPURLResponse)?.statusCode == 200 else { return } guard let image = UIImage(data: data) else { return } nowPlayingInfo[MPMediaItemPropertyArtwork] = MPMediaItemArtwork(boundsSize: image.size) { _ in image } } MPNowPlayingInfoCenter.default().nowPlayingInfo = nowPlayingInfo } the app crashes when hitting MPMediaItemPropertyArtwork: MPMediaItemArtwork(boundsSize: defaultArtwork.size) { _ in defaultArtwork } or nowPlayingInfo[MPMediaItemPropertyArtwork] = MPMediaItemArtwork(boundsSize: image.size) { _ in image } commenting out these two make the app work again. Again, no clue on why. Thanks in advance

ICEcard app is "Emergency as a Service" platform. One of the key feature is to know about primary info, health info, or in case missing child , elderly using Face scan of registered user of app via another registered user of ICEcard app. App was working fine but last 2-3 week back got issue reported of app getting closed as soon Face scan option is selected. to simulate issue > register > open face scan icon at bottom home screen> select any of option accident or health issue or information >> app closes immediately. Android app is working fine. link of app store. https://apps.apple.com/in/app/ice-card-app/id6736453602 android link for reference https://play.google.com/store/apps/details?id=com.rannlab.ice_card.ice_card&pcampaignid=web_share

dSYM size became thrice for builds generated via xcode 26 compared to xcode 16. These are all release builds.

Xcode will transfer the app to the iPhone, and I can run it on the iPhone, but the Xcode debugger fails to attach. I am using iPhone 14 Pro with iOS 18.6. I've tried connecting via cable, also via network - same issue both ways. The message raised by Xcode says: Could not attach to pid: "6303" Ensure “<a\AppName>” is not already running, and has permission to debug it. I don't know how to determine if I have permission. I assume I do; I am the owner of the account, with admin role.

I am trying to debug the AAX version of my plugin (MIDI effect) on Pro Tools, but I am getting the following error (Mac console) when attempting to load it: dlsym cannot find symbol g_dwILResult in CFBundle etc.. I used Xcode 16.4 to build the plugin. Has anybody come across the same or a similar message? Best, Achillefs Axart Labs

When the app launches, it assigns the correct string stored in NSUserDefaults to the instance variable (serverAddress) of type NSString.
Afterwards, when the app transitions to a suspended state and receives a VoIP Push notification approximately 4 hours later, causing the app to enter the background state, referencing the value of serverAddress may result in it showing as &lt;NSMallocBlock: 0x106452d60&gt; even though it hasn't been deallocated. This does not occur every time. The specific class definitions are as follows. @implementation NewPAPEOPLEClient
{
    NSString* serverAddress;
    NSString* apiKey;
    dispatch_semaphore_t lock;
    NSMutableArray* errCallID;
} #define PREF_STR(key)  [[NSUserDefaults standardUserDefaults] stringForKey:(key) The global instance variable (serverAddress) is set with the following value when the application starts: serverAddress = PREF_STR(@"APP_CONTACT_SERVICE_SERVER_ADDRESS") Based on the above, please answer the following questions. (1) If the instance variable's value becomes &lt;NSMallocBlock: 0x106452d60&gt;, does that mean the memory area has been released? (2) Can the memory area of an instance variable be automatically released without being explicitly released?
 Can an instance variable of type NSString that is not autoreleased be automatically released? (3) Please tell me how to prevent the memory area from being automatically released. Will using retain prevent automatic release?

I have been using tvOS 18 and Xcode 26 all summer without issue but since updating the tv to the latest tvOS 26 beta I am now unable to attach to debug builds. When using the Run button in Xcode the build completes, the tv screen goes black and then I see a warning in Xcode: Launching "App Name" is taking longer than expected. Do you want to continue to wait? LLDB is likely reading from device memory to resolve symbols. If I continue to wait after around 5 mins, in the Xcode console, I see: warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not find the on-disk shared cache for this device. This will likely reduce debugging performance. But the process on the tv hangs indefinately. Hitting stop in Xcode disconnects the debugger but the app then finishes launching successfully on the TV. Trying to use "Debug > Attach to process > [App Name]" once it is running also just hangs the app and waits until stopped. When stopping the hung debugger I see an Xcode error with the following: Could not attach to pid : “1222” Domain: IDEDebugSessionErrorDomain Code: 3 Failure Reason: internal error User Info: { DVTErrorCreationDateKey = "2025-09-01 09:51:54 +0000"; DVTRadarComponentKey = 855031; IDERunOperationFailingWorker = DBGLLDBLauncher; RawUnderlyingErrorMessage = "Xcode has killed the LLDB RPC server to allow the debugger to detach from your process. You may need to manually terminate your process."; } -- Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { "device_identifier" = "00008110-000240CE1A87801E"; "device_isCoreDevice" = 1; "device_isWireless" = 1; "device_model" = "AppleTV14,1"; "device_osBuild" = "26.0 (23J5348a)"; "device_osBuild_monotonic" = 2309534800; "device_os_variant" = 1; "device_platform" = "com.apple.platform.appletvos"; "device_platform_family" = 4; "device_reality" = 1; "device_thinningType" = "AppleTV14,1"; "device_transport" = 2; "launchSession_schemeCommand" = Run; "launchSession_schemeCommand_enum" = 1; "launchSession_targetArch" = arm64; "launchSession_targetArch_enum" = 6; "operation_duration_ms" = 76122; "operation_errorCode" = 3; "operation_errorDomain" = IDEDebugSessionErrorDomain; "operation_errorWorker" = DBGLLDBLauncher; "operation_error_reportable" = 1; "operation_name" = IDERunOperationWorkerGroup; "param_consoleMode" = 0; "param_debugger_attachToExtensions" = 0; "param_debugger_attachToXPC" = 1; "param_debugger_type" = 3; "param_destination_isProxy" = 0; "param_destination_platform" = "com.apple.platform.appletvos"; "param_diag_MainThreadChecker_stopOnIssue" = 0; "param_diag_MallocStackLogging_enableDuringAttach" = 0; "param_diag_MallocStackLogging_enableForXPC" = 0; "param_diag_allowLocationSimulation" = 0; "param_diag_checker_mtc_enable" = 0; "param_diag_checker_tpc_enable" = 0; "param_diag_gpu_frameCapture_enable" = 0; "param_diag_gpu_shaderValidation_enable" = 0; "param_diag_gpu_validation_enable" = 1; "param_diag_guardMalloc_enable" = 0; "param_diag_memoryGraphOnResourceException" = 0; "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" = 256; "param_lldbVersion_component_idx_1" = 0; "param_lldbVersion_monotonic" = 170300300002; "param_runnable_appExtensionHostRunMode" = 0; "param_testing_launchedForTesting" = 0; "param_testing_suppressSimulatorApp" = 0; "param_testing_usingCLI" = 0; "sdk_canonicalName" = "appletvos26.0"; "sdk_osVersion" = "26.0"; "sdk_platformID" = 3; "sdk_variant" = appletvos; "sdk_version_monotonic" = 2309534400; } -- System Information macOS Version 26.0 (Build 25A5349a) Xcode 26.0 (24208.14) (Build 17A5305k) Timestamp: 2025-09-01T10:51:54+01:00 I have another AppleTV still running on tvOS 18 and builds continue to run and attach fine there. I've tried rebooting the 26 beta AppleTV but I'm at a bit of a loss what else to try?

Hello, I have a Cocoa application from which I fork a new process (helper sort of) and it crashes on fork due to some cleanup code probably registered with pthreads_atfork() in Network framework. This is crash from the child process: Application Specific Information: *** multi-threaded process forked *** BUG IN CLIENT OF LIBPLATFORM: os_unfair_lock is corrupt Abort Cause 258 crashed on child side of fork pre-exec Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_platform.dylib 0x194551238 _os_unfair_lock_corruption_abort + 88 1 libsystem_platform.dylib 0x19454c788 _os_unfair_lock_lock_slow + 332 2 Network 0x19b1b4af0 nw_path_shared_necp_fd + 124 3 Network 0x19b1b4698 -[NWConcrete_nw_path_evaluator dealloc] + 72 4 Network 0x19af9d970 __nw_dictionary_dispose_block_invoke + 32 5 libxpc.dylib 0x194260210 _xpc_dictionary_apply_apply + 68 6 libxpc.dylib 0x19425c9a0 _xpc_dictionary_apply_node_f + 156 7 libxpc.dylib 0x1942600e8 xpc_dictionary_apply + 136 8 Network 0x19acd5210 -[OS_nw_dictionary dealloc] + 112 9 Network 0x19b1beb08 nw_path_release_globals + 120 10 Network 0x19b3d4fa0 nw_settings_child_has_forked() + 312 11 libsystem_pthread.dylib 0x100c8f7c8 _pthread_atfork_child_handlers + 76 12 libsystem_c.dylib 0x1943d9944 fork + 112 (...) I'm trying to create a child process with boost::process::child which does basically just a fork() followed by execv() and I do it before the - [NSApplication run] is called. Is it know bug or behavior which I've run into? Also what is a correct way to spawn child processes in Cocoa applications? As far as my understanding goes the basically all the available APIs (e.g. posix, NSTask) should be more or less the same thing calling the same syscalls. So forking the process early before main run loop starts and not starting another NSApplication in forked child should be ok ...or not?

We are experiencing troubles in our organization when we want to debug iOS applications on physical iPhones and iPads. Our iPhones (iPhone 16e, iOS 18.5) are not recognized by Xcode 16.4, but in the Finder they show up fine using the USB cable. We are aware, that the communication is different and there is an ad-hoc network that gets created to exchange the device profile. Together with our IT department responsible for our security infrastructure we narrowed it down to the following reason: As we are blocking all IPv6 traffic for local networking, the iPhone cannot communicate with Xcode to make the first connection and load the device profile. As they are not planning on changing this behavior, I am reaching out to you, if there is a way to force this first handshake between Xcode and iOS device to use IPv4? Or is there any other way to enable debugging for these devices? Any ideas would be very helpful.

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.

There are multiple report of crashes on URLConnectionLoader::loadWithWhatToDo. The crashed thread in the stack traces pointing to calls inside CFNetwork which seems to be internal library in iOS. The crash has happened quite a while already (but we cannot detect when the crash started to occur) and impacted multiple iOS versions recorded from iOS 15.4 to 18.4.1 that was recorded in Xcode crash report organizer so far. Unfortunately, we have no idea on how to reproduce it yet but the crash keeps on increasing and affect more on iOS 18 users (which makes sense because many people updated their iOS to the newer version) and we haven’t found any clue on what actually happened and how to fix it on the crash reports. What we understand is it seems to come from a network request that happened to trigger the crash but we need more information on what (condition) actually cause it and how to solve it. Hereby, I attach sample crash report for both iOS 15 and 18. I also have submitted a report (that include more crash reports) with number: FB17775979. Will appreciate any insight regarding this issue and any resolution that we can do to avoid it. iOS 15.crash iOS 18.crash

I often get questions about third-party crash reporting. These usually show up in one of two contexts: Folks are trying to implement their own crash reporter. Folks have implemented their own crash reporter and are trying to debug a problem based on the report it generated. This is a complex issue and this post is my attempt to untangle some of that complexity. If you have a follow-up question about anything I've raised here, please put it in a new thread with the Debugging tag. IMPORTANT All of the following is my own direct experience. None of it should be considered official DTS policy. If you have a specific question that needs a direct answer — perhaps you’re trying to convince your boss that implementing your own crash reporter is a very bad idea — start a dedicated thread here on the forums and we can discuss the details there. Use whatever subtopic is appropriate for your issue, but make sure to add the Debugging tag so that I see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Scope First, I can only speak to the technical side of this issue. There are other aspects that are beyond my remit: I don’t work for App Review, and only they can give definitive answers about what will or won’t be allowed on the store. Implementing your own crash reporter has significant privacy implications. IMPORTANT If you implement your own crash reporter, discuss the privacy impact with a lawyer. This post assumes that you are implementing your own crash reporter. A lot of folks use a crash reporter from another third party. From my perspective these are the same thing. If you use a custom crash reporter, you are responsible for its behaviour, both good and bad, regardless of where the actual code came from. Note If you use a crash reporter from another third party, run the tests outlined in Preserve the Apple Crash Report to verify that it’s working well. General Advice I strongly advise against implementing your own crash reporter. It’s very easy to create a basic crash reporter that works well enough to debug simple problems. It’s impossible to implement a good crash reporter, one that’s reliable, binary compatible, and sufficient to debug complex problems. The bulk of this post is a low-level explanation of that impossibility. Rather than attempting the impossible, I recommend that you lean in to Apple’s crash reporter. In recent years it’s acquired some really cool new features: If you’re creating an App Store app, the Xcode organiser gives you easy, interactive access to Apple crash reports. If you’re an enterprise developer, consider switching to Custom App Distribution. This yields all the benefits of App Store distribution without your app being generally available on the store. iOS 14 and macOS 12 report crashes in MetricKit. This is a very cool feature, and I’m surprised by how few people use it effectively. If you previously dismissed Apple crash reports as insufficient, I encourage you to reconsider that decision. Why Is This Impossible? Earlier I said “It’s impossible to implement a good crash reporter”, and I want to explain why I’m confident enough in my conclusions to use that specific word. There are two fundamental problems here: On iOS (and the other iOS-based platforms, watchOS and tvOS) your crash reporter must run inside the crashed process. That means it can never be 100% reliable. If the process is crashing then, by definition, it’s in an undefined state. Attempting to do real work in that state is just asking for problems [1]. To get good results your crash reporter must be intimately tied to system implementation details. These can change from release to release, which invalidates the assumptions made by your crash reporter. This isn’t a problem for the Apple crash reporter because it ships with the system. However, a crash reporter that’s built in to your product is always going to be brittle. I’m speaking from hard-won experience here. I worked for DTS during the PowerPC-to-Intel transition, and saw a lot of folks with custom crash reporters struggle through that process. Still, this post exists because lots of folks ignore this reality, so the subsequent sections contain advice about specific technical issues. WARNING Do not interpret any of the following as encouragement to implement your own crash reporter. I strongly advise against that. However, if you ignore my advice then you should at least try to minimise the risk, which is what the rest of this document is about. [1] On macOS it’s possible for your crash reporter to run out of process, just like the Apple crash reporter. However, possible is not the same as easy. In fact, running out of process can make things worse: It prevents you from geting critical state for the crashed process without being tightly bound to OS implementation details. It would be nice if Apple provided APIs for this sort of thing, but that’s currently not the case. Preserve the Apple Crash Report You must ensure that your crash reporter doesn’t disrupt the Apple crash reporter. This is important for three reasons: Some fraction of your crashes will not be caused by your code but by problems in framework code, and accurate Apple crash reports are critical in diagnosing such issues. When dealing with really hard-to-debug problems, you need the more obscure info that’s shown in the Apple crash report. If you’re working with someone from Apple (here on the forums, via a bug report, or a DTS case, or whatever), they’re going to want an accurate Apple crash report. If your crash reporter is disrupting the Apple crash reporter — either preventing it from generating crash reports entirely [1], or distorting those crash reports — that limits how much they can help you. IMPORTANT This is not a theoretical concern. The forums have many threads where I’ve been unable to help folks debug a gnarly problem because their third-party crash reporter didn’t preserve the Apple crash report (see here, here, and here for some examples). To avoid these issues I recommend that you test your crash reporter’s impact on the Apple crash reporter. The basic idea is: Create a program that generates a set of specific crashes. Run through each crash. Verify that your crash reporter produces sensible results. Verify that the Apple crash reporter produces the same results as it does without your crash reporter With regards step 1, your test suite should include: An un-handled language exception thrown by your code An un-handled language exception thrown by the OS (accessing an NSArray out of bounds is an easy way to get this) Various machine exceptions (at a minimum, memory access, illegal instruction, and breakpoint exceptions) Stack overflow Make sure to test all of these cases on both the main thread and a secondary thread. With regards step 4, check that the resulting Apple crash report includes correct values for: The exception info The crashed thread That thread’s state Any application-specific info, and especially the last exception backtrace [1] A particularly pathological behaviour here is to end your crash reporter by calling exit. This completely suppresses the Apple crash report. Some third-party language runtimes ‘helpfully’ include such a crash reporter, which makes it very hard to debug problems that occur within your process but outside of that language. Signals Many third-party crash reporters use UNIX signals to catch the crash. This is a shame because using Mach exception handling, the mechanism used by the Apple crash reporter, is generally a better option. However, there are two reasons to favour UNIX signals over Mach exception handling: On iOS-based platforms your crash reporter must run in-process, and doing in-process Mach exception handling is not feasible. Folks are a lot more familiar with UNIX signals. Mach exception handling, and Mach messaging in general, is pretty darned obscure. If you use UNIX signals for your crash reporter, be aware that this API has some gaping pitfalls. First and foremost, your signal handler can only use async signal safe functions [1]. You can find a list of these functions in sigaction man page [2] [3]. WARNING This list does not include malloc. This means that a crash reporter’s signal handler cannot use Objective-C or Swift, as there’s no way to constrain how those language runtimes allocate memory [4]. That means you’re stuck with C or C++, but even there you have to be careful to comply with this constraint. The Operative: It’s worse than you know. Captain Malcolm Reynolds: It usually is. Many crash reports use functions like backtrace (see its man page) to get a backtrace from their signal handler. There’s two problems with this: backtrace is not an async signal safe function. backtrace uses a naïve algorithm that doesn’t deal well with cross signal handler stack frames [5]. The latter point is particularly worrying, because it hides the identity of the stack frame that triggered the signal. If you’re going to backtrace out of a signal, you must use the crashed thread’s state (accessible via the handlers uap parameter) to start your backtrace. Apropos that, if your crash reporter wants to log the state of the crashed thread, that’s the place to get it. Your signal handler must be prepared to be called by multiple threads. A typical crashing signal (like SIGSEGV) is delivered to the thread that triggered the machine exception. While your signal handler is running on that thread, other threads in your process continue to run. One of these threads could crash, causing it to call your signal handler. It’s a good idea to suspend all threads in your process early in your signal handler. However, there’s no way to completely eliminate this window. Note The need to suspend all the other threads in your process is further evidence that sticking to async signal safe functions is required. An unsafe function might depend on a thread you’ve suspended. A typical crashing signal is delivered on the thread that triggered the machine exception. If the machine exception was caused by a stack overflow, the system won’t have enough stack space to call your signal handler. You can tell the system to switch to an alternative stack (see the discussion of SA_ONSTACK in the sigaction man page) but that isn’t a complete solution (because of the thread issue discussed immediately above). Finally, there’s the question of how to exit from your signal handler. You must not call exit. There’s two problems with doing that: exit is not async signal safe. In fact, exit can run arbitrary code via handlers registered with atexit. If you want to exit the process, call _exit. Exiting the process is a bad idea anyway, because it will prevent the Apple crash reporter from running. This is very poor form. For an explanation as to why, see Preserve the Apple Crash Report (above). A better solution is to unregister your signal handler (set it to SIG_DFL) and then return. This will cause the crashed process to continue execution, crash again, and generate a crash report via the Apple crash reporter. [1] While the common signals caught by a crash reporter are not technically async signals (except SIGABRT), you still have to treat them as async signals because they can occur on any thread at any time. [2] It’s reasonable to extend this list to other routines that are implemented as thin shims on a system call. For example, I have no qualms about calling vm_read (see below) from a signal handler. [3] Be aware, however, that even this list has caveats. See my Async Signal Safe Functions vs Dyld Lazy Binding post for details. [4] I expect that it’ll eventually be possible to write signal handlers in Swift, possibly using some facility that evolves from the the existing, but unsupported, @_noAllocation and @_noLocks attributes. If you’d like to get involved with that effort, I recommend that engage with the Swift Evolution process. [5] Cross signal handler stack frames are pushed on to the stack by the kernel when it runs a signal handler on a thread. As there’s no API to learn about the structure of these frames, there’s no way to backtrace across one of these frames in isolation. I’m happy to go into details but it’s really not relevant to this discussion [6]. If you’re interested, start a new thread with the Debugging tag and we can chat there. [6] (Arg, my footnotes have footnotes!) The exception to this is where your trying to generate a crash report for code running in a signal handler. That’s not easy, and frankly you’re better off avoiding signal handlers in general. Where possible, handle signals via a Dispatch event source. Reading Memory A signal handler must be very careful about the memory it touches, because the contents of that memory might have been corrupted by the crash that triggered the signal. My general rule here is that the signal handler can safely access: Its code Its stack (subject to the constraints discussed earlier) Its arguments Immutable global state In the last point, I’m using immutable to mean immutable after startup. It’s reasonable to set up some global state when the process starts, before installing your signal handler, and then rely on it in your signal handler. Changing any global state after the signal handler is installed is dangerous, and if you need to do that you must be careful to ensure that your signal handler sees consistent state, even though a crash might occur halfway through your change. You can’t protect this global state with a mutex because mutexes are not async signal safe (and even if they were you’d deadlock if the mutex was held by the thread that crashed). You should be able to use atomic operations for this, but atomic operations are notoriously hard to use correctly (if I had a dollar for every time I’ve pointed out to a developer they’re using atomic operations incorrectly, I’d be very badly paid (-: but that’s still a lot of developers!). If your signal handler reads other memory, it must take care to avoid crashing while doing that read. There’s no BSD-level API for this [1], so I recommend that you use vm_read. [1] The traditional UNIX approach for doing this is to install a signal handler to catch any memory access exceptions triggered by the read, but now we’re talking signal handling within a signal handler and that’s just silly. Writing Files If your want to write a crash report from your signal handler, you must use low-level UNIX APIs (open, write, close) because only those low-level APIs are documented to be async signal safe. You must also set up the path in advance because the standard APIs for determining where to write the file (NSFileManager, for example) are not async signal safe. Offline Symbolication Do not attempt to do symbolication from your signal handler. Rather, write enough information to your crash report to support offline symbolication. Specifically: The addresses to symbolicate For each Mach-O image in the process: The image’s path The image’s build UUID [1] The image’s load address You can get most of the Mach-O image information using the APIs in <mach-o/dyld.h> [2]. Be aware, however, that these APIs are not async signal safe. You’ll need to get this information in advance and cache it for your signal handler to record. This is complicated by the fact that the list of Mach-O images can change as you process loads and unloads code. This requires you to share mutable state with your signal handler, which is exactly what I recommend against in Reading Memory. Note You can learn about images loading and unloading using _dyld_register_func_for_add_image and _dyld_register_func_for_remove_image respectively. [1] If you’re unfamiliar with that term, see TN3178 Checking for and resolving build UUID problems and the documents it links to. [2] I believe you’ll need to parse the Mach-O load commands to get the build UUID. What to Include When deciding what to include in a crash report, there’s a three-way balance to be struck: The more information you include, the easier it is to diagnose problems. Some information is hard to obtain, either because there’s no public API to get that information, or because the API is not available to your crash reporter. Some information is so privacy-sensitive that it has no place in a crash report. Apple’s crash reporter strikes its own balance here, and I recommend that you try to include everything that it includes, subject to the limitations described in the second point. Here’s what I’d considered to be a minimal list: Information about the machine exception that triggered the crash For memory access exceptions, the address of the access that triggered the crash Backtraces of all the threads (sometimes the backtrace of a non-crashing thread can yield critical information about the crash) The crashed thread Its thread state A list of Mach-O images, as discussed in the Offline Symbolication section IMPORTANT Make sure you report the thread backtraces in a consistent order. Without that it’s hard to correlate information across crash reports. Revision History 2025-08-25 Added some links to examples of third-party crash reports not preserving the Apple crash report. Added a link to TN3178. Made other minor editorial changes. 2022-05-16 Fixed a broken link. 2021-09-10 Expanded the General Advice section to include pointers to Apple crash report resources, including MetricKit. Split the second half of that section out in to a new Why Is This Impossible? section. Made minor editoral changes. 2021-02-27 Fixed the formatting. Made minor editoral changes. 2019-05-13 Added a reference to my Async Signal Safe Functions vs Dyld Lazy Binding post. 2019-02-15 Expanded the introduction to the Preserve the Apple Crash Report section. 2019-02-14 Clarified the complexities of an out-of-process crash reporter. Added the What to Include section. Enhanced the Signals section to cover reentrancy and stack overflow. Made minor editoral changes. 2019-02-13 Made minor editoral changes. Added a new footnote to the Signals section. 2019-02-12 First posted.

Hi, I have a .NET MAUI app running on .NET 9. When I test locally in debug or release mode it works perfectly fine, but when testing from TestFlight it crashes almost immediately every time. I have sent the crash report to TestFlight and produced the symbolicated.crash file (attached), but I'm not sure it's helpful for understanding how to fix the issue. If anyone can help me understand what the issue might be and any possible fixes it'd be very much appreciated. I'm developing using Visual Studio 2022 paired to my Mac. I have distributed previously without issue, but now can't seem to, even after reverting recent code. net9.0-ios 15.0 symbolicated.crash

Both view and modifier versions of the FamilyActivityPicker crash randomly when selecting some items (usually the other option) throwing these in the console: [com.apple.FamilyControls.ActivityPickerExtension(1150.1)] Connection to plugin invalidated while in use AX Lookup problem - errorCode:1100 error:Permission denied portName:'com.apple.iphone.axserver' PID:22091 ( 0 AXRuntime 0x00000001c603b0fc _AXGetPortFromCache + 800 1 AXRuntime 0x00000001c603cce0 AXUIElementPerformFencedActionWithValue + 700 2 UIKit 0x0000000230de3ec8 DDE6E0C5-2AC3-3C73-8CFE-BC88DE35BB5F + 1453768 3 libdispatch.dylib 0x0000000103ef0b98 _dispatch_call_block_and_release + 32 4 libdispatch.dylib 0x0000000103ef27bc _dispatch_client_callout + 20 5 libdispatch.dylib 0x0000000103efa66c _dispatch_lane_serial_drain + 832 6 libdispatch.dylib 0x0000000103efb408 _dispatch_lane_invoke + 408 7 libdispatch.dylib 0x0000000103f08404 _dispatch_root_queue_drain_deferred_wlh + 328 8 libdispatch.dylib 0x0000000103f07a38 _dispatch_workloop_worker_thread + 444 9 libsystem_pthread.dylib 0x00000001f0824f20 _pthread_wqthread + 288 10 libsystem_pthread.dylib 0x00000001f0824fc0 start_wqthread + 8 ) This also happens in production apps like the Opal. The questions are: At least how to detect it to be able to manually reload the sheet (like what Opal does and shows an alert when this happens) How to prevent it in the first place? I really appreciate any help you can provide.

Intro I am reporting multiple persistent UI animation issues observed in tvOS 26 (Beta 6). These issues have been reproducible across multiple tvOS releases. They are subtle but noticeable, and they affect the overall polish and perceived quality of the system. I am happy to provide high-quality video captures for each of the issues described below. ⸻ Bug #1: App launch animation stutter/jump Summary: The zoom-in animation from a Springboard icon to full-screen app stutters or jumps at the moment the app becomes full screen. Steps to reproduce: 1. On Springboard, select any app icon. 2. Observe the zoom-in animation. Expected result: Smooth, continuous zoom without frame drops or jumps. Actual result: Animation visibly stutters/jumps at the full-screen transition. Possible cause: Timing issue in Core Animation interpolation or abrupt view hierarchy switch. ⸻ Bug #2: Text rendering weight change (“jump”) during transitions Summary: Text inside apps changes visual weight mid-transition from scaled preview to full screen. Steps to reproduce: 1. From Springboard or App Switcher, launch an app with visible text. 2. Observe text during the zoom animation — initially slightly bolder, then thinner once full screen. Also occurs in: • Top Shelf banners in the Dock • App Switcher → full-screen transitions Expected result: Consistent text rendering throughout the transition. Actual result: Visible “pop” in text weight/anti-aliasing during transition. Possible cause: Different rasterization/anti-aliasing mode between preview snapshot (CALayer.contents) and live CoreText/UIKit rendering. ⸻ Bug #3: Focus shadow jumps instead of interpolating smoothly Summary: Shadows around focused UI elements (icons, buttons) change abruptly during focus transitions. Steps to reproduce: 1. Navigate between focusable UI elements on Springboard or in apps. 2. Observe the shadow effects. Expected result: Shadows interpolate smoothly (offset, opacity, radius) during focus transitions. Actual result: Shadows “jump” abruptly, breaking animation smoothness. Possible cause: UIFocusEngine not interpolating shadow parameters consistently. ⸻ Bug #4: Abrupt jumps when swiping horizontally between content items Summary: In horizontally scrollable poster/content rows, focus snaps abruptly instead of scrolling smoothly. Steps to reproduce: 1. In the TV app or any app with horizontal poster rows, swipe left/right. 2. Observe the transition between focused items. Expected result: Smooth horizontal navigation with continuous motion. Actual result: Occasional abrupt snapping/jumping between items. ⸻ Impact While none of these bugs block core functionality, they degrade the premium feel and visual polish of tvOS. They are persistent across releases and occur in core system UI, so they are visible to all users. Note I can provide video recordings for each bug to assist engineering in reproducing and analyzing the issues.

I regularly bump into folks confused by this issue, so I thought I’d collect my thoughts on the topic into a single (hopefully) coherent post. If you have questions or comments, put them in a new thread here on the forums. Feel free to use whatever subtopic and tags that apply to your situation, but make sure to add the Debugging tag so that I see your thread go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Testing and Debugging Code Running in the Background I regularly see questions like this: My background code works just fine in Xcode but fails when I download the app from the App Store. or this: … or fails when I run my app from the Home screen. or this: How do I step through my background code? These suggest a fundamental misunderstanding of how the debugger interacts with iOS’s background execution model. The goal of this post is to explain that misunderstanding so that you can effectively test and debug background code. Note The focus of this post is iOS. The advice here generally applies to any of iOS’s ‘child’ platforms, so iPadOS, tvOS, and so on. However, there will be some platform specific differences, especially on watchOS. This advice here doesn’t apply to macOS. It’s background execution model is completely different than the one used by iOS. Understand the Fundamentals The key point to note here is that the debugger prevents your app from suspending. This has important consequences for iOS’s background execution model. Normally: iOS suspends your app when it’s in the background. Once your app is suspended, it becomes eligible for termination. The most common reason for this is that the system wants to recover memory, but it can happen for various other reasons. For example, the system might terminate a suspended app in order to update it. Under various circumstances your app can continue running after moving to the background. A great example of this is the continued processed task feature, introduced in iOS 26 beta. Alternatively, your app can be resumed or relaunched in the background to perform some task. For example, the region monitor feature of Core Location can resume or relaunch your app in the background when the user enters or leaves a region. If no app needs to be executing, the system can sleep the CPU. None of this happens in the normal way if the debugger is attached to your app, and it’s vital that you take that into account when debugging code that runs in the background. An Example of the Problem For an example of how this can cause problems, imagine an app that uses an URLSession background session. A background session will resume or relaunch your app in the background when specific events happen. This involves two separate code paths: If your app is suspended, the session resumes it in the background. If your app is terminated, it relaunches it in the background. Neither code path behaves normally if the debugger is attached. In the first case, the app never suspends, so the resume case isn’t properly exercised. Rather, your background session acts like it would if your app were in the foreground. Normally this doesn’t cause too many problems, so this isn’t a huge concern. On the other hand, the second case is much more problematic. The debugger prevents your app from suspending, and hence from terminating, and thus you can’t exercise this code path at all. Seek Framework-Specific Advice The above is just an example, and there are likely other things to keep in mind when debugging background code for a specific framework. Consult the documentation for the framework you’re working with to see if it has specific advice. Note For URLSession background sessions, check out Testing Background Session Code. The rest of this post focuses on the general case, offering advice that applies to all frameworks that support background execution. Run Your App Outside of Xcode When debugging background execution, launch your app from the Home screen. For day-to-day development: Run the app from Xcode in the normal way (Product > Run). Stop it. Run it again from the Home screen. Alternatively, install a build from TestFlight. This accurately replicates the App Store install experience. Write Code with Debugging in Mind It’s obvious that, if you run the app without attaching the debugger, you won’t be able to use the debugger to debug it. Rather: Extract the core logic of your code into libraries, and then write extensive unit tests for those libraries. You’ll be able to debug these unit tests with the debugger. Add log points to help debug your integration with the system. Treat your logging as a feature of your product. Carefully consider where to add log points and at what level to log. Check this logging code into your source code repository and ship it — or at least the bulk of it — as part of your final product. This logging will be super helpful when it comes to debugging problems that only show up in the field. My general advice is that you use the system log for these log points. See Your Friend the System Log for lots of advice on that front. One of the great features of the system log is that disabled log points are very cheap. In most cases it’s fine to leave these in your final product. Attach and Detach In some cases it really is helpful to debug with the debugger. One option here is to attach to your running app, debug a specific thing, and then detach from it. Specifically: To attach to a running app, choose Debug > Attach to Process > YourAppName in Xcode. To detach, choose Debug > Detach. Understand Force Quit iOS allows users to remove an app from the multitasking UI. This is commonly known as force quit, but that’s not a particularly accurate term: The multitasking UI doesn’t show apps that are running, it shows apps that have been run by the user. The UI shows recently run apps regardless of whether they’re in the foreground, running in the background, suspended, or terminated. So, removing an app from the UI may not actually quit anything. Removing an app sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. Note In some circumstances iOS will not honour this flag. The exact cases where this happens are not documented and have changed over time. Keep these behaviours in mind as you debug your background execution code. For example, imagine you’re trying to test the URLSession background relaunch code path discussed above. If you force quit your app, you’ll never hit this code path because iOS won’t relaunch your app in the background. Rather, add a debug-only button that causes your app to call exit. IMPORTANT This suggestion is for debugging only. Don’t include a Quit button in your final app! This is specifically proscribed by QA1561. Alternatively, if you’re attached to your app with Xcode, simply choose Product > Stop. This is like calling exit; it has no impact on your app’s ability to run in the background. Test With Various Background App Refresh Settings iOS puts users in control of background execution via the options in Settings > General > Background App Refresh. Test how your app performs with the following settings: Background app refresh turned off overall Background app refresh turned on in general but turned off for your app Background app refresh turned on in general and turned on for your app IMPORTANT While these settings are labelled Background App Refresh, they affect subsystems other than background app refresh. Test all of these cases regardless of what specific background execution feature you’re using. Test Realistic User Scenarios In many cases you won’t be able to fully test background execution code at your desk. Rather, install a TestFlight build of your app and then use the device as a normal user would. For example: To test Core Location background execution properly, actual leave your office and move around as a user might. To test background app refresh, use your app regularly during the day and then put your device on charge at night. Testing like this requires two things: Patience Good logging The system log may be sufficient here, but you might need to investigate other logging solutions that are more appropriate for your product. These testing challenges are why it’s critical that you have unit tests to exercise your core logic. It takes a lot of time to run integration tests like this, so you want to focus on integration issues. Before starting your integration tests, make sure that your unit tests have flushed out any bugs in your core logic. Revision History 2025-08-12 Made various editorial changes. 2025-08-11 First posted.

My Xcode version is 16.4, I have added an old version simulator (iPhone 13 with iOS 17.2) to the simulator list, but I can't use it for debugging, and all on display are iPhone 16 with 18.6 (the latest iOS devices). The setting "Minimum Deployments" for my App is 16.6. In addition, when I downloaded an iOS 16.0 version simulator, Xcode automatically added all iPhone 15 models of the simulator, but I still can't use them. In short, I can only use the default iPhone 16 simulators. So, if I want to debug my App using iPhone 13 (iOS 17.2), what should I do? Thank you for your reply. :) Another small issue, my App's destination has been set to support only iPhone, why are those iPad simulators still appearing?

Hello everyone, I'm encountering a MultipeerConnectivity connection issue while developing a visionOS app and would like to ask if other developers have experienced similar problems. Problem Description In visionOS 26.0 Beta 3 and Beta 4, when a visionOS device attempts to connect to an iPad via MultipeerConnectivity, the iPad side completely fails to receive connection requests, resulting in connection establishment failure. Specific Symptoms After executing serviceBrowser?.invitePeer(peerID, to: mcSession, withContext: nil, timeout: 10.0) on the visionOS side The iPad side shows no response and receives no connection invitation Connection request times out after 10 seconds and is automatically rejected No error logs or exception information are generated Environment Information visionOS version: 26.0 Beta 3 and Beta 4 Development environment: macOS Tahoe 26.0 Beta (25A5306g) Target device: iPad (iOS 17.x) Network environment: Same WiFi network Comparative Test Results visionOS 2.6 (22O785): Functionality completely normal visionOS 26.0 Beta 1/2: Functionality normal visionOS 26.0 Beta 3/4: Exhibits the above problems Attempted Solutions Checked network configuration and firewall settings Adjusted MultipeerConnectivity parameters Reinitialized MCSession and MCNearbyServiceBrowser Cleared app cache and reinstalled Reset network settings Temporary Workaround Currently, the only solution is to downgrade the visionOS device to version 2.6. Impact of the Problem This issue severely affects the development of cross-device collaboration features in visionOS apps, particularly scenarios requiring peer-to-peer communication with iOS/iPadOS devices. Questions for Help Have other developers encountered similar issues? Are there any known solutions or workarounds? Is this a known issue with visionOS 26.0 Beta? Are there other known issues related to MultipeerConnectivity? Relevant Code Snippet // Connection invitation code private var serviceBrowser: MCNearbyServiceBrowser? let mcSession: MCSession // Execute connection invitation serviceBrowser?.invitePeer(peerID, to: mcSession, withContext: nil, timeout: 10.0) Thank you for your help and suggestions! Development Environment: Xcode 15.x Target Platform: visionOS

I am building a widget that supports 2 different widget kinds, each supporting systemSmall, systemMedium, and systemLarge size families. My widget does download and display images so I expect memory usage to be on the higher end, but in debugging some memory issues, I notice that when I build my widget scheme to a physical device, things start off reasonable at ~12MB of memory usage. But as I change the widgets intent, add the other widget kind, or add different widget size families, this memory usage grows until it ultimately hits the 30MB cap. My question is, is the 30MB memory limit spread across all my supported widget kinds/sizes? Or does each individual widget get its own 30MB cap? i.e., if I have systemMedium Widget A and systemLarge Widget B, are they sharing that 30MB memory limit?