In the archived documentation for Distribution Definition files (https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html), the allowed-os-versions and os-version element are partially documented. I have a few questions about these elements: allowed-os-versions The documentation states: Availability: Available in OS X v10.6.6 and later. Has this element always worked correctly in the past? I'm asking because it does not seem to work correctly on OS X v10.14 for the min attribute of a sub os-version element. os-version The documentation states: This element is designed for you to use a specific OS version number for the min attribute, and a major OS version number for the before attribute. The expectation is that you will know an exact minimum version but not an exact major version. This keeps you from having to guess the last minor revision before the next major revision, as you would have to do if the before attribute were inclusive. This is quite confusing because the documentation never explicitly says what a specific or major OS version number is. Is specific major.minor.patch or major.minor? What is major? major or major.minor? As the documentation was created at a time where the OS version scheme was: 10.minor.patch (and minor was actually the major) and we are now in an era where the OS version is major.minor.path, this is even more confusing. I would also be curious to know what the major version is officially supposed to be for macOS Tahoe in this case. 16 or 26? Generally speaking, this documentation is missing examples for a lot of the elements. Also why is there a tag for InstallerJS and not one for Installation in the Developer Forums?

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.

I want to test different types of journaling suggestions, like for example photo/video containing ones but as a developer I have no control over what's shown in the Journaling Suggestions sheet. And this makes it really difficult to develop or test any suggestion type other than "reflection". Please let us have a fake suggestions sheet that includes all kinds of suggestion types so we can test. We could toggle it under Developer settings I think.

Is anyone seeing flaky results when using parameterized test with pairs of (input, result) data? I have several (5) tests for a given method. I create a zip sequence by zip([in1, in2, in3, in4, in5],[out1, out2, out3, out4, out5]) Sometimes, the test only runs 4 of the tests and fails to report a failure even though I deliberately place data that should cause a failure. Sometimes, even though I only select one test to run, the test explorer goes crazy into a loop and I have to clear test results to get it to stop. Following a suggestion, I disabled running tests in parallel. Xcode 16.2 / OSX 14.7 (Sonoma) / Mac mini M2 Pro

Hi. I have an iPad 7th gen running iPadOS 14.8.1. For testing purposes, I want to upgrade it to the latest release of iPadOS 17, even though the device wants me to upgrade to iPadOS 18.5. Is there a way to upgrade it to iPadOS 17? btw this would free-up a newer iPad running iPadOS 17 so I can install iPadOS 26 beta. Thank you.

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.

We have a macOS application packaged as a .pkg file. To notarize it, we first code-sign individual library folders and the .app bundle using the following command: codesign --force --deep --sign "Developer ID Application: &amp;lt;Our Account Name&amp;gt;, LLC (Team ID)" "Our_product.app" Code Sign result for .app file: Our_prodcut.app: valid on disk Our_product.app: satisfies its Designated Requirement We are using packages tool to create .pkg file with code signed .app file. Steps followed once .pkg file is ready: 1. Product Sign: productsign -sign "Developer ID Installer: &amp;lt;Our Account Name&amp;gt;" output.pkg signed-output.pkg 2. Submit for notorization: `xcrun notarytool submit signed-outout.pkg --keychain-profile "notarytool-password" --wait Received following output: Current status: Accepted................................. Processing complete id: 2d5c450f-5b22-4b4d-9579-ef21c0356548 status: Accepted Transferred Notarization log: xcrun notarytool log 10169892-b28c-407c-b348-edab0b34ef34 --keychain-profile "notarytool-password" Desktop/developer_log_6.json We have observed log with "Accepted" status with issues as "null". 3. Stapler: stapler staple signed-output.pkg stapler validate signed-output.pkg Processing: signed-output.pkg The validate action worked! 4. Checking status of .pkg file: Command: spctl --assess --verbose=4 signed-output.pkg Output: signed-output.pkg: rejected source=no usable signaturess Warning During Installation: While installing the .pkg file, a security warning appears as follows. Please help us to resolve this.

Q. Is there a plan to finally document the PackageInfo file format used in .pkg flat package? The man page for pkgbuild is not really useful to understand the different options. It does not seem to make sense to have an official documentation for the Distribution Definition file but not for the PackageInfo file.

Hi, We are seeing the below error in our angular application where we use the custom elements. Can you please help us to resolve the issue? [Error] TypeError: new.target does not define a custom element. The same code works fine in other browsers.

I’m using iOS 26 right now, can’t go back to iOS 18 cuz I did not backup and my phone is so laggy right now i cant even turn off developer mode help me please

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 I try to get a new API Key I get the following error. "API Keys cannot be created due to an invalid Program License Agreement. Please update this agreement and try your request again." I have been to the agreement section, and it says: "Issued October 8, 2025. Accepted November 19, 2025." Any idea why I still get this error?? Not sure if that makes a difference. I had a paid account, but I didn't renew it because I don't need it anymore, and I was told that I can still use this account for free for app testing.

When building binutils (2.4.4) on Mac OS Sequoia (15.4), a compilation error occurs. In file included from ../../zlib/gzguts.h:21: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdio.h:61: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_stdio.h:318:7: error: expected identifier or '(' 318:7: error: expected identifier or '(' 318 | FILE | FILE fdofdopen(int, cpen(int, const char onst char ) __DARWI) __DARWIN_ALIN_ALIAS_STARTIAS_STARTING(__MAC_NG(__MAC_10_6, __I10_6, __IPHONE_2_0PHONE_2_0, __DARWI, __DARWIN_ALN_ALIAS(fIAS(fdopen)); dopen)); | ^ | ^ ../../zlib/zutil.h:147:33: note: expanded from macro 'fdopen' 147 | # ../../zlib/zutil.h:147:33: note: expanded from macro 'fdopen' 147 | # define define fdopefdopen(fd,moden(fd,mode) NULL /) NULL / No f No fdopen() *dopen() */ | ^ / | error.txt In 1311 Line.

I'm finding developing for HomeKit using the iOS Simulator utterly confounding. All of my home's actual HomeKit accessories show up fine when I run the HomeKit app I'm developing on my actual phone. But none show up when I run my app in the iOS Simulator. Maybe that's how it's supposed to be? I decided to run the HomeKit Accessory Simulator in an attempt to get something to show up in the iOS Simulator, but the accessories I've created there don't show up in the Simulator either. How do I get devices to show up in the iOS Simulator? Thanks.

I have static libraries and headers of a C++ project that I believe are correctly built for iOS and iOS Simulator destinations. The C++ project is built via CMake with something like: cmake dirName \ -G "Unix Makefiles" \ -B buildDir \ -DCMAKE_INSTALL_PREFIX=installDir \ -DCMAKE_SYSTEM_NAME=iOS \ -DCMAKE_SYSTEM_PROCESSOR=arm64 \ -DCMAKE_OSX_ARCHITECTURES=arm64 \ -DCMAKE_OSX_SYSROOT=$(xcrun --sdk iphonesimulator --show-sdk-path) \ -DCMAKE_OSX_DEPLOYMENT_TARGET=15.0 ... cmake --build buildDir --config Release --target install I believe those are all the important parameters. This gives me a static library (.a) and headers that I believe should be compatible with arm64 iOS simulators, and I do this same thing for x86_64 architecture with simulators and for actual iOS non-simulator via the iphoneos SDK path. I'm pretty sure this gives me the correct static lib and headers. Let's assume it does because I'm not able actually create the XCFramework to know if they're right. This does work with a macOS lib and headers, but I need iOS for this library. How do I package this into an XCFramework now? This Apple developer articles says I should be a able to create an xcframework via xcodebuild -create-xcframework -library libName.a -headers include but when I try to do this with my my iOS arm64 simulator static lib I get: error: binaries with multiple platforms are not supported '/Users/.../install/ios-arm64-simulator/libName.a But, when I run: lips -info libName.a I get Non-fat file libName.a is architecture arm64, so, I'm not sure what to do here. Trying to extract arm64 from that static library also produces an error as it it is just an arm64 lib. I'm not really sure what's going on, but from reading online this specific command, xcodebuild -create-xcframework is a consistent pain point in the process of trying to get an XCFramework, and the seemingly only workaround is to archive a framework project and then create the xcframework via xcodebuild -create-xcframework -archive MyFramework.xcarchive -framework[or -library]. However, how am I supposed to get this static lib and headers into a suitable xcodeproj so that I can archive it correctly? Everytime I try to copy the headers and static lib into the Framework xcodeproj and set what I believe are all the correct settings, my .xcarchive is always empty. Does anyone have any advice here on how to get this to work? The main impetus for trying to get this C++ static lib and headers into an XCFramework as that seems like the only valid way to link a 3rd party C++ lib to an SPM package and have the C++ package be interfaceable with Swift.

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

hey I accidentally deleted my info.plist with holds my app version and other critical things and I don't know how to get it back or how to recode it

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

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?

I'm exploring using a handful of frameworks to share code between macOS apps. However, one of these frameworks needs privilege to function. The main app has a helper tool utilizing SMAppService. However, I can't work out if there's a feasible way to use that helper tool to support the framework dependency. Should I be creating a second helper tool for the framework instead? Or am I barking up the wrong tree? Thanks!