Hi, I'm migrating my project from the old .strings files to String Catalogs (.xcstrings files). Everything is migrating over fine except for my custom intents. Right now the localization files for my custom intents all live "under" the definition file like so: But there is no option to migrate to a string catalog. I even tried removing the localization files, and re-adding them using the "Localize..." button, but that just creates the old .strings files, not the new string catalog. Is this not supported yet for intents definitions? I can't find any documentation about this. It would be a real shame to have part of my app on string catalogs and this one piece on the old Localizable.strings format.

When I try to make a unit test target for my macOS app that uses Objective-C, running tests fails, and the debugging log shows a message "Creating more than one Application". If, on the other hand, when I create the unit test target, I select "None" as the target to be tested, and then add all my sources to that target, my tests work. So, I can get my testing done, but I think I must be doing something wrong. By the way, along with the error message, there is a stack crawl: 0 CoreFoundation 0x00007ff8140410aa __exceptionPreprocess + 242 1 libobjc.A.dylib 0x00007ff813b660b7 objc_exception_throw + 48 2 Foundation 0x00007ff814f19bd8 -[NSCalendarDate initWithCoder:] + 0 3 AppKit 0x00007ff817030062 -[NSApplication init] + 1718 4 XCTestCore 0x000000010774b0df -[XCTestDriver _createTestBundlePrincipalClassInstance] + 82 5 XCTestCore 0x0000000107749338 -[XCTestDriver _runTests] + 111 6 XCTestCore 0x000000010770f194 _XCTestMain + 126 7 libXCTestBundleInject.dylib 0x0000000106e8982d __copy_helper_block_e8_32s + 0 8 CoreFoundation 0x00007ff813fc9a91 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12 9 CoreFoundation 0x00007ff813fc99ca __CFRunLoopDoBlocks + 398 10 CoreFoundation 0x00007ff813fc883d __CFRunLoopRun + 898 11 CoreFoundation 0x00007ff813fc7e51 CFRunLoopRunSpecific + 560 12 HIToolbox 0x00007ff81da52f3d RunCurrentEventLoopInMode + 292 13 HIToolbox 0x00007ff81da52b84 ReceiveNextEventCommon + 199 14 HIToolbox 0x00007ff81da52aa8 _BlockUntilNextEventMatchingListInModeWithFilter + 64 15 AppKit 0x00007ff8170689d8 _DPSNextEvent + 858 16 AppKit 0x00007ff817067882 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1214 17 AppKit 0x00007ff817059ef7 -[NSApplication run] + 586 18 AppKit 0x00007ff81702e111 NSApplicationMain + 817 19 PlainCalc 0x00000001057d0a91 main + 65 20 dyld 0x00007ff813b93418 start + 1896

The Mac has an Intel chip and has Xcode 15.2 installed. After launching Xcode, the canvas interface keeps spinning and cannot display synchronously normally. The simulator also takes a long time to start. Seeking help to resolve this issue.

Unsupported Request PATCH to http://developer.apple.com/services-account/v1/bundleIds/{MyId} not supported. Reference #8.5dfb1302.1756215327.6d0203bb https://errors.edgesuite.net/8.5dfb1302.1756215327.6d0203bb

Xcode version 16.4 (16F6) now only supports uploading a 1024x1024 icon, but during archiving, it keeps prompting that a 120x120 icon is missing. Attempts to add the image in Assets didn't work. How can this issue be resolved?"

Hello everyone, I’m completely new to programming and Apple development, but I’ve always had the strong wish to learn coding and to work more deeply with Apple’s system structures. My main questions are: How should I best start learning? For example, is Swift Playgrounds the right first step? How should I continue afterwards to gain further knowledge, possibly in areas like system architecture, cybersecurity, or cloud computing (even though I don’t want to commit too early to one direction)? Can you recommend a learning schedule or intensity (e.g., how often per day or week I should practice) for someone who works full-time? Is my current MacBook Air (2020, Intel i3, 8 GB RAM, 250 GB SSD) still suitable for learning and beginner development, or would you recommend upgrading to a newer model? On top of that, my English is not perfect yet – is it possible to improve it alongside learning coding? I’m very motivated to finally start this journey, even though I once turned down an IBM apprenticeship when I was younger. Now I want to give it a real try. Any advice, personal experiences, or learning resources would be very much appreciated. Thank you in advance!

Hi, I am reaching out to seek assistance with a persistent code signing issue that is preventing our team from installing our iOS app, "Scoopz" (https://apps.apple.com/us/app/scoopz-real-life-real-video/id6449206831) on physical devices. We suspect there may be an issue with our Apple Developer account, as we have exhausted all standard troubleshooting steps without success. Below, I’ve provided details about the issue, the error logs, and the steps we’ve taken. Issue Description: When attempting to install the app on an iPhone using Xcode, we encounter the following error: Unable to Install “Scoopz: Debug” Domain: IXUserPresentableErrorDomain Code: 14 Recovery Suggestion: Failed to verify code signature of /[REDACTED_PATH]/OurApp.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) The app builds successfully to the iOS Simulator and can be released to the App Store without issues, but it fails to debug on physical devices. Steps Taken: Our team has attempted the following troubleshooting steps without resolving the issue: Verified that our Apple Developer account is active and our team membership is valid. Checked certificates in Keychain Access and the Apple Developer Portal, ensuring they are not expired or revoked. We created and installed new Apple Development certificates. Confirmed that the provisioning profile includes the target device’s UDID, is associated with a valid certificate, and is not expired. We regenerated and reinstalled the profile. We tried both xcode managed and manually installed profiles. Cleaned the Xcode build folder, deleted the app from the device, and rebuilt the project. Despite these efforts, the issue persists across our entire development team, leading us to believe there may be a problem with our Apple Developer account or its associated certificates/profiles. Request for Assistance: We kindly request your help to: Investigate any potential issues with our Apple Developer account that could be causing this code signing error. Verify the status of our certificates and provisioning profiles on Apple’s servers. Provide guidance on any additional steps or configurations needed to resolve the error. If necessary, suggest how we can escalate this issue for further investigation. Full error log: Unable to Install “Scoopz: Debug” Domain: IXUserPresentableErrorDomain Code: 14 Recovery Suggestion: Failed to verify code signature of /[REDACTED_PATH]/OurApp.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) Please ensure that the certificates used to sign your app have not expired. If this issue persists, please attach an IPA of your app when sending a report to Apple. User Info: { DVTErrorCreationDateKey = "2025-08-20 23:50:11 +0000"; IDERunOperationFailingWorker = IDEInstallCoreDeviceWorker; } Failed to install the app on the device. Domain: com.apple.dt.CoreDeviceError Code: 3002 User Info: { *** } Unable to Install “Scoopz: Debug” Domain: IXUserPresentableErrorDomain Code: 14 Failure Reason: This app cannot be installed because its integrity could not be verified. Recovery Suggestion: Failed to verify code signature of /[REDACTED_PATH]/OurApp.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) Failed to verify code signature of /[REDACTED_PATH]/OurApp.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) Domain: MIInstallerErrorDomain Code: 13 User Info: { FunctionName = "+[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:]"; LegacyErrorString = ApplicationVerificationFailed; LibMISErrorNumber = "-402620392"; SourceFileLine = 78; } Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { "device_identifier" = "-*********"; "device_isCoreDevice" = 1; "device_model" = "iPhone16,2"; "device_osBuild" = "17.1 (21B80)"; "device_platform" = "com.apple.platform.iphoneos"; "device_thinningType" = "iPhone16,2"; "dvt_coredevice_version" = "397.21"; "dvt_coresimulator_version" = 987; "dvt_mobiledevice_version" = "1784.101.1"; "launchSession_schemeCommand" = Run; "launchSession_state" = 1; "launchSession_targetArch" = arm64; "operation_duration_ms" = 4926; "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.0"; "sdk_osVersion" = "18.0"; "sdk_variant" = iphoneos; } System Information macOS Version 15.4.1 (Build 24E263) Xcode 16.0 (23051) (Build 16A242d) Timestamp: 2025-08-20T16:50:11-07:00

Any time I attempt to download the latest beta of macOS 26, Safari stops the download at Zero KB, with no indication of why. I'm able to download OS 26 beta 8 for the other platforms absolutely fine, just not macOS. Pressing the little orange "reload" button, just results in another copy of the same zero KB file bundle on the file system. Can anyone help please?

I’m trying to archive my app in Xcode but keep running into issues. When I attempt to archive, I see two errors: “Communication with Apple failed. Your team has no device from which to generate a provisioning profile. Connect a device to use or manually add a device ID in the certificate.” “No profiles were found” — Xcode can’t locate a matching iOS development provisioning profile. I’ve already added the device ID manually, set up my bundle identifier in Apple Connect (which was detected), and signed in with my Apple ID in Xcode. What steps should I take to resolve this? If there’s a thread, article, or anything that explains the fix, I will appreciate if you can share it as well. Also, is it common that I created the project, but my role shows as Admin instead of Account Holder? I tried to find a way to change my role from Admin to Account Holder, but I couldn’t find any resources. Thank you in advance for your help!

Hello, It seems Xcode 26 beta is lagging the OS releases, which is fine. However, how does one install a Beta N + 1 or N + 2 SDK into the older Xcode beta? I'd like to use iOS 26 Beta 8 from the Xcode 26 Beta 6 install I have. I have tried Settings/Components and Devices & Simulators but nothing Beta 7 nor 8 shows up there. Thanks! -- Greg Bolsinga

When I update the macOS from 15.5 to 15.6, Preview error. 1、I try remove simulator cache， sdk 2、remove Xcode build cache 3、reinstall Xcode 4、try with this method https://byby.dev/uninstall-xcode#:%7E:text=Delete%20old%20simulators%20and%20devices,moving%20them%20to%20the%20Trash but all failed swiftui log.txt

There is a code review (split view) feature. Which is nice. But then when I see a change I want to stage and right click the blue bar in the gutter next to the change, I'm only presented with the option to discard the change, nothing else. So in order to stage I either have to go to the source control window (accessed via the project navigator) or close the code review tool, stage, and then go back to the code review tool.

Right now, if I added a large swatch of contiguous code, the stage feature in Xcode is all or nothing — either I stage all the changes or I stage none of them. It would be a better UX if after spotting the isolates changes within that swatch that are final if I could select them and stage them. This way, it would be easy for me to easily green light all the changes I know are production ready, and then when I'm done, clearly see those which are not and easily be able to hone in on the changes that require some more thought.

I’m new to iOS development. Previously, I’ve worked with Python and Django, mainly using JetBrains PyCharm PRO. In PyCharm, I really benefit from plugins like "Rainbow Brackets" , which help a lot with readability and code navigation. As someone who wears glasses, I find such visual aids very helpful for reducing eye strain. While exploring Xcode, I noticed that similar built-in features or up-to-date plugin support seem limited. Considering Apple’s strong focus on accessibility and user experience, I was a bit surprised by this. With Xcode 26 coming soon, I’m also wondering if there will be improvements in plugin support or built-in tools like Swift Linter and Swift Format. Are there any current tools or plugins you’d recommend to fill these gaps?

My app (called "MuVis - Music Visualizer") passes the macOS App Store verification, but is failing the iOS verification. The errors indicate a problem with the Swift package github.com/Treata11/CBass.  I have been in touch with the CBass package developer (Treata11) as well as the original BASS developers (un4seen.com).  We think the problem is related to CBass swift-package config (which apparently works fine for mac, but doesn’t for iOS). The source code for the package is at the site package.  All of us think that the package is configured correctly in accordance with the latest Apple package development documentation.  Please tell us what is wrong with this package, and how to make it pass the iOS App Store verification. The Xcode error messages from validation testing include several items similar to: Upload Symbols Failed: inline-code The archive did not include a dSYM for the bass.framework with the UUIDs [18D5DBE2-3250-3EDE-B75C-D81B4E9F05AC, A88554A0-9087-3776-AC05-424B2D52F973, DEB682F5-ABBE-39D5-A0F8-8C01C14E178A]. Ensure that the archive's dSYM folder includes a DWARF file for bass.framework with the expected UUIDs. Since the MuVis app is long and complex, I have written a minimal reproducible example app (called "SwiftCBassDemo") for which source code is available at DemoApp. I am using macOS 15.6.1, Xcode 16.4, and iOS 18.6.2.

I can not seem to get ll the pieces working here. Has anyone set up grok? URL - https://api.x.ai/v1/chat/completions api-key ---- API Key Header x-api-key Doesn't work. Any help would be greatly appreciated. Thanks, Rob

In previous versions of the simulator, it was possible to import files into the Files app by dragging them from the Finder into the Simulator. It appears that in the iOS 26 Simulator, this opens the file in Safari. I've only tried it with .json files so far. The documentation at https://developer.apple.com/documentation/xcode/sharing-data-with-simulator says that the original behaviour should happen: To add files to Simulator, select one or more files in Finder on your Mac, then click the Share button. Select Simulator from the share destination list. Choose the simulated device from the drop-down list. Simulator opens the Files app, and lets you select where to save the files. I'd love to learn if this is intentional behaviour, and if so, what workarounds there might be. I use this pattern quite a lot, as I have a HealthKit app, and I've built a system that allows me to export workouts as JSON files from a real device, that I can then import into a simulator for testing. Edit: I found a workaround. Make a folder in Files.app, then search for it within ~/Library/Developer/CoreSimulator/Devices. Open the folder in Finder, then add any files you want to be available in the Simulator.

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 everyone, I'm totally new to this and am just having fun making an app for myself. I'm attempting to get a broadcastupload extension working, but whatever i do i cant get the replaykit to work. I keep getting this error in xcode: Provisioning profile "Project v6 Broadcast Upload Development" doesn't include the com.apple.developer.replaykit.broadcast entitlement. What I've tried: Created separate App IDs for each target (Explicit App IDs, not Wildcard) Enabled App Groups capability on all three App IDs in Apple Developer Portal Selected the correct App Group for all App IDs Added App Groups capability in Xcode for all targets and all build configurations Created entitlements file with com.apple.developer.replaykit.broadcast: true for Broadcast Upload extension Recreated provisioning profiles multiple times Used manual code signing with correct certificates I'm completely lost. I reached out directly to apple developer support and they just told me to come here... Any help would be grgeatly appreciated.

I've filed a FB already through standard channels (FB ID: FB19032008) but I'll post it here in case it may get some attention from others experiencing similar issues. On macOS 26 Beta 5 and Xcode 26 Beta 5 (and earlier revisions afaik) Icon Composer specifies a minimum window size that greatly exceeds the bounds of the 1280x800/832pt video modes available on 13in MacBooks, and which also is too large for the default 1440x900 video mode on non-notched 13in MacBook Air/Pro models as this causes a default-size 64pt dock to occlude the window. I've attached screenshots depicting this behaviour in the two above described cases. Best solution seems like reducing min window size to something that will fit reasonably in a 1280x800pt viewport including the dock and menu bar (e.g. 1000x600 or something).