Ursache des Integritaetsfehlers festhalten: veraltetes Profil im Xcode-Zwischenspeicher

2026-08-29 13:16:02 +02:00
parent 49712f7c7a
commit b6a868df5e
1 changed files with 24 additions and 1 deletions
@@ -4677,8 +4677,31 @@ be opened in **Safari** — other browsers do not hand `itms-services://` to the
 refuses a non-`https://` base outright rather than producing a manifest that fails silently on the
 phone.
 **"App cannot be installed because its integrity could not be verified" — it was a stale cached
 provisioning profile.** First install attempt failed on the phone with that message. Everything on
 the signing side measured clean, which is worth listing because it is the exact set of things not to
 re-check next time: the `.ipa` fetched through Cloudflare was **byte-identical** (same SHA-256),
 `codesign --verify --deep --strict` passed and satisfied its Designated Requirement, the signing
 certificate was valid to 2027, the WWDR intermediates were current (G3→2030, G6→2036), and the
 entitlements carried the right `application-identifier`.
 The cause was the one thing not visible from the artifact: the embedded ad-hoc profile listed **one**
 device, and by then the team had **two** registered. Registering a device at Apple does **not**
 invalidate profiles already issued, and `-allowProvisioningUpdates` happily re-uses whatever sits in
 `~/Library/Developer/Xcode/UserData/Provisioning Profiles` — so a rebuild silently keeps embedding the
 outdated device list. **Fix: delete the cached `.mobileprovision` for that profile, then re-export.**
 A full re-archive is unnecessary — `xcodebuild -exportArchive` re-signs, so ~1 minute against the
 existing `.xcarchive` is enough. Verified afterwards: profile now lists both
 `00008130-001C089E3E8A001C` and `00008140-000229913A0B001C`, still valid to 2027-08-29.
 Not used, though the owner offered it: a hand-downloaded `Audi_App.mobileprovision`. It was a
 **development** profile (`get-task-allow: true`) with a **7-day** life, so it would have needed
 Developer Mode on the phone, a development certificate instead of the distribution one, and a
 re-install every week. Its value was diagnostic, not operational — it is what revealed the second
 device.
 **Still open at end of session:** this Mac is logged out of Tailscale (`BackendState: NeedsLogin`),
-so no host was serving yet and the over-the-air install is **built but not yet exercised end to end**.
+which is moot while Gitea hosts the install (section AJ).
 Also untouched: `MARKETING_VERSION` is still `1.0`/`1` from the Capacitor scaffold, so successive
 `.ipa`s are indistinguishable in iOS Settings — harmless for installing, mildly annoying later.