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.

Xcode 16.2 Flutter version 3.27.1 0 0x1008abee4 __assert_rtn + 160 1 0x1008add9c ld::tool::OutputFile::setFixup64(unsigned char*, unsigned long long, ld::Atom const*) (.cold.3) + 0 2 0x100789640 ld::tool::OutputFile::setFixup64(unsigned char*, unsigned long long, ld::Atom const*) + 656 3 0x100785b78 ld::tool::OutputFile::applyFixUps(ld::Internal&amp;, unsigned long long, ld::Atom const*, unsigned char*) + 4388 4 0x10078be18 ___ZN2ld4tool10OutputFile10writeAtomsERNS_8InternalEPh_block_invoke + 488 5 0x19bc19428 _dispatch_client_callout2 + 20 6 0x19bc2d850 _dispatch_apply_invoke3 + 336 7 0x19bc193e8 _dispatch_client_callout + 20 8 0x19bc1ac68 _dispatch_once_callout + 32 9 0x19bc2c8a4 _dispatch_apply_invoke + 252 10 0x19bc193e8 _dispatch_client_callout + 20 11 0x19bc2b080 _dispatch_root_queue_drain + 864 12 0x19bc2b6b8 _dispatch_worker_thread2 + 156 13 0x19bdc5fd0 _pthread_wqthread + 228 A linker snapshot was created at: /tmp/Test Kopi Kenangan.debug.dylib-2025-02-27-100512.ld-snapshot ld: Assertion failed: (reconstituted == accumulator), function setFixup64, file OutputFile.cpp, line 2975. clang: error: linker command failed with exit code 1 (use -v to see invocation)

Up to now I've been building my x64 binaries on Sequioa specifying a target macOS level of 13.4. That worked fine. In an attempt to debug a problem that was causing some pain I created a 13.4 x64 build environment and tried to build the code there. This code: using CacheKeyType = std::filesystem::path; using CacheValueType = std::tuple<LoadedImage, int, bool>; // <image, lastUse, currentlyLoading> using CacheType = std::unordered_map<CacheKeyType, CacheValueType>; friend class ThreadLoader; static inline constexpr int16_t MAXIMAGESINCACHE = 20; static inline constinit std::atomic_int age{ 0 }; static inline std::shared_mutex rwMutex{}; static inline CacheType imageCache{}; got me the following errors: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/c++/v1/__hash_table:838:5: error: static_assert failed due to requirement 'integral_constant<bool, false>::value' "the specified hash does not meet the Hash requirements" static_assert(__check_hash_requirements<_Key, _Hash>::value, ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/c++/v1/__hash_table:853:1: note: in instantiation of template class 'std::__enforce_unordered_container_requirements<std::filesystem::path, std::hash<std::filesystem::path>, std::equal_to<std::filesystem::path>>' requested here typename __enforce_unordered_container_requirements<_Key, _Hash, _Equal>::type ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/c++/v1/unordered_map:1152:30: note: while substituting explicitly-specified template arguments into function template '__diagnose_unordered_container_requirements' static_assert(sizeof(__diagnose_unordered_container_requirements<_Key, _Hash, _Pred>(0)), ""); ^ /Users/amonra/.vs/DSS/build/DeepSkyStackerKernel/DeepSkyStackerKernel_autogen/EWIEGA46WW/../../../../DeepSkyStackerKernel/imageloader.h:60:26: note: in instantiation of member function 'std::unordered_map<std::filesystem::path, std::tuple<LoadedImage, int, bool>>::~unordered_map' requested here static inline CacheType imageCache{}; ^ 2 errors generated. Which isn't "mega-helpful" :( I thought that specifying: set(CMAKE_OSX_DEPLOYMENT_TARGET 13.4 CACHE STRING "Minimum operating system version for deployment" FORCE) would have made the compilations use the same headers as for Ventura above, but it seems not? Is this to be expected?

Hi everyone, We’re testing the new iOS 26 capability, Performing Fast Account Creation with Passkeys, using the sample project provided here: Performing Fast Account Creation with Passkeys. When running the project on the iOS 26 simulator and tapping the "Sign Up" button, we encounter the following error: The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1010.) From the header file, this error is described as: /// ASAuthorizationError.h /// This error signals that the device is not currently set up to create passkeys. ASAuthorizationErrorDeviceNotConfiguredForPasskeyCreation AS_API_AVAILABLE(ios(19.0), macos(16.0), visionos(3.0)) = 1010, We’ve tested this on both Xcode 26 Beta 1 and Beta 2, and the error persists on the simulator in both versions. However, when testing on a physical iOS 26 device, everything works as expected, just like in the WWDC demo. Could this issue be related to missing simulator settings? Or is it a potential bug in the simulator? Any advice would be greatly appreciated. Thanks in advance!

Hi, I have an installer package that runs a postinstall script. The script can take a long time to complete, as one thing it does is copy about 10-30 GB of files using the rsync tool. We noticed on macOS 15 that the installer would fail almost exactly 10 minutes after it started. Looking in the /var/log/install.log, I see a message like this: 2025-07-01 12:54:32-07 Work-M1 package_script_service[21562]: PackageKit: Terminating PKInstallTask(pid:21573). Task has exceeded its 600 seconds of runtime. This does not happen in my testing on macOS 12 (Monterey) I have a few questions about this: A) Is this documented, and which OS introduced this? B) Is there a way a developer can extend or disable the time limit via a setting in the installer package. Or if not, is there a way end end user can disable it temporarily on their system? Thanks, Andrew

Weirdness going on here. Our app is crashing on startup with iPad 7s running iOS 18.5. Before updating to iOS 18.5, it was working fine on iPad 7s. Even with iOS 18.5, it is working fine on every device we have tried including dozens of other iPads and iPhones. We have narrowed it down to the SquareReaderSDK. If we remove that SDK, it will launch and work without issues. But, many of our users need the SquareReaderSDK. The crash happens at app load, before appDelegate didFinishLaunchingWithOptions. So we can't figure out any way to debug the issue. Is anyone else having a similar issue? Square thinks it is an Apple issue.

I want to keep an eye on the App Store Connect release notes to find out when builds created with Xcode 26.2 RC will be accepted. I tried to add https://developer.apple.com/help/app-store-connect/release-notes/ to my RSS reeder but the items listed are not the same, it’s the items from the latest news from Apple Developer instead. Can we get an RSS feed please? Seems will be useful to monitor these release notes over time.

I would like to inquire about a concern related to the app review process. Specifically, I would like to understand if forcefully denying an application's execution on the iOS Simulator (for instance, by implementing a check in the code that prevents the app from running in a simulated environment) could negatively impact or delay the app’s approval during the App Store review process. This measure is intended solely for security and integrity reasons during development and distribution. The app functions normally on real devices, and all other guidelines and requirements outlined by Apple are being strictly followed. Could you please confirm whether such a restriction on the Simulator is acceptable, and if there are any best practices or recommendations from Apple regarding this? Thank you for your support, and I look forward to your guidance.

Recently we tried to update the plist.info file in one of our apps to specify an LSMinimumSystemVersion of 16.0 but when uploading this to App Store Connect using the Transporter app we received an error that this setting cannot be any higher than 15.2. Is there any way around this? Will this be changing soon?

I need to automate updating to latest iOS betas as part of my ci script, but I can't get it to install iOS 26.0 beta for the life of me, using xcodes or xcodebuild. I can see the version listed using xcodes runtimes --include-betas, and I tried sudo xcodes runtimes install "iOS 26.0-beta1", but I would get the error Downloading Runtime iOS 26.0-beta1: 0% Error: ProcessExecutionError()\ I also tried xcodebuild -downloadPlatform iOS -buildVersion 23A5260l, where I found the specific build id on apples dev images website. But I would get the error iOS 23A5260l is not available for download. Specific version download failed, trying downloadPlatform ios latest... And similar error for trying xcodebuild -downloadPlatform iOS -buildVersion 26.0 or other version ids I found online. But this command would work for any other versions and betas listed on the website. I was able to install iOS 26.0 through xcodebuild -downloadPlatform iOS, which automatically installed it for me, but this is unideal for my situation, as I want to control which betas to install instead of just the latest one (like iOS 18.6 beta that just came out). Is anyone else also struggling with these errors? xcodes version 1.6.2 Xcode version 26.0 Beta (installed and selected through xcode)

Hi, I have just updated my MacBook to Tahoe Beta 2, but now I cannot boot the iOS simulator. Where can I download the next Xcode beta? The Application download page is still showing the Xcode beta 1 build. Cheers, Jeff

I just turned it on by accident and I can’t turn it off… I’m using IOS 26 rn and I can’t go back and I can’t disable the developer mode, I’m not a developer so yeah

I’ve developed a virtual machine manager application using the macOS Virtualization framework. The application currently supports both NAT and bridged networking configurations. I’m now looking to implement host-only networking, where the guest VM can communicate with the host but not with external networks. Is this networking mode supported by the Virtualization framework, and if so, what is the recommended approach to set it up? Additionally, I would like to implement port forwarding from the host to the guest (e.g., redirecting traffic from a specific port on the host to a port on the guest). Is there a way to configure port forwarding using the built-in APIs of the Virtualization framework, or would this require a custom networking solution? Any guidance or best practices for implementing these features within the constraints of the framework would be greatly appreciated.

It is gone from where I used to find it on Apple’s web site. Is it deprecated or no longer available?

The project at hand is quite complex, and the link content is especially. I suddenly saw this warning again in recent days and wanted to inquire about when this deletion would be done, so that our team could make preparations and plan in advance.

I am working on a Swift package which uses CoreAudio, and includes some tests in a testTarget which use the Testing framework, and a couple of executableTarget targets which exercise the same code. I'm using Xcode 16.2 on macOS 15.3.1. One of the things I do in the test code is create a HAL plugin, then find that plugin using the kAudioHardwarePropertyTranslateUIDToDevice. Finding the plugin that I just created always fails from within a Swift Testing test, unless I run the test which creates the plugin individually first, then separately, run the test which finds the plugin, by clicking on the little arrows next to the function names. If I put the tests in a serialized suite (so creation always happens first, then finding), running the suite always fails - it creates the plugin, but can't find it. If I run the 'find my plugin' test again manually, it is always found. If I call the same functions from a regular executable (the thing created by a "executableTarget" in my .package.swift file), the just-created plugin is always found. Is there a way to mimic the runtime environment of a regular executable in a Swift Testing target, or am I misunderstanding something? this my be related to this issue: https://github.com/swiftlang/swift/issues/76882 but I don't understand it well enough to be sure.

I'd like to give control to the app developer that uses my library to select which level of logs they'd like to see from my lib (e.g. do they want to see all debug messages or just errors). I know there are filtering controls that Xcode gives us, but I'm wondering if there is a way to pull this off with code. Ideally the user callsite would look like MyLib(logLevel: .info). And then I would pass that info level somehow to OSLog. Today, I create my logger like this: let myLogger = Logger( subsystem: Bundle.main.bundleIdentifier ?? "UnknownApp", category: "MyLibrary" ) As far as I can tell, there is nothing I can then pass to my myLogger instance to configure the threshold level. I'm imagining an interface like: myLogger.logLevel(.warning) // Later... myLogger.debug("You won't see this") myLogger.error("But you will see this") Does OSLog and friends give us any ability to do this out of the box, or are we building little wrappers around OSLog to accomplish this? Thank you, Lou

When you update XCode it updates the sdk version, but do changes in the sdk take effect for apps running in a lower iOS version or only the corresponding iOS version or higher? For instance, https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-18_1-release-notes Do changes listed in the notes only happen for apps that are running on iOS 18.1 devices or on any device with the app compiled against the 18.1 sdk version? Am I the only person who finds the docs totally unclear on this?

Hi. I have three disk partitions on my MacBook Air M1. The one with Monterey, the one with Sonoma, and the one with Sequoia (15.3.1 in particular). When I try to download the 15.4 Beta from software update in settings, everything would go "fine" - the download process is being completed, the computer says it's going to restart in 60seconds, the countdown begins, etc. However, when restarting several times, I am being logged in once again into previous macOS (15.3.1) version, with a kernel panic report. I had the same panic on macOS 15.3 when attempting to download 15.4 Beta. I've upgraded my macOS to 15.3.1, as I thought I'd need the very last available version of regular macOS to participate in the newest beta. However, the panic occurs, pointing to some t8020dart.c file. I don't even theoretically know what is this and couldn't find any reference to that C file. Attaching a part of panic report: panic(cpu 3 caller 0x0): t8020dart 0xfffffdf02c980000 (dart-disp0): Can't ignore lock validation @t8020dart.c:535 Debugger message: panic Memory ID: 0xff OS release type: Not set yet OS version: Not set yet Kernel version: Darwin Kernel Version 24.4.0: Sat Feb 15 22:43:38 PST 2025; root:xnu-11417.100.533.501.4~3/RELEASE_ARM64_T8103 Fileset Kernelcache UUID: 232D67A6D42C66E14780A24B3C0AE05D Kernel UUID: F2602757-A486-30A9-8D8E-714224E5FE4A Boot session UUID: 575CD5EA-6898-47ED-9AEC-05E318135695 iBoot version: iBoot-11881.100.964.0.1 iBoot Stage 2 version: iBoot-11881.100.964.0.1 secure boot?: YES roots installed: 0 Paniclog version: 14 KernelCache slide: 0x00000000181d8000 KernelCache base: 0xfffffe001f1dc000 Kernel slide: 0x00000000181e0000 Kernel text base: 0xfffffe001f1e4000 Kernel text exec slide: 0x00000000198d0000 Kernel text exec base: 0xfffffe00208d4000 mach_absolute_time: 0x85b39c4 Epoch Time: sec usec Boot : 0x00000000 0x00000000 Sleep : 0x00000000 0x00000000 Wake : 0x00000000 0x00000000 Calendar: 0x00000000 0x00000000 Zone info: Zone map: 0xfffffe120c000000 - 0xfffffe380c000000 . VM : 0xfffffe120c000000 - 0xfffffe17d8000000 . RO : 0xfffffe17d8000000 - 0xfffffe1a72000000 . GEN0 : 0xfffffe1a72000000 - 0xfffffe203e000000 . GEN1 : 0xfffffe203e000000 - 0xfffffe260a000000 . GEN2 : 0xfffffe260a000000 - 0xfffffe2bd6000000 . GEN3 : 0xfffffe2bd6000000 - 0xfffffe31a2000000 . DATA : 0xfffffe31a2000000 - 0xfffffe380c000000 Metadata: 0xfffffe76ce010000 - 0xfffffe76d7810000 Bitmaps : 0xfffffe76d7810000 - 0xfffffe76d8d80000 Extra : 0 - 0 CORE 0 recently retired instr at 0xfffffe0020a9d2d0 CORE 1 recently retired instr at 0xfffffe0020a9d2d0 CORE 2 recently retired instr at 0xfffffe0020a9d2d0 CORE 3 recently retired instr at 0xfffffe0020a9b9ec CORE 4 recently retired instr at 0xfffffe0020a9d2d0 CORE 5 recently retired instr at 0xfffffe0020a9d2d0 CORE 6 recently retired instr at 0xfffffe0020a9d2d0 CORE 7 recently retired instr at 0xfffffe0020a9d2d0 TPIDRx_ELy = {1: 0xfffffe2040392fb0 0: 0x0000000000000003 0ro: 0x0000000000000000 } CORE 0 PVH locks held: None CORE 1 PVH locks held: None CORE 2 PVH locks held: None CORE 3 PVH locks held: None CORE 4 PVH locks held: None CORE 5 PVH locks held: None CORE 6 PVH locks held: None CORE 7 PVH locks held: None CORE 0: PC=0xfffffe002102157c, LR=0xfffffe0021021568, FP=0xfffffebf22637890 CORE 1: PC=0xfffffe00210207a4, LR=0xfffffe0020fe4eb0, FP=0xfffffebf2262b890 CORE 2: PC=0xfffffe002094c790, LR=0xfffffe002094c63c, FP=0xfffffebf22643890 CORE 3 is the one that panicked. Check the full backtrace for details. CORE 4: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2213fed0 CORE 5: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf22163ed0 CORE 6: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2216fed0 CORE 7: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2211bed0 Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space Panicked task 0xfffffe260c042b78: 0 pages, 268 threads: pid 0: kernel_task Panicked thread: 0xfffffe2040392fb0, backtrace: 0xfffffebf22666920, tid: 279 lr: 0xfffffe00209332bc fp: 0xfffffebf226669b0 lr: 0xfffffe0020a93cdc fp: 0xfffffebf22666a20 lr: 0xfffffe0020a91e94 fp: 0xfffffebf22666ae0 lr: 0xfffffe00208dbb94 fp: 0xfffffebf22666af0 lr: 0xfffffe0020932ba0 fp: 0xfffffebf22666ec0 lr: 0xfffffe0020932924 fp: 0xfffffe0031577e90 lr: 0xfffffe00211cb198 fp: 0xfffffe0031577eb0 lr: 0xfffffe002120aae4 fp: 0xfffffe0031577f80 lr: 0xfffffe00211f9104 fp: 0xfffffe0031577fe0 lr: 0xfffffe00208dc3fc fp: 0xfffffebf22666ee0 lr: 0xfffffe0020a82d74 fp: 0xfffffebf22666f30 lr: 0xfffffe00222f9964 fp: 0xfffffebf22667c00 lr: 0xfffffe002107c198 fp: 0xfffffebf22667c90 lr: 0xfffffe002107b79c fp: 0xfffffebf22667dc0 lr: 0xfffffe002107963c fp: 0xfffffebf22667e40 lr: 0xfffffe002107ffc8 fp: 0xfffffebf22667f20 lr: 0xfffffe00208e4f04 fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.AppleT8020DART(1.0)[6BE1928B-115D-345C-B457-FD1101FC7E1E]@0xfffffe00222f9120->0xfffffe002230139b dependency: com.apple.driver.AppleARMPlatform(1.0.2)[4EB15554-31E0-3057-9A85-EAA79C69E848]@0xfffffe0021369200->0xfffffe00213bf21f dependency: com.apple.driver.IODARTFamily(1)[8FC5A69F-6052-3F02-9EA3-78D080116812]@0xfffffe0022ec6750->0xfffffe0022eda9cf last started kext at 139867172: com.apple.plugin.IOgPTPPlugin 1340.12 (addr 0xfffffe001fba3f70, size 139368)

When attempting to open sysdiagnose logs collected from an iPhone running iOS 26 beta 3 on macOS Console, the application consistently crashes. Crash report has been added for reference. Apple Feedback- FB18834450