Skip to content

fix(ios): TestFlight build number must be < 2^32 (date +%s)#207

Merged
oratis merged 1 commit into
mainfrom
fix/testflight-build-number
Jul 1, 2026
Merged

fix(ios): TestFlight build number must be < 2^32 (date +%s)#207
oratis merged 1 commit into
mainfrom
fix/testflight-build-number

Conversation

@oratis

@oratis oratis commented Jul 1, 2026

Copy link
Copy Markdown
Owner

testflight.sh defaulted BUILD_NUMBER=date +%Y%m%d%H%M → a 12-digit stamp (~2e11), 47× over Apple's CFBundleVersion limit of 2³²−1. The transporter accepts the upload ("EXPORT SUCCEEDED") but processing silently rejects it (ITMS-90062) — the build never appears in TestFlight and no error is shown. This silently broke every timestamp upload (e.g. 202607012336, 202607011716 — neither ever registered; ASC only ever had builds 1–6 from elsewhere).

Fix: date +%s (Unix seconds, ~1.8e9) — under 2³², monotonic, unique per second, valid until 2106.

Confirmed by re-uploading build 1782922384 (valid number) from main (with the #206 chat fix).

🤖 Generated with Claude Code

…d%H%M)

CFBundleVersion components are capped at 2^32-1 (4,294,967,295). The old default
`date +%Y%m%d%H%M` produces a 12-digit stamp (~2e11) — 47x over the limit. Apple's
transporter ACCEPTS the upload ("EXPORT SUCCEEDED") but processing then silently
rejects it (ITMS-90062) and the build never reaches TestFlight — no error surfaced
to the uploader. Every timestamp upload was failing this way.

Switch to `date +%s` (Unix seconds, ~1.8e9): under 2^32, monotonic, unique per
second, valid until 2106.

Verified: re-uploaded build 1782922384 with this scheme.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@oratis oratis merged commit 858231f into main Jul 1, 2026
1 check passed
oratis added a commit that referenced this pull request Jul 1, 2026
) (#208)

* fix(ios): MARKETING_VERSION 0.1.0 → 1.0 (must be >= app's App Store version)

The App Store Connect record for Lisa Pocket is at version 1.0
(PREPARE_FOR_SUBMISSION), with builds under the 1.0 train. project.yml still
carried a stale "0.1.0", so testflight.sh archives declared CFBundleShortVersionString
0.1.0 — LOWER than 1.0. App Store Connect silently rejects a too-low marketing
version at ingestion: the upload reports "EXPORT SUCCEEDED" but no build ever
appears in TestFlight (no 0.1.0 train is even created).

Together with the build-number fix in this branch, this is the second half of
"why don't my uploads show up." Bump to 1.0 so archives attach to the existing
train by default.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(ios): stamp CFBundleVersion into the generated Info.plists (override was a no-op)

xcodegen writes a LITERAL CFBundleVersion ("1") into Sources/Info.plist and
Widgets/Info.plist, so `xcodebuild archive … CURRENT_PROJECT_VERSION=$BUILD_NUMBER`
never changed the shipped build number — every archive was build "1". App Store
Connect kept rejecting them as "Redundant Binary Upload" (and the earlier ones
under the wrong 0.1.0 train vanished outright).

After `xcodegen generate`, plutil-replace CFBundleVersion in both the app and the
widget extension (they must match, or embedded-binary validation fails) with
$BUILD_NUMBER. Verified locally: post-generate both read "1"; post-patch both read
the timestamp and are equal.

Third of three TestFlight-upload fixes in this branch (build# < 2^32, marketing
version >= app version, and now the build# actually reaching the binary).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant