Xcode on Lessons learned

Xcode Archive can ship the wrong display name despite correct source settings

Thu, 29 Oct 2026 14:22:00 +0100

A production iOS archive had the production bundle ID and backend environment, but its CFBundleDisplayName was the beta name. The tagged source said otherwise, and App Store Connect never shows that name, so only an installed build revealed it. Add a Run Script phase that checks the processed app Info.plist, so a manual Product > Archive also rejects the wrong identity.

Using synthetic names, the mismatch was:

CFBundleIdentifier = com.example.notebook
CFBundleDisplayName = NotebookBeta

Source checks missed the artifact

The investigation initially ruled out the mismatch from project settings and runtime configuration checks. That conclusion was too strong. The runtime check validated the product variant against the backend environment; it did not validate the display name. A production bundle with a beta display name could satisfy it.

Reading the archived app’s plist settled the question. Its name disagreed with the committed production settings. An uncommitted local edit was the likely explanation, but the archive alone could not establish exactly how the value changed.

The release flow had no step that showed the name either. App Store Connect metadata covers the store listing’s app name, not the bundle’s CFBundleDisplayName, which only appears under the home screen icon. The only check is to install the production build from TestFlight, or from the App Store after release, and read that label by hand. It is easy to overlook when the bundle ID and backend already look right.

Source-level regression tests still help, but manual Archive does not run the scheme’s Test action. A check confined to a deployment lane also misses someone archiving directly in Xcode.

Check the processed plist during the build

Add a Run Script phase named Verify App Identity to the app target, after its existing phases. Use /bin/sh. Leave Run script only when installing unchecked.

Declare this Input File:

$(TARGET_BUILD_DIR)/$(INFOPLIST_PATH)

Declare this Output File:

$(DERIVED_FILE_DIR)/verified-app-identity.stamp

Uncheck Based on dependency analysis for this small guard. It should validate every build, including repeated archives. The input declaration still establishes the dependency on plist processing; visual phase order alone is insufficient. Apple’s Run Script documentation explains how declared inputs and outputs determine task ordering.

Paste this script, adapting the explicit configuration allowlist:

set -eu
: "${SCRIPT_OUTPUT_FILE_0:?Declare the stamp Output File}"
stamp="$SCRIPT_OUTPUT_FILE_0"
rm -f "$stamp"
: "${TARGET_BUILD_DIR:?}" "${INFOPLIST_PATH:?}" "${CONFIGURATION:?}"
plist="$TARGET_BUILD_DIR/$INFOPLIST_PATH"
fail() {
 printf 'error: %s\n' "$*" >&2
 exit 1
}
case "$CONFIGURATION" in
 Release)
 expected_id=com.example.notebook
 expected_name=Notebook
 ;;
 Debug)
 expected_id=com.example.notebook.beta
 expected_name=NotebookBeta
 ;;
 *) fail "No identity policy for configuration $CONFIGURATION" ;;
esac
[ -f "$plist" ] || fail "Missing processed Info.plist: $plist"
id=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' "$plist") ||
 fail 'Cannot read CFBundleIdentifier'
name=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleDisplayName' "$plist") ||
 fail 'Cannot read CFBundleDisplayName'
[ "$id" = "$expected_id" ] && [ "$name" = "$expected_name" ] ||
 fail "$CONFIGURATION requires $expected_id / $expected_name; got $id / $name"
printf 'Verified app identity: %s / %s\n' "$id" "$name"
: > "$stamp"

Do not substitute the source INFOPLIST_FILE: generated keys and build-setting expansion can change the packaged values. Keep the expected identity independent of the settings under test.

The declared paths also describe the script’s file access for user-script sandboxing. Keep sandboxing enabled where possible and test these declarations with your Xcode version. The original target had it disabled. The stamp lives outside the signed app and is created only after validation. Removing it first, failing on missing values, and running unconditionally prevent an old stamp from becoming a false success after a failed check.

Prove that wrong builds fail

The historical implementation passed normal builds across all four original configurations. Four deliberate mutations failed: the production ID, production name, beta ID, and beta name, changed separately. Each failure reported the mismatched identity; the project file was restored afterward. These were build checks, not evidence of a fresh Archive after the fix.

For your project, repeat those negative controls, then restore the settings and archive twice without cleaning. Confirm the guard runs both times and inspect the resulting archive’s app plist. Also test a missing key and an unrecognized configuration.

This checks the app’s base plist only. Localized InfoPlist.strings can affect the displayed name, and extensions need separate policies. Check the Archive action’s selected configuration in your scheme, then deliberately break its display name and confirm Archive fails before trusting the guard.

