Two Hours Lost to a Silent 401: Submitting 12 iOS Apps to the App Store With No Human in the Loop (Part 1)

A developer who rebuilt his income around an autonomous Claude Code environment reports monthly revenue surpassing ¥1.2M after being laid off. He details how an App Store Connect API key enables fully automated app submissions without human interaction, eliminating the 2FA bottleneck. The key technical challenge is correctly generating an ES256 JWT with raw r||s encoding, as Python's default DER encoding causes silent 401 errors.

I went from earning about ¥100,000 a month as a university student to ¥600,000 by stacking side gigs — then got laid off and dropped straight back to zero. Six months later, after rebuilding everything around an autonomous Claude Code environment, monthly revenue is past ¥1.2M. The piece of that environment I want to open up here is the one that lets apps go into App Store review without a human ever logging into App Store Connect. When you try to ship iOS apps in volume, the bottleneck isn't development — it's submission. Open Xcode, click Archive, log into App Store Connect, wait for the 2FA SMS, pick a build, hit "Submit for Review." For a single app it's no big deal. Once you're managing five or ten at once, that sequence becomes pure recurring labor, every week. There's a more fundamental problem too: anything that depends on 2FA can't be handed to a bot . fastlane's deliver is convenient, but every time the session cookie expires, an interactive auth prompt fires. On CI, that's a dead end. An App Store Connect API key the .p8 file removes the problem at the root. Issue the key once and you can hit the API without two-factor authentication . There's no expiration either — it lives until you explicitly revoke it. Which means that in an environment where this key is present, Claude Code can autonomously run "submit for review" at 2 a.m. Right now I manage 12 apps. Some of them ship a new version on the same day. The hours a human can sit in front of a screen are finite, but the API can be hit in parallel . Once a loop like for app id in $ cat app ids.txt ; do python3 ~/.appstoreconnect/asc.py submit "$app id"; done is running, every app gets submitted while I'm drinking coffee. "Open Xcode every time" is a task. "Anyone or anything with the API key can submit" is an environment. Grinding through tasks caps your income at the number of hours you have. Build the environment and the system runs while you sleep. Most of the reason revenue is 12× what it was in my university days isn't that I increased my own workload — it's that I increased the number of things that work in my place . The ASC API key is one emblematic example. "With an API key, you just generate a JWT and call the API" is technically correct — but if the implementation is off by one step, you get 401 forever. Apple's ES256 JWT requires the raw r‖s encoding defined by RFC 7518 . Python's crypto library returns DER by default, so using it as-is guarantees a broken JWT. On first encounter, the cause is completely invisible, because the error comes back as "401 Unauthorized" rather than "Invalid signature." In the next section I'll get concrete about what this trap actually is, and about the code I'm really using. Start with the big picture. From binary generation to App Store review submission, my environment splits into three layers. ┌─────────────────────────────────────────────────────────┐ │ Layer 1: バイナリ生成 │ │ xcodebuild archive tools/archive.sh │ │ または eas build --local Expo系アプリ │ └──────────────────┬──────────────────────────────────────┘ │ .ipa ▼ ┌─────────────────────────────────────────────────────────┐ │ Layer 2: バイナリ転送 │ │ eas submit Transporter相当・クラウド枠消費ゼロ │ └──────────────────┬──────────────────────────────────────┘ │ processingState: VALID ▼ ┌─────────────────────────────────────────────────────────┐ │ Layer 3: 状態確認 / メタ編集 / 審査提出 │ │ python3 ~/.appstoreconnect/asc.py {apps|status|submit}│ │ 2FA不要・JWT認証・アカウント横断で使える │ └─────────────────────────────────────────────────────────┘ Layer 3 is the topic here. asc.py is only 272 lines, but it covers nearly every operation the review lifecycle needs. 全アプリ一覧 python3 ~/.appstoreconnect/asc.py apps 特定アプリの審査状態・ビルド状態を確認 python3 ~/.appstoreconnect/asc.py status <app id 審査に提出 python3 ~/.appstoreconnect/asc.py submit <app id Let's walk through why this runs without 2FA, and how it's implemented internally. The App Store Connect API key is managed as two files under ~/.appstoreconnect/ . ~/.appstoreconnect/keys.json { "key id": "XXXXXXXXXX", "issuer id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "key path": "~/.appstoreconnect/AuthKey XXXXXXXXXX.p8" } ~/.appstoreconnect/AuthKey XXXXXXXXXX.p8 the private key itself, downloadable from ASC exactly once At the top of asc.py , keys.json is loaded and those three values are held as constants. CFG = json.load open os.path.expanduser "~/.appstoreconnect/keys.json" KEY ID, ISSUER = CFG "key id" , CFG "issuer id" P8 = os.path.expanduser CFG "key path" The only secret is the single .p8 file. keys.json contains nothing but the key ID and issuer ID. That separation matters: even if keys.json ends up in Git not that I recommend it , it isn't an immediate leak incident. Managing just the .p8 strictly is enough. In my environment the .p8 sits in ~/.appstoreconnect/ and the whole directory is chmod 700 . When putting this on CI/CD, write the file out from a secret store at runtime. The heart of JWT auth is the jwt function. Here's the actual code, verbatim. python def b64 b : return base64.urlsafe b64encode b .rstrip b"=" def jwt : h = b64 json.dumps {"alg":"ES256","kid":KEY ID,"typ":"JWT"}, separators= ",",":" .encode p = b64 json.dumps {"iss":ISSUER, "iat":int time.time -30, "exp":int time.time +900, "aud":"appstoreconnect-v1"}, separators= ",",":" .encode signing = h + b"." + p key = serialization.load pem private key open P8,"rb" .read , password=None der = key.sign signing, ec.ECDSA hashes.SHA256 r, s = decode dss signature der return signing + b"." + b64 r.to bytes 32,"big" + s.to bytes 32,"big" .decode The trap is in the last two lines. key.sign returns the ECDSA signature in DER format. DER carries an ASN.1 structure, in the form 30 xx 02 xx r-bytes 02 xx s-bytes . Apple does not accept this DER. What Apple's ES256 JWT requires is the "fixed 64-byte raw encoding" defined in RFC 7518 Section 3.4. That is: r as 32 bytes and s as 32 bytes, big-endian, concatenated into 64 bytes total, then Base64URL-encoded. NG: DERをそのままBase64URLにしても401になる b64 der OK: DERをデコードしてr,sを取り出し、生の32バイトで連結する r, s = decode dss signature der b64 r.to bytes 32, "big" + s.to bytes 32, "big" decode dss signature is a function from the cryptography library that converts a DER-format signature into a Python integer tuple r, s . From there, to bytes 32, "big" turns each into a 32-byte sequence, and you concatenate them and Base64URL-encode — that's the correct procedure. Why 32 bytes? Because ES256 uses the NIST P-256 curve, and that curve's order fits in 32 bytes 256 bits . Even when r or s happens to be a small value leading byte zero , it must still be zero-padded to 32 bytes. r.to bytes 32, "big" handles that automatically. Get this implementation wrong and what Apple returns is always 401 Unauthorized . It's a signature verification failure, but it comes back as "authentication failed" rather than "bad signature," so it takes a while to realize the problem is in the JWT structure. iat is 30 seconds in the past One more small but important point. "iat": int time.time - 30, iat issued at is set 30 seconds before the current time. The reason is clock skew. If Apple's API servers and your local machine are slightly out of sync, the JWT can be rejected as "not yet valid." I actually lost tens of minutes to this once. Leaving a 30-second margin absorbs virtually all environmental differences. The expiration is set to 900 seconds 15 minutes from now. That's plenty for a JWT that gets thrown away after one request. Here's the full list of subcommands asc.py provides. | Command | Purpose | |---|---| apps | Print every managed app ID, Bundle ID, name | status <id | Check version state, review state, and the processing state of the latest build | submit <id | Submit the editable version for review create reviewSubmission → add item → submitted=true | make-version <id <ver | Prepare or update the version string on the App Store | attach-build <id <ver | Attach a processed build to a version | whatsnew <id <text | Set the "What's New" text for all locales at once | release <id <ver <whatsnew | Run the three above together for verification; does not submit | reject <id | Withdraw an in-review submission via Developer Reject | dedup <id --apply | Detect and delete duplicate screenshots dry-run / apply toggle | add-tester <id | Idempotently add a TestFlight internal tester | The design axis is idempotency . For example, before submitting for review, submit checks whether a READY FOR REVIEW reviewSubmission already exists and reuses it if so. python def submit app id, platform="IOS" : , rs = call "GET", f"/v1/reviewSubmissions?filter app ={app id}&filter state =READY FOR REVIEW&limit=1" sub = rs.get "data" or None 0 if not sub: 新規作成 st, r = call "POST", "/v1/reviewSubmissions", {...} ... sid = sub "id" バージョンをitemとして追加 ... submitted=true で提出 st, r = call "PATCH", f"/v1/reviewSubmissions/{sid}", {"data": {"type": "reviewSubmissions", "id": sid, "attributes": {"submitted": True}}} For an automation script, "running the same command twice doesn't break anything" is a hard requirement. When Claude Code retries, or when a network error causes a re-run, double submissions and duplicate errors must not happen. Check current state with a GET before operating — I apply that pattern to every write command without exception. Let's also look at tools/archive.sh , which produces the binary. xcodegen generate rm -rf build/Auraly.xcarchive build/export xcodebuild archive \ -project Auraly.xcodeproj \ -scheme Auraly \ -configuration Release \ -archivePath build/Auraly.xcarchive \ -destination 'generic/platform=iOS' \ CODE SIGN STYLE=Manual \ CODE SIGN IDENTITY="Apple Distribution" \ PROVISIONING PROFILE SPECIFIER="Auraly AppStore" \ -allowProvisioningUpdates xcodebuild -exportArchive \ -archivePath build/Auraly.xcarchive \ -exportOptionsPlist ExportOptions.plist \ -exportPath build/export The key point is CODE SIGN STYLE=Manual . With Automatic Signing, Xcode tries to manage provisioning profiles itself, which can pop an auth dialog during headless runs. Setting Manual and specifying the profile by name makes GUI-free builds stable. The provisioning profile itself is generated and installed automatically from the ASC API by tools/setup signing.py . It creates an App Store distribution profile via the /v1/profiles API and writes it directly into ~/Library/MobileDevice/Provisioning Profiles/ , so the signing environment is ready without ever opening Xcode. Certificate matching uses the SHA1 fingerprint: LOCAL SHA1 = "EC06777A693874E920CECFE390D467670552CCCE".lower ... der = base64.b64decode content sha1 = hashlib.sha1 der .hexdigest if sha1 == LOCAL SHA1: return c "id" This reconciles the local distribution certificate with the certificate on ASC. That removes the need for a human to sit at a screen deciding "which keychain certificate do I use?" In the next post Part 2 , I'll go into detail on wiring this asc.py into Claude Code's autonomous loop, the full pipeline that manages 12 apps, and the diagnosis and breakthrough procedure for when submissions kept getting rejected with INVALID BINARY. asc.py has exactly one dependency: the cryptography library. For HTTP it uses urllib.request . python def call method, path, body=None : url = path if path.startswith "http" else BASE + path data = json.dumps body .encode if body is not None else None req = urllib.request.Request url, data=data, method=method, headers={"Authorization":"Bearer "+ jwt , "Content-Type":"application/json"} try: r = urllib.request.urlopen req ; raw = r.read return r.status, json.loads raw if raw else None except urllib.error.HTTPError as e: return e.code, json.loads e.read or b"{}" The reason for not using requests is simple: a script that runs on the Python standard library alone can be carried into any environment unconditionally . Setting up a new Mac, deploying to a CI environment — removing a single pip install requests step changes the friction completely. One more thing: call calls jwt every time and generates a fresh JWT. Since the JWT has a 900-second 15-minute lifetime, caching the same JWT within a single script run would be harmless. But I deliberately don't cache it. The reason is to prevent the half-broken failure mode where a JWT expires partway through a long batch and only the later requests come back 401. Regenerating every time is marginally slower, but the cost is one ECDSA signature per request — microseconds. Even running all 12 apps in one pass, there's no perceptible difference. HTTPError handling is kept minimal too. It returns the status code and response body as-is, and callers stick to the if st = 400: ... return pattern. Branching control flow with exceptions mixes in stack traces and hurts readability, so I keep a consistent "judge by number, return early" style. The part that gave me the most trouble when I first implemented this was "identify a processed build by its marketing version the display version, like 0.3.2 ." The /v1/builds endpoint response includes the build number the integer build number but not the marketing version string. The marketing version lives on a separate resource called preReleaseVersion , and it isn't returned unless you explicitly pass include=preReleaseVersion in the query. python def build for version app id, version string : , b = call "GET", f"/v1/builds?filter app ={app id}&limit=20&sort=-uploadedDate" f"&include=preReleaseVersion" incl = {i "id" : i for i in b.get "included", if i "type" == "preReleaseVersions"} for x in b.get "data", : if x "attributes" .get "processingState" = "VALID": continue pr = x.get "relationships", {} .get "preReleaseVersion", {} .get "data" ver = incl.get pr "id" , {} .get "attributes", {} .get "version" if pr else None if ver == version string: return x "id" , x "attributes" .get "version" return None Adding include=preReleaseVersion puts objects of type preReleaseVersions into the response's included array. Turning that into a dict keyed by ID incl and looking up each build's relationships.preReleaseVersion.data.id is the crux of this code. Skipping processingState = "VALID" matters too. Builds whose binary processing hasn't finished on Apple's side are in PROCESSING or INVALID state. Trying to attach one of those to a version returns 409 . Filtering to VALID automatically excludes builds that are still "processing" right after upload.If you run fastlane deliver multiple times with sync screenshots: false , screenshots get appended every run. Even if the first run put in the correct 5 screenshots, after the second run there are 10, and after the third, 15. App Store validation rejects anything over "10 per size," so this becomes a quiet cause of submission failure. dedup screenshots solves it using the combination of sourceFileChecksum and fileName as the key. python def dedup screenshots app id, apply=False : ... for sh in shots.get "data", : key = sh "attributes" .get "sourceFileChecksum" , sh "attributes" .get "fileName" if key in seen: if apply: st, = call "DELETE", f"/v1/appScreenshots/{sh 'id' }" print f" {locale}/... DELETE {sh 'id' } - {st}" else: print f" {locale}/... dup {sh 'id' } dry-run " total += 1 else: seen.add key The important part is that apply=False makes dry-run the default . Just running asc.py dedup <app id only prints how many duplicates exist; actual deletion happens only when you pass --apply . When you're managing 12 apps, there's a real risk of "oops, I deleted every screenshot," so I made it a two-stage design.In actual operation I always slot in dedup --apply immediately before submit . It's just a sequential call inside a batch script, so a human never has to think about it. tools/setup signing.py is the script that "prepares the certificate / Bundle ID / provisioning profile trio without opening Xcode." Certificate matching is done by SHA1 fingerprint the part touched on earlier . The reason: a certificate on ASC carries no direct information about which keychain private key it corresponds to. Recording the SHA1 of the distribution certificate in the local keychain in advance, then pulling all certificates from the ASC API and matching by DER-decode + SHA1 computation, is the most reliable approach. Provisioning profile management follows a "delete the old one, then recreate" pattern. python def ensure profile cert id, bundle internal id : , d = asc.call "GET", "/v1/profiles?limit=200&filter profileType =IOS APP STORE" for p in d.get "data", : if p "attributes" .get "name" == PROFILE NAME: asc.call "DELETE", f"/v1/profiles/{p 'id' }" print "deleted stale profile", p "id" st, r = asc.call "POST", "/v1/profiles", {...} ... uuid = attrs "uuid" content = base64.b64decode attrs "profileContent" dest dir = os.path.expanduser "~/Library/MobileDevice/Provisioning Profiles" dest = os.path.join dest dir, f"{uuid}.mobileprovision" with open dest, "wb" as f: f.write content The reason for deleting the same-named profile first: when you renew a certificate, a leftover old profile creates the inconsistency "the profile exists, but the certificate is stale." Deleting and recreating every time makes it much easier to guarantee "idempotent, and always in the correct state." Writing directly into ~/Library/MobileDevice/Provisioning Profiles/ under the UUID filename is important too — that's what lets xcodebuild resolve PROVISIONING PROFILE SPECIFIER="Auraly AppStore" by name. No need to press Xcode's download button. Adding my own iCloud address to TestFlight as an internal tester is the first thing I do after submitting for review. That's also a single command: asc.py add-tester <app id . Near the end of the code there's a comment like this: python def add tester app id, email=DEFAULT TESTER EMAIL, first="Lily", last="Tester" : """... 注意: 外部グループや betaGroups/{id}/relationships/betaTesters 直リンクは 409 STATE ERROR Tester cannot be assigned になる。create-with-group が唯一通る。""" That comment is a record of failure more on that in the next section . The correct pattern is to create via POST /v1/betaTesters with relationships.betaGroups included in the body. st, r = call "POST", "/v1/betaTesters", {"data": {"type": "betaTesters", "attributes": {"email": email, "firstName": first, "lastName": last}, "relationships": {"betaGroups": {"data": {"type": "betaGroups", "id": gid} }}}} Doing "create the tester" and "assign group membership" in a single request keeps it from colliding with Apple's state management. Also, has tester runs an existence check first to prevent double registration. Without that idempotency check, running a batch across every app would try to register the same address 12 times and get 12 409s back. Building automation environments, I've repeatedly hit the pattern where "implementation finishes fairly quickly, and the time goes into killing mysterious 401s and mysterious 409s." Here are the failures I actually hit, in symptom → cause → fix order. The night I first implemented asc.py , I assembled the JWT, hit the API, and got 401 Unauthorized . Python's key.sign signing, ec.ECDSA hashes.SHA256 appears to work correctly. The Base64URL of the header and payload assembles fine. Eyeballing the JWT structure, nothing looks wrong. And yet every single call returns 401. Looking at the error response body, all you get is {"errors": {"status":"401","code":"NOT AUTHORIZED","title":"Authentication credentials are missing or invalid."} } — a zero-information message. It doesn't tell you "your signature is broken." After about two hours re-checking header formats, the aud value, and the exp calculation, I happened to look up RFC 7518 Section 3.4 and noticed it: an ES256 JWT signature must be "a fixed 64 bytes: r 32 bytes + s 32 bytes " . What key.sign returns is a variable-length DER byte string. It starts with an ASN.1 encoding like 30 xx 02 xx... , and the lengths of r and s vary. I was Base64URL-ing that directly. 書いていたコード（間違い） sig b64 = b64 der 正しいコード r, s = decode dss signature der sig b64 = b64 r.to bytes 32, "big" + s.to bytes 32, "big" Convert DER back to Python integers r, s with decode dss signature , turn each into 32 big-endian bytes, concatenate — that alone turned 401 into 200. An "authentication failed" error code hides an encoding-format problem in the signature algorithm. Knowing that up front would have bought me back two hours. A while after solving the DER problem, a new phenomenon appeared: "works in the morning, stops working in the early afternoon." Reproducibility was low, and trying again a few hours later it would be fine. If Apple's API servers and the local machine are off by a few to a dozen-odd seconds, iat issued at can get rejected as "a JWT from the future." A Mac's system clock is normally NTP-synced, but right after sleep or under heavy load, a few seconds of drift can occur. The fix is simple: set iat to 30 seconds before the current time. "iat": int time.time - 30, That declares "this JWT was issued 30 seconds ago," so from Apple's API server's perspective it's accepted as "a JWT issued sufficiently in the past." It only shaves 30 seconds off the 900-second lifetime, so there's no practical downside. For adding TestFlight testers, my first approach was "fetch the internal group first, then add the tester to that group." 失敗したパターン asc.call "POST", f"/v1/betaGroups/{gid}/relationships/betaTesters", {"data": {"type": "betaTesters", "id": tester id} } This returns 409 STATE ERROR: Tester cannot be assigned . Directly linking an external tester to an internal group is treated as a disallowed transition in Apple's state machine. The correct method is to specify the group at the moment you create the tester . Send relationships.betaGroups in the request body of POST /v1/betaTesters . That one shot atomically completes both "create the tester" and "assign group membership." From the outside, Apple's API looks like a "general-purpose REST API that can do anything," but in reality it's the review lifecycle's state machine exposed via API, so many operations error out unless you follow the correct transition order . Much of this isn't in the docs; you have to find it by trial and error. When uploading screenshots with fastlane deliver , running it multiple times with sync screenshots: false or the omitted default appends screenshots instead of replacing them . The first submission is fine. When you fix something after a rejection and try to resubmit, re-running deliver doubles the screenshots — 4 become 8 on the second deliver . Eight is just under the App Store limit 10 per size , so it's hard to notice, and when another re-run takes you to 12 you get back METADATA ERROR: Too many screenshots . From the symptom alone it reads as "the metadata is broken," and I wasted about an hour suspecting image size and format problems. The cause was simply "the same screenshot is in there multiple times." dedup screenshots is what I built in response. It deletes the second and subsequent entries where both sourceFileChecksum and fileName match. Using sourceFileChecksum alone leaves the rare case where different files share a checksum, so the filename is the second key. Making it verifiable in advance via dry-run without --apply also came from this failure — I learned that "if you wipe everything at once, you can't get it back." When attaching a build to a version in attach build , my first implementation only hit /v1/builds?filter app =xxx&limit=20&sort=-uploadedDate . The App Store Connect UI clearly showed a VALID build, yet the script said no VALID build for version 0.3.2 . The cause: the response doesn't include the marketing version 0.3.2 . The /v1/builds response returns only build objects; the marketing version corresponding to a build is tied to a separate resource, preReleaseVersion . It doesn't appear in the response unless you include it. 修正後：include=preReleaseVersion を追加 , b = call "GET", f"/v1/builds?filter app ={app id}&limit=20&sort=-uploadedDate" f"&include=preReleaseVersion" incl = {i "id" : i for i in b.get "included", if i "type" == "preReleaseVersions"} Adding include puts objects of type preReleaseVersions into the response's included array. Turn that into a dict keyed by ID and look it up via each build's relationships.preReleaseVersion.data.id , and you get the marketing version string. The App Store Connect API docs explain the include parameter, but there's no exhaustive table of "which endpoint can include which resource," so you don't know until you try. I tried preReleaseVersion because I'd seen builds and version strings displayed as associated in the ASC UI and guessed "that join has to exist somewhere." What these failures have in common is that the state of "it looks correct but doesn't work" lasts a long time . 401 and 409 look superficially similar, but each has its own distinct cause. There's no magic bullet — just dump the entire body of Apple's API responses with json.dumps r :800 and read them carefully. That's it. In the next post Part 2 , I'll explain wiring this asc.py into Claude Code's autonomous loop and the full pipeline design for managing 12 apps in parallel. I've covered most of the "why I wrote it that way" reasoning above. But once you start implementing, the real problem is "not recognizing that this symptom is that cause." Below is a comprehensive index in symptom → cause → countermeasure form, so you can look things up when the same symptom hits. ① A 401 comes back, but the error body says nothing about "signature" {"code":"NOT AUTHORIZED","title":"Authentication credentials are missing or invalid."} is also returned for a mis-encoded ES256 signature. The classic case is passing the DER returned by key.sign into b64 der . From Apple's side it only ever looks like "authentication failed." The correct approach is to convert it into Python integers r, s with decode dss signature der from cryptography.hazmat.primitives.asymmetric.utils , then pass the concatenation r.to bytes 32,"big" + s.to bytes 32,"big" to Base64URL. The import path itself is easy to get wrong, so watch out. ② Works in the morning, 401 in the early afternoon low reproducibility The cause is NTP drift on the Mac or delayed clock sync right after waking from sleep. If you leave iat as plain int time.time , a few seconds of divergence from Apple's server time gets it rejected as "not yet valid." asc.py subtracts 30 seconds with int time.time - 30 . Apple's tolerance margin measures out at roughly ±60 seconds, so this value leaves plenty of room. ③ 409 STATE ERROR: Tester cannot be assigned direct betaGroups link Passing an existing tester ID to POST /v1/betaGroups/{id}/relationships/betaTesters is rejected as a "disallowed transition" in Apple's state machine. The error message doesn't tell you the right way. As noted in the asc.py comment the 注意: block within its 272 lines , the only pattern that works is including relationships.betaGroups in the POST /v1/betaTesters body so tester creation and group membership complete in a single request. ④ METADATA ERROR: Too many screenshots after re-running fastlane deliver Running deliver multiple times with sync screenshots: false or the omitted default appends screenshots rather than deleting them. Exceed the App Store limit of 10 per size and review submission won't go through. Check duplicates with asc.py dedup <app id and delete with --apply . Using only sourceFileChecksum as the dedup key occasionally causes wrong deletions, so both checksum, fileName are used as the key see key = sh "attributes" .get "sourceFileChecksum" , sh "attributes" .get "fileName" in asc.py . ⑤ A VALID build is visible in the UI but you get no VALID build for version X.X.X The default /v1/builds response doesn't include the marketing version string 0.3.2 etc. . Without &include=preReleaseVersion , the included array comes back empty and you can't match on the version string. That's exactly why build for version in asc.py spells out that query parameter. The same symptom appears if you've uploaded so many builds in a short window that limit=20 isn't enough, so for apps with many builds, raise limit= or check the sort=-uploadedDate ordering. ⑥ version is WAITING FOR REVIEW locked error before submit In WAITING FOR REVIEW or IN REVIEW state you can neither edit the appStoreVersion nor add new reviewSubmissionItem s. asc.py allows writes only in the five states EDITABLE = {"PREPARE FOR SUBMISSION", "DEVELOPER REJECTED", "REJECTED", "METADATA REJECTED", "INVALID BINARY"} and returns a guard otherwise. To withdraw a review via Developer Reject and resubmit, use asc.py reject <app id UNRESOLVED ISSUES is also covered by that function . ⑦ I thought INVALID BINARY meant having to recreate the version INVALID BINARY is in EDITABLE . In other words, even in the "Apple rejected the binary during processing" state, you can swap the binary and resubmit under the same version. Just bump the build number, re-upload, overwrite with asc.py attach-build <app id <ver , then call submit . It saves the trouble of recreating the version. ⑧ setup signing.py exits with no ASC cert matches local SHA1 At the top of setup signing.py there's a constant LOCAL SHA1 = "EC06777A...".lower . That's the SHA1 fingerprint of the distribution certificate in your local keychain. Apple Distribution certificates expire after one year, and renewing produces a different SHA1. If you run setup signing.py after the annual renewal without updating this constant, find cert loops through every entry, finds no match, and hits sys.exit 1 . After renewing a certificate, always check the SHA1 in Keychain Access and rewrite the constant. ⑨ archive.sh fails to build because it can't resolve the provisioning profile archive.sh 's PROVISIONING PROFILE SPECIFIER="Auraly AppStore" resolves by exact string match against setup signing.py 's PROFILE NAME = "Auraly AppStore" . In an environment where setup signing.py hasn't been run — or hasn't been re-run after a certificate renewal — the stale profile sticks around and xcodebuild fails code signing with either "no matching profile found" or "certificate doesn't match." Keep the order setup signing.py → archive.sh at the head of the pipeline. Also, line 6 of archive.sh is xcodegen generate , and if you've changed project.yml , that step regenerates the .xcodeproj . Skipping it and building against a stale .xcodeproj can make the archive fail due to scheme configuration mismatches. ⑩ You called release but nothing was submitted asc.py release <app id <ver "<whatsnew " runs the three steps "prepare version → attach build → set What's New" together, but it does not submit . As the comment at the end of the code says, the intent is "確認後 submit する" "submit after verification" . The design is: prepare with release , confirm on the ASC screen that everything looks right, then call asc.py submit <app id separately. It's easy to call release at the end of an automation and mistakenly assume "submitted" — be careful. ⑪ Screenshots you deleted with dedup --apply reappear dedup screenshots scans every locale and every size of whatever version latest version currently returns. When that version is in a state outside EDITABLE e.g. WAITING FOR REVIEW , even apply=True returns early with just a message and deletes nothing the guard at line 186 of asc.py . Repeating --apply in that state changes nothing, so use reject to return it to an editable state first. Here are the rules that became standard from actually running 12 apps. 1. Isolate the .p8 with chmod 700 on the whole directory Just creating ~/.appstoreconnect/ and running chmod 700 ~/.appstoreconnect prevents other users on the same machine from reading it. Since keys.json holds only key id and issuer id , even if it leaks, the API can't be called without the private key itself. When putting this on CI, write it out from a secret store at runtime as ~/.appstoreconnect/AuthKey XXXXXXXXXX.p8 , and always verify that no .p8 is in the commit history. 2. Generate the JWT on every request don't cache it call invokes jwt on every call. Regenerating each time despite a 900-second lifetime looks inefficient, but it prevents the problem where the JWT expires mid-batch and only the later requests come back 401. ECDSA signing costs microseconds per request, and even across a 12-app batch there's no perceptible difference. Choosing "behaves the same no matter where it breaks" over "cache it and go slightly faster" is a founding principle of stable API client operation. 3. Always test the decode dss signature → to bytes 32, "big" concatenation Once you implement an ES256 JWT signature, decode the generated JWT string once and confirm the signature part is 64 bytes after Base64URL decoding . DER would be variable-length typically 70–72 bytes . If len base64.urlsafe b64decode jwt.split "." 2 + "==" returns 64, your r‖s encoding is correct. Leave it untested on "it seems to work" and the signature breaks the moment r or s happens to be small and the zero padding is missing. 4. Always subtract 30 seconds from iat Even when a production machine is NTP-synced, a few seconds of drift can occur right after waking from sleep or under heavy load. Apple's tolerance margin is presumed to be around ±60 seconds, but 30 seconds of headroom is a safety margin you get for free. The 900-second lifetime just becomes 870 seconds — no practical downside. 5. Every write operation should GET the current state before POST/PATCH submit first checks for an existing submission with GET /v1/reviewSubmissions?filter state =READY FOR REVIEW and reuses it if present. add tester first runs an existence check via has tester . Applying this "check → act" pattern rigorously to every write command means no double submissions or duplicate errors, whether Claude Code retries or you run it twice by hand. Idempotency is the single most important design principle for an API client. 6. Memorize the five EDITABLE states Only in the five states PREPARE FOR SUBMISSION , DEVELOPER REJECTED , REJECTED , METADATA REJECTED , and INVALID BINARY can you change version attributes, swap builds, or delete screenshots. Attempting those in any other state returns 409 or 422 . When the review flow gets stuck, first check the current appStoreState with asc.py status <app id ; if it isn't in EDITABLE, you can decide either to reject first, or — where reject isn't needed — to wait for review to complete. 7. Slot dedup --apply in right before every submit Regardless of how many times you've run fastlane deliver , get in the habit of running asc.py dedup <app id --apply immediately before submit . Even when the dry-run shows zero, the execution cost is low, and it preempts METADATA ERROR from duplicated screenshots. In a batch script you can guarantee it with a single serial line: for app id in ...; do asc.py dedup "$app id" --apply && asc.py submit "$app id"; done . 8. Manage provisioning profiles on a delete-then-recreate cycle ensure profile in setup signing.py deletes all same-named profiles first, then creates a new one. It's "recreate," not "update." When you renew a certificate, a leftover profile bound to the old certificate ID creates the inconsistency "the profile exists but the certificate doesn't match." With a recreate cycle, exactly one profile with the correct certificate ID always exists, and xcodebuild resolves it correctly. 9. Stabilize headless builds with CODE SIGN STYLE=Manual archive.sh specifies CODE SIGN STYLE=Manual because with Automatic Signing, Xcode tries to manage provisioning profiles itself — which can surface a Keychain Access authentication dialog during headless runs or attempt to reach the Apple Developer API. Setting Manual and pinning the Profile Specifier by name reduces it to xcodebuild resolving, by name, the profile that setup signing.py wrote into ~/Library/MobileDevice/Provisioning Profiles/ — no GUI operation whatsoever. 10. Keep external libraries down to just cryptography asc.py uses urllib.request for HTTP and doesn't take requests as a dependency. Setting up a new Mac, running for the first time in a CI environment — removing one pip install requests step changes the real friction substantially. cryptography alone can't be replaced by the standard library, so it's tolerated as the minimal dependency. Never getting stuck on pip install -r requirements.txt each time you carry the script into another project is a direct benefit of this design decision. 11. Print the whole response body for API errors with json.dumps r :800 Every function in asc.py uses the uniform pattern if st = 400: print json.dumps r :800 ; return . Apple's error responses have a detail field inside the errors array, and that's where the hint about the cause lives. If you print only status without showing detail , 409, 401, and 422 all look like the same "error." The habit of dumping the entire body cuts your root-cause time by more than half. 12. Always call release and submit as separate steps release <app id <ver "<whatsnew " bundles version preparation, build attachment, and What's New setup, but deliberately does not submit. Calling asc.py status <app id after release to confirm the metadata is set correctly, and only then calling submit , prevents the wasteful cycle of "submit, notice the mistake, then Developer Reject." Even when building this into an automated pipeline, I design it so the release output is left in the log in a form Claude Code can read, and it proceeds to submit only if there's no problem. 13. Always rewrite the SHA1 fingerprint when the certificate is renewed LOCAL SHA1 in setup signing.py is the SHA1 of the distribution certificate, and Apple Distribution certificates expire after one year. After renewal, select the new distribution certificate in Keychain Access, check the value under "Get Info" → "SHA-1 fingerprint," and rewrite the constant. Forget to rewrite it and find cert scans all 200 certificates, finds no match, and terminates with sys.exit 1 . The stable practice is to put certificate renewal in your calendar and, on the day you renew, complete the setup signing.py rewrite and a verification run as a set. "With an API key, you just generate a JWT and call the API" is correct — but that JWT has to be ES256 raw r‖s encoding, iat needs a 30-second clock-skew cushion, forget include=preReleaseVersion and builds are invisible, and tester addition returns 409 unless you use create-with-group. You don't reach the state of "hitting the API without 2FA" until you've stepped on every one of these yourself. The asc.py introduced here is 272 lines, and the three commands apps / status / submit are its core — but behind them sit every stumbling point listed above. Implement it after reading what's here and you can clear the DER problem that cost me two hours, and the clock-skew problem that ate tens of minutes, on the first pass. Finally, a look back at the structure. Layer 1 produces the binary archive.sh with Manual Signing , Layer 2 transfers it eas submit , and Layer 3 submits for review through the ASC API asc.py submit . Only with all three layers in place do you get an environment where "review submissions for 12 apps run to completion while I'm asleep." The code is right there. All that's left is to run it. In the next post Part 2 , I'll explain wiring this asc.py into Claude Code's autonomous loop, the breakthrough procedure for INVALID BINARY resubmissions, and the pipeline design for managing 12 apps in parallel. I've written up the full picture of the system, the breakdown of the ¥1.2M/month, and the 30-day procedure in a paid note. 📕 Claude Code自律環境で、実際どう稼ぐか ― 仕組み・実例・始め方・サポート https://note.com/bokuwalily/n/n849b3a07784a Written by Lily — I ship iOS apps and automate my content stack with Claude Code. Follow along: Portfolio https://bokuwalily.com · X https://x.com/bokuwalily · GitHub https://github.com/bokuwalily