The App Store bottleneck is not the build, it is the 2FA prompt sitting inside your CI job

A developer writing on dev.to has published the auth layer of a pipeline that puts iOS apps into App Store review without anyone logging into App Store Connect, and the interesting part is not the automation but the diagnosis: he argues the bottleneck in shipping iOS apps at volume is submission, not development ^[2]. That matters because the standard tool for the job, fastlane's `deliver`, is built on a session cookie, and when the cookie expires it fires an interactive auth prompt, which on CI is a dead end ^[6].

Look at the manual path he describes: open Xcode, click Archive, log into App Store Connect, wait for the 2FA SMS, pick a build, hit Submit for Review ^[3]. For one app that is a nuisance. At five or ten apps managed at once it becomes recurring labor, every week ^[4]. The structural point is sharper than the tedium: anything that depends on 2FA cannot be handed to a bot ^[5]. A human has to be awake and holding a phone.

The replacement is an App Store Connect API key, the `.p8` file. Issue it once and you can call the API without two-factor authentication, and it does not expire until you explicitly revoke it ^[7]. According to the author, that single property is what lets an agent run "submit for review" at 2 a.m. with no one present ^[8]. He says he manages 12 apps, some shipping a new version the same day, and that a shell loop over an `app_ids.txt` file submits all of them in parallel while he drinks coffee ^[1][9]. His framing: opening Xcode every time is a task, whereas "anyone (or anything) with the API key can submit" is an environment ^[19].

Storage is two files under `~/.appstoreconnect/`: a `keys.json` holding `key_id`, `issuer_id` and `key_path`, plus the `.p8` private key itself, which App Store Connect lets you download exactly once ^[14]. The submission tool he uses is 272 lines of Python exposing three verbs, `apps`, `status` and `submit`, and he says it covers nearly every operation the review lifecycle needs ^[13]. It sits as layer three of a three-layer split: `xcodebuild archive` or `eas build --local` for the binary, `eas submit` for transfer, then the API client for state checks, metadata edits and review submission ^[12].

Now the part worth budgeting time for. Apple's ES256 JWT requires the raw r-concatenated-with-s signature encoding defined in RFC 7518, and Python's crypto library returns DER by default, so passing it through unchanged guarantees a broken token ^[10]. The API does not say "invalid signature." It returns 401 Unauthorized, which makes the cause invisible on first contact ^[11]. The author's headline puts the cost of that at two hours ^[18].

Treat the revenue arc around this with the usual caution: it is self-reported and single-sourced. He describes going from roughly 100,000 yen a month as a student to 600,000 by stacking side gigs, then to zero after a layoff, then past 1.2M a month six months later around an autonomous Claude Code setup ^[15]. That is double his pre-layoff peak ^[17], and he attributes it to increasing the number of things that work in his place rather than his own hours ^[16].

What to watch: whether the promised part two publishes the JWT signing code, since the DER-versus-raw detail is the whole difficulty ^[10]. And a governance question the piece does not address: a credential that never expires and needs no second factor is exactly as durable in someone else's hands as in yours ^[7].