xcodebuild says TEST SUCCEEDED, the xcresult says "Issues recorded without an associated test or suite"

Mon, 28 Sep 2026 12:16:00 +0200

A branch passed locally. xcodebuild test exited 0 and printed:

** TEST SUCCEEDED **

The fastlane coverage lane on the same branch failed with Tests have failed and didn’t name a test. Scan’s xcpretty output doesn’t show Swift Testing results, so the log didn’t include any failing tests. The result bundle had the answer:

xcrun xcresulttool get test-results summary --path Test.xcresult

{'result': 'Failed', 'totalTestCount': 2320, 'passedTests': 2317, 'failedTests': 1, ...}
testName: Issues recorded without an associated test or suite
failureText: Issue recorded: failed - Unimplemented: Unimplemented AppVersionClient.currentVersion …
 This issue was emitted from tests running in a host application.
 This can lead to false positives, where failures could have emitted from live application code at launch time, and not from the current test.

If your console is green and fastlane, Xcode Cloud or anything else that reads the .xcresult is red, check the summary for that pseudo-test before you go looking for a flaky test.

Setup

Xcode 26, Swift Testing, an app-hosted unit test target (tests run inside the real app process).
swift-dependencies 1.14, with a client whose testValue calls IssueReporting.unimplemented(...). That’s the usual way to make sure a test sets every dependency it uses.
The app’s root view is a login screen. On appear, it asks a backend for the minimum supported version and compares it with currentVersion().

What happened

Because the app hosts the tests, it launches as it does for a user, and its login screen sends the version request. When the response arrives, the screen reads the version client inside a test process, which resolves to the unimplemented test value and records an issue. No test is running on that code path, so the issue gets attached to no test.

The console run only shows it as a warning:

⚠︎ Test «unknown» recorded a warning at VersionClient.swift:24:1: Issue recorded
↳ failed - Unimplemented: Unimplemented AppVersionClient.currentVersion …

The result bundle counts it as a failure, though, and fastlane reads it.

Main didn’t fail, and the new branch didn’t touch any of this code. Its only addition was a new app-hosted suite that took about seven seconds. That extra time let the response arrive while tests were still running. On main, the run was over before the response came back. This is timing-dependent, so a faster backend or a slower one can hide the failure or bring it back.

Reproduce one target and compare the result bundle summaries:

Run	Total	Failed
Hosted target, as is	21	1
Same, new suite skipped (`-skip-testing`)	16	0
Same, with the fix	20	0

The 21 in the first row is 20 real tests plus the pseudo-test.

Dead end: set the dependency at launch

The obvious fix is to give the app a live value in its entry point:

prepareDependencies {
 $0.appVersion = AppVersionClient { Bundle.main.shortVersion }
}

It built and changed nothing. The same failure showed up again. In a test process, swift-dependencies resets its cached values for each test: it registers an XCTest observer that clears the cache whenever a test case starts. The value you prepare at app launch is gone once the tests start, and the later response reads the test value again.

Fix: don’t show the app UI while hosting tests

isTesting from IssueReporting (re-exported by Dependencies) is true inside a test process. Gate the scene’s content on it:

import Dependencies
import SwiftUI

@main
struct MyApp: App {
 var body: some Scene {
 WindowGroup {
 // Unit tests run inside this app. Its login screen would start a
 // network request whose response reads an unimplemented test dependency.
 if !isTesting {
 RootView()
 }
 }
 }
}

This is the workaround in the library’s Testing gotchas docs. Before applying it, check that no hosted test needs the app’s window or a view in the scene. Here, none did, because the tests only needed a real UIApplication, which still exists with an empty WindowGroup. The shipping app is unchanged, since isTesting is false outside a test run.

With the fix, the hosted target passed 20 of 20, the whole coverage lane reported 0 failures on both schemes, and the test run stopped sending requests to the dev backend.

That last part is a nice bonus. A test host that shows its real UI talks to real servers from your CI, and anything it logs (request and response bodies, anti-forgery tokens) ends up in your test logs.

Takeaway

An app-hosted test run also runs your app. Anything the app starts on its own at launch can record a failure that belongs to no test and shows up only in the .xcresult. Keep the UI out of the test host with if !isTesting, and when the console and the lane disagree, read xcresulttool get test-results summary first.

Try it on your own app-hosted target: grep a recent test log for Test «unknown» recorded. Each hit is an issue recorded outside any test, and the result bundle may already count it as a failure.