After the initial setup worked for regular builds, three edge cases needed fixing. Early exit on clean (BuildPkgTestCMD.sh) The pre-action runs even when cleaning, but there’s nothing to build and nothing to clean manually — PkgTestCMD lives inside the parent’s BUILD_DIR, so Xcode cleans it automatically. We just exit early. OBJROOT isolation (BuildPkgTestCMD.sh) We were already setting SYMROOT to keep build products inside the parent’s BUILD_DIR. Turned out OBJROOT (intermediates) also needed to be isolated, otherwise building PkgTestCMD standalone would conflict and produce “entitlements modified during build” errors. TARGET_BUILD_DIR (CopyPkgTestCMD.sh + outputPaths) During archive, Xcode always creates a temporary .app directory and copies the bundle there itself — it knows exactly what files it’s putting in. Copying our binary to BUILT_PRODUCTS_DIR meant injecting a file into that directory after Xcode had already done its packaging, so Xcode had no awareness of it. TARGET_BUILD_DIR is the correct destination: our binary lands inside the .app before Xcode packages it for archive, so Xcode naturally includes it and understands the final state of the bundle.

FB21931761 for improving algorithms. FB21934998 for improving documentation.

So splitting targets into different projects is a way to go, but do not make cross-project references and add target dependency. The idea is to build the subproject fully separately. Claude helped with implementation, so I asked it to write the rest of the post. The Solution Two scripts, triggered at different build stages: 1. Scheme Pre-Action — BuildPkgTestCMD.sh Builds the CLI project via a separate xcodebuild invocation before the main build starts. 2. Run Script Build Phase — CopyPkgTestCMD.sh Copies the built binary into the app bundle after the Resources phase. Both scripts check EFFECTIVE_PLATFORM_NAME and skip on non-Catalyst builds (e.g. iOS). Gotchas We Hit Build settings leaking into the nested xcodebuild call. Scheme pre-actions inherit all build settings from the parent target as environment variables. This means the nested xcodebuild silently picks up Catalyst platform, signing, and arch settings. Fix: wrap the call with env -i, passing through only selected variables: env -i \ PATH="$PATH" \ HOME="$HOME" \ TMPDIR="${TMPDIR:-/tmp}" \ xcodebuild \ -project "$PKGTESTCMD_PROJECT" \ -target PkgTestCMD \ -configuration "${CONFIGURATION}" \ SYMROOT="${BUILD_DIR}/PkgTestCMD" \ -quiet Script sandboxing blocks reading the script file itself. With ENABLE_USER_SCRIPT_SANDBOXING = YES (the default in recent Xcode), the Run Script phase can’t read its own .sh file unless it’s declared in inputPaths. Add the script path as the first input: inputPaths: $(SRCROOT)/PkgTest/CopyPkgTestCMD.sh $(BUILD_DIR)/PkgTestCMD/$(CONFIGURATION)/PkgTestCMD Archive fails with sandbox file-write-create deny. During archive, the .app inside BUILT_PRODUCTS_DIR is actually a symlink to INSTALL_DIR/Applications/... The sandbox builds its write-allow list from declared outputPaths but doesn’t resolve symlinks — so the write to the real path gets denied. Fix: declare both paths in outputPaths: outputPaths: $(BUILT_PRODUCTS_DIR)/$(EXECUTABLE_FOLDER_PATH)/PkgTestCMD $(DSTROOT)$(INSTALL_PATH)/$(EXECUTABLE_FOLDER_PATH)/PkgTestCMD The first covers debug/run builds, the second covers the resolved archive path. Result Debug builds, iOS builds, and archives all work correctly. The CLI binary ends up at PkgTest.app/Contents/MacOS/PkgTestCMD alongside the main executable.

iOS 26.1 is released, iOS 26.2 beta appeared, but no signs that UIManagedDocument loses @MainActor. Does anybody have the same concern? Anybody uses UIManagedDocument and wants to transition to Swift 6? Or, perhaps, already use it?

Thank you! I'll definitely send an improvement suggestion.

The thing with foo attribute is done on purpose to make a direct lightweight migration from V1 to V3 impossible. At the same time, it's possible to migrate using the intermediate V2.

Turned out that this is Xcode 16.3 which does it correctly. According to the Expression Macros design, macro parameters should be type-checked, so the macro implementation doesn't receive incorrect code as input. Thus Xcode <=16.2 erroneously allowed the wrong expression to be passed into my macro implementation, and this is fixed in Xcode 16.3.

Bug report: FB17081839.

I have the same problem. In may case, in the Monetization -> Pricing and Availability -> App Availability section for the app all of a sudden I started to have 2 countries in the Processing state. If your account is in the 'Processing' country then you can view the app in TestFlight but can't install it. I contacted developer support, they redirected me to App Store Notices but no replies from them so far.

Seems that the problem is fixed but partially. Now the issue only appears if UICollectionView.allowsMultipleSelection is true.

According to the step 2 of the doc you need to save the new document to a temporary location first. Try something like this: if let newDocumentURL = newDocumentURL, let appropritateURL = try? FileManager.default.url(for: .cachesDirectory, in: .userDomainMask, appropriateFor: nil, create: false), let newDocumentTempURL = try? FileManager.default.url(for: .itemReplacementDirectory, in: .userDomainMask, appropriateFor: appropritateURL, create: true).appendingPathComponent(newDocumentURL.lastPathComponent) { try! FileManager.default.copyItem(at: newDocumentURL, to: newDocumentTempURL) importHandler(newDocumentTempURL, .copy) } Btw, the doc's sample project also stopped to work for it creates a new document the same way. But with the above changes it starts to work.

Reasons for my post. Could you, colleagues, confirm that this is a bug but not incorrect setup of mine? If it's a bug then to bring attention of Apple engineers to the problem. :)

Confirm this for the main menu. uncached works only for context menus. Perhaps, the main menu (because of its persistence) needs to be rebuilt in order the closure ofUIDeferredMenuElement be called again. Dynamic menu item for the main menu can be achieved through UIResponder.validate(_:). Also, you can call UIMenuSystem.main.setNeedsRebuild() to update all menu items.

It turns out that the problem occurs when you have UIManagedDocument.revert() and external coordinated writing synchronized. What's more—the hanging occurs on macOS also. I simplified test to just call revert() and coordinate(writingItemAt:). If you run exactly the same test on UIDocument, everything works fine. I'm pretty sure that this is a bug in UIManagedDocument. As of now, I incline to override revert() in order to skip super's implementation of this method, because it's UIManagedDocument and, by logic, we can work with managedObjectContext.

Mention of this build setting should be in the Xcode documentation.