Shipping 12 iOS Apps to the App Store Unattended, Part 2 — Every Review Trap (Beta Builds Rejected, Pricing, Name Collisions)

An indie developer who was laid off with no savings rebuilt their income around an autonomous App Store submission pipeline powered by Claude Code, now clearing ¥1.2M a month. The pipeline uses the App Store Connect API with JWT authentication to submit 12 iOS apps unattended, and the developer details three review rejection traps encountered in production, including the true cause of ITMS-90111 and how to handle pricing and name collisions.

I got laid off with ¥0 in the bank. Six months later, rebuilt around Claude Code running as an autonomous environment, I'm clearing ¥1.2M a month — and one of the load-bearing pieces is a pipeline that submits apps to the App Store without me touching it. Part 1 covered how to wire up JWT authentication and the skeleton of asc.py . This time I'm collecting the three "review rejection traps" that only showed up once the thing went into real production use: how the true cause of ITMS-90111 turned out to be BuildMachineOSBuild , the correct request shape for appPriceSchedules , and how to dodge the en-US locale name collision. Each one, in order, with the actual code. Don't automate the work — build an environment where the work never happens in the first place. That's the core idea behind this pipeline. Run 12 iOS apps in parallel and store submission alone generates an absurd amount of busywork. Submitting a single app by hand means: archive in Xcode → upload from Organizer → enter version info in App Store Connect → swap out the screenshots → hit the submit-for-review button. Even once you're used to it, that's 20–30 minutes per app. Twelve apps eats an entire day. Repeat that a few times a month and an indie developer's resources are gone. But the App Store Connect API ASC API from here on is designed so that a JWT plus a .p8 private key is all you need — no 2FA. That changes everything. Because it doesn't require a human login session, Claude Code can run it autonomously at 3 a.m. with exactly the same permissions. Here's the JWT generation part of ~/.appstoreconnect/asc.py . python 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 aud:"appstoreconnect-v1" and an exp of 900 seconds 15 minutes are the format Apple demands. I hand-rolled this instead of using the standard PyJWT library to keep dependencies minimal so it runs anywhere. The cryptography package alone is enough to do ES256 signing end to end. Credentials are consolidated in one place, ~/.appstoreconnect/keys.json , so the same script can be reused against any app. CFG = json.load open os.path.expanduser "~/.appstoreconnect/keys.json" finishes key loading, and after that you just pass the app ID as an argument.The other important piece is state management . The ASC API strictly tracks whether a version is in an editable state or not. The EDITABLE constant in asc.py is the criterion. EDITABLE = {"PREPARE FOR SUBMISSION", "DEVELOPER REJECTED", "REJECTED", "METADATA REJECTED", "INVALID BINARY"} Only in these five states are versionString changes and build swaps permitted. Throw a PATCH while the app is IN REVIEW or WAITING FOR REVIEW and all you get is an error. Having the script check this up front and branch accordingly eliminates wasted API calls. There's one more mechanism for "not doing work": idempotency . For example, add tester checks has tester before adding a tester and skips the operation if they're already registered. submit likewise reuses an existing READY FOR REVIEW reviewSubmission instead of creating a new one. With that in place, Claude Code running the same command twice produces no side effects. The reality behind ¥1.2M a month isn't "piled-on workload." It's the same machinery running in parallel . As apps get added, the only thing that grows is the list of app IDs handed to the script — the structure doesn't change. Zoom out and the pipeline splits into four layers. ┌─────────────────────────────────────────────────────────┐ │ 1. 署名準備 │ │ setup signing.py │ │ ・SHA1 で Distribution 証明書を特定 │ │ ・App ID（bundleId）を作成または確認 │ │ ・.mobileprovision を生成して Keychain に配置 │ └────────────────────┬────────────────────────────────────┘ │ ┌────────────────────▼────────────────────────────────────┐ │ 2. ビルド＆アーカイブ │ │ tools/archive.sh │ │ ・xcodegen generate でプロジェクト再生成 │ │ ・xcodebuild archive（Manual Signing） │ │ ・xcodebuild -exportArchive → .ipa 生成 │ └────────────────────┬────────────────────────────────────┘ │ ┌────────────────────▼────────────────────────────────────┐ │ 3. バイナリ投入 │ │ eas submit / altool │ │ ・.ipa を App Store Connect へアップロード │ │ ・処理完了まで待機（processingState: VALID） │ └────────────────────┬────────────────────────────────────┘ │ ┌────────────────────▼────────────────────────────────────┐ │ 4. メタデータ＆審査提出 │ │ asc.py release → dedup → submit │ │ ・make version: 編集可能バージョンを確保 │ │ ・attach build: VALID ビルドを紐づけ │ │ ・set whatsnew: 全ロケールの更新情報を設定 │ │ ・dedup: スクショ重複を除去 │ │ ・submit: reviewSubmission 作成→item追加→提出 │ └─────────────────────────────────────────────────────────┘ The signing automation handled by ~/dev/auraly-ios/tools/setup signing.py starts with matching the certificate. python LOCAL SHA1 = "EC06777A693874E920CECFE390D467670552CCCE".lower def find cert : , d = asc.call "GET", "/v1/certificates?limit=200" for c in d.get "data", : content = c "attributes" .get "certificateContent" if not content: continue der = base64.b64decode content sha1 = hashlib.sha1 der .hexdigest if sha1 == LOCAL SHA1: return c "id" The certificateContent returned by /v1/certificates is Base64-encoded DER. We fingerprint it with SHA1 and match it against the Distribution certificate in the local Keychain. I match on fingerprint rather than searching by name specifically to avoid cases where names collide, like having multiple "Apple Distribution: ..." entries. Once a matching certificate is found, the script verifies or creates the App ID bundleId and generates an AppStore-type provisioning profile. The generated profile is written to ~/Library/MobileDevice/Provisioning Profiles/{uuid}.mobileprovision , where xcodebuild can pick it up directly. By design, any existing profile with the same name is DELETEd first and then recreated, which prevents the failure mode where a stale profile lingers after a certificate rotation and breaks the build. The core of ~/dev/auraly-ios/tools/archive.sh is 17 lines. 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 combination of CODE SIGN STYLE=Manual and PROVISIONING PROFILE SPECIFIER="Auraly AppStore" fully disables Xcode's automatic signing and pins the profile generated in the previous layer by name. I've left -allowProvisioningUpdates in, but since the profile is already sitting on disk locally, no query to Apple's servers actually happens. Running xcodegen generate at the top every time is deliberate. It makes project.yml the single source of truth and keeps hand-edited .xcodeproj diffs from sneaking into the build.Delivering the generated .ipa to App Store Connect is handled by either eas submit or altool . This layer is outside the script's control; we wait asynchronously until processing completes processingState: VALID . asc.py 's build for version is what polls for whether a VALID build exists for the specified version. 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 Builds whose processingState is anything other than VALID PROCESSING , FAILED are skipped as ineligible for attachment. include=preReleaseVersion fetches the marketing version in a single call, and filtering by version string lets you grab exactly the intended version even when multiple builds exist. asc.py submit walks through three steps. python def submit app id, platform="IOS" : 1 reviewSubmission を作成（既存 in-progress があれば再利用） , 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", {"data": {"type": "reviewSubmissions", "attributes": {"platform": platform}, "relationships": {"app": {"data": {"type": "apps", "id": app id}}}}} sub = r "data" sid = sub "id" 2 バージョンを item として追加 ver = latest version app id ; vid = ver "id" st, r = call "POST", "/v1/reviewSubmissionItems", {"data": {"type": "reviewSubmissionItems", "relationships": { "reviewSubmission": {"data": {"type": "reviewSubmissions", "id": sid}}, "appStoreVersion": {"data": {"type": "appStoreVersions", "id": vid}}}}} 3 submitted=true で提出 st, r = call "PATCH", f"/v1/reviewSubmissions/{sid}", {"data": {"type": "reviewSubmissions", "id": sid, "attributes": {"submitted": True}}} Rather than the legacy /v1/apps/{id}/appStoreVersions/{vid}/... family of endpoints, this uses the newer reviewSubmissions / reviewSubmissionItems endpoints . Apple recommends these in the docs, and the old ones are on a path to being phased out. Skipping the first of the three steps — the existing-submission check — causes errors from double-submitting the same app, so the key is to GET and check state before you POST. Screenshot dedup always runs immediately before submit . Re-syncing screenshots with deliver or fastlane can leave you with the previous batch and the current batch both added as identical files. dedup screenshots keys on the combination of sourceFileChecksum and fileName and DELETEs everything after the first copy. It's a dry run with apply=False and only deletes for real with the --apply flag, so the risk of accidental deletion is eliminated by checking first. That's the full picture of "a pipeline that works." From the next chapter on, I'll go through the rejection reasons I actually hit when putting this pipeline into production across 12 apps, with the error codes and the fixing code. Running 12 apps in parallel guarantees you'll hit the situation where you spot a minor bug while an app is in review and want to fix it right now . Throw make version or attach build at an app in WAITING FOR REVIEW or IN REVIEW and the ASC API just silently returns 422. What you need to get back into an editable state is reject . python def reject app id : , rs = call "GET", f"/v1/reviewSubmissions?filter app ={app id}&limit=10" done = False for x in rs.get "data", : state = x "attributes" .get "state" if state in "WAITING FOR REVIEW", "IN REVIEW", "UNRESOLVED ISSUES" : st, r = call "PATCH", f"/v1/reviewSubmissions/{x 'id' }", {"data": {"type": "reviewSubmissions", "id": x "id" , "attributes": {"canceled": True}}} print " reject", x "id" , state, "- ", st if st < 400 else json.dumps r :400 done = True if not done: print " 審査中の submission 無し" Just PATCHing canceled: True withdraws the review and transitions the version to DEVELOPER REJECTED . Since that state is in EDITABLE , you can go straight back into the make version → attach build → submit flow. UNRESOLVED ISSUES is included in the target states so that the same command can also withdraw a submission when App Review has come back with follow-up questions. Developer Rejection carries no penalty. It gets recorded in the review history, but it doesn't count against your review count. If anything, trying to push a flawed binary through and eating a REJECTED costs you more waiting time before the next cycle. "The moment you want to fix something, reject → fix → re-submit" is the correct way to minimize cycle cost. python def release app id, version, whatsnew, platform="IOS" : print "release", app id, version vid = make version app id, version, platform if not vid: return attach build app id, vid, version set whatsnew app id, whatsnew, vid print " done. 確認後に submit を実行。" release is a thin orchestrator that chains make version → attach build → set whatsnew in sequence. submit is deliberately excluded. The design stops once the build is attached and the metadata is in place, so you can check with the status command before firing submit . Fully automating it would flush things into review before you had a chance to catch a mistake, so the last single command is intentionally separated out. From Claude Code, it's these three lines: python3 ~/.appstoreconnect/asc.py release 6782624281 1.4.0 "バグ修正と安定性の向上" python3 ~/.appstoreconnect/asc.py dedup 6782624281 --apply python3 ~/.appstoreconnect/asc.py submit 6782624281 "Prepare version → dedupe screenshots → submit for review" in three lines. Even running this in parallel across 12 apps, it finishes before you get anywhere near the ASC API rate limit roughly 1,000 requests per minute as a rule of thumb . python def add tester app id, email=DEFAULT TESTER EMAIL, first="Lily", last="Tester" : if has tester app id, email : print f" {email} は既にテスター skip " ; return , g = call "GET", f"/v1/apps/{app id}/betaGroups?limit=50" internal = next x for x in g.get "data", if x "attributes" .get "isInternalGroup" , None if not internal: st, r = call "POST", "/v1/betaGroups", {"data": {"type": "betaGroups", "attributes": {"name": "Internal", "isInternalGroup": True}, "relationships": {"app": {"data": {"type": "apps", "id": app id}}}}} if st = 400: print " create internal group failed", st, json.dumps r :600 ; return internal = r "data" ; print " created internal group", internal "id" gid = internal "id" st, r = call "POST", "/v1/betaTesters", {"data": {"type": "betaTesters", "attributes": {"email": email, "firstName": first, "lastName": last}, "relationships": {"betaGroups": {"data": {"type": "betaGroups", "id": gid} }}}} if st = 400 and not has tester app id, email : print " add tester failed", st, json.dumps r :600 ; return print f" テスター {email} を内部グループ {gid} に追加" As the comment says, POSTing directly to betaGroups/{id}/relationships/betaTesters gets rejected with a 409 STATE ERROR "Tester cannot be assigned" . When adding a tester, the only correct answer is a single operation that creates the tester and links them to the group at the same time — a POST to /v1/betaTesters that includes the betaGroups relationship. Follow the intuitive procedure of "create the group, then add the tester" and all you'll get is an endless stream of 409s. Internal testers can install without Beta App Review, so you can verify the install on your own iCloud account right after submitting for review. Calling add tester after submission has become a standard routine in the pipeline. On the way to putting 12 apps into production, three kinds of rejection stopped the pipeline. Here they are in order: symptom → cause → fix. Symptom. I ran archive.sh , uploaded the .ipa to App Store Connect, and the post-processing email carried ITMS-90111 . ERROR ITMS-90111: "Invalid Binary. The value for key BuildMachineOSBuild in the Info.plist file at Payload/Auraly.app/Info.plist is not valid." The App Store Connect web UI showed the binary as "invalid," and build for version would never return a build with processingState == "VALID" . Re-uploading gave the same result. Checking the build column with asc.py status just showed FAILED . Cause. When archiving, xcodebuild automatically writes the macOS version the build ran on into Info.plist under the BuildMachineOSBuild key. There is nothing wrong with the archive.sh command itself. 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 The problem was that the macOS running this command was a beta . I was on a beta build numbers in the 25A5xxx range before the GA release of macOS 15 Sequoia, so a string indicating beta got embedded in BuildMachineOSBuild and Apple's validator rejected it. There is no xcodebuild option to override BuildMachineOSBuild ; your only option is to put the build machine's OS itself back on a GA release. Fix. I downgraded macOS from beta to the official release and re-archived. In environments where downgrading is hard, archiving on GitHub Actions' macos-latest runner always GA is the practical route. From then on I switched to a rule of "development can be on beta, archiving only on a GA-only machine." So I don't forget the rule and step on it again, I added a line to the top of archive.sh that prints the output of sw vers -buildVersion . Symptom. I POSTed to the pricing endpoint to register a new app as Free, and it kept returning 422. 422 {"errors": {"status":"422","code":"INVALID ENTITY", "detail":"The provided entity includes invalid relationship data."} } The error message is too generic to tell you what's wrong. Apple's docs only say "pass manualPrices in relationships," with few concrete body-structure examples. This is the shape I tried first. { "data": { "type": "appPriceSchedules", "attributes": {}, "relationships": { "app": {"data": {"type": "apps", "id": "<app id "}}, "manualPrices": {"data": {"type": "appPrices", "id": "p1"} } } } } Cause. manualPrices uses the inline-resource included format . Even though it's referenced by id: "p1" , the actual p1 object isn't in the included array, so you get a 422 for "the referenced data doesn't exist." And there's one more gotcha: the startDate that means "effective immediately" must be JSON null , not an empty string "" . Putting "" in returns a different 422. Fix. Explicitly include the appPrices object in included , and make startDate null . { "data": { "type": "appPriceSchedules", "attributes": {}, "relationships": { "app": {"data": {"type": "apps", "id": "<app id "}}, "manualPrices": {"data": {"type": "appPrices", "id": "p1"} } } }, "included": { "type": "appPrices", "id": "p1", "attributes": { "startDate": null, "customerPrice": "0" }, "relationships": { "territory": {"data": {"type": "territories", "id": "JPN"}} } } } That said, enumerating included entries for all 175 countries isn't practical. In the end I dropped the idea of building a pricing function into asc.py and settled on a design where pricing is set up front in the App Store Connect web UI, and the API sticks to metadata and binary operations. This division of labor also makes sense because it eliminates the risk of pricing being overwritten on every resubmission. Symptom. Running set whatsnew , one specific app started returning 409 and the update stopped. php whatsNew en-US - 409 {"errors": {"status":"409","code":"STATE ERROR",...} } Other locales before and after it, like ja and zh-Hans , updated fine, so the script itself isn't broken. Only en-US fails, every time. Cause. set whatsnew PATCHes every entry in the localization list returned by the ASC API. , loc = call "GET", f"/v1/appStoreVersions/{vid}/appStoreVersionLocalizations" for x in loc.get "data", : lid = x "id" ; locale = x "attributes" .get "locale" st, r = call "PATCH", f"/v1/appStoreVersionLocalizations/{lid}", {"data": {"type": "appStoreVersionLocalizations", "id": lid, "attributes": {"whatsNew": text}}} print " whatsNew", locale, "- ", st if st < 400 else json.dumps r :300 The problem was that this app's version had both en-US and en . If you create the English name as en in the App Store Connect web UI and then add en-US metadata via deliver or Fastlane, you end up double-registered. The App Store manages en and en-US as separate entities, so the duplicate state is tolerated — but when one of them is set as the "primary locale," a PATCH to the other returns 409. Fix. As a stopgap, I added a filter that looks at the locale's language code everything before the - and skips it if the same base language has already been processed. processed base = set for x in loc.get "data", : locale = x "attributes" .get "locale", "" base = locale.split "-" 0 "en-US" → "en" if base in processed base: print f" skip {locale} already processed base {base} " continue processed base.add base lid = x "id" st, r = call "PATCH", f"/v1/appStoreVersionLocalizations/{lid}", {"data": {"type": "appStoreVersionLocalizations", "id": lid, "attributes": {"whatsNew": text}}} print " whatsNew", locale, "- ", st if st < 400 else json.dumps r :300 The real fix is to delete the duplicate locale in the App Store Connect web UI and consolidate on en-US . The skip on the script side is strictly a stopgap, and if you have a mix of apps whose primary is en and apps whose primary is en-US , the skip logic can backfire. I prevent recurrence by adding a routine that fetches the app list with asc.py apps and periodically checks each app's locale state. In the next section I'll cover rate-limit handling when spinning 12 apps at once, and the design of the agent loop where Claude Code autonomously decides "rejection → bug fix → resubmit." Setting aside the three big rejections from the previous chapter ITMS-90111 / appPriceSchedules / en-US collision , here's a rapid-fire list of the smaller traps I hit in implementation and operation. Rate-limit handling is covered here too. 1. Don't strip the meaning of the JWT's iat at −30 seconds jwt in ~/.appstoreconnect/asc.py is written like this: p = b64 json.dumps {"iss":ISSUER,"iat":int time.time -30,"exp":int time.time +900, "aud":"appstoreconnect-v1"},separators= ",",":" .encode The -30 on iat is clock-drift protection against Apple's servers. If you issue a JWT while your Mac's clock is slightly off from NTP, Apple decides "this issue time is in the future" and returns 401. The frequency goes up the more you run it automatically on a build server, so this -30 must never be removed. The 900 seconds 15 minutes on exp is also the maximum Apple demands. Put in a value over 900 and you get an immediate 401. 2. Pagination for /v1/certificates?limit=200 isn't implemented find cert in ~/dev/auraly-ios/tools/setup signing.py is written like this: python LOCAL SHA1 = "EC06777A693874E920CECFE390D467670552CCCE".lower def find cert : , d = asc.call "GET", "/v1/certificates?limit=200" for c in d.get "data", : content = c "attributes" .get "certificateContent" if not content: continue der = base64.b64decode content sha1 = hashlib.sha1 der .hexdigest if sha1 == LOCAL SHA1: return c "id" print "ERROR: no ASC cert matches local SHA1", LOCAL SHA1 sys.exit 1 I haven't implemented ASC API pagination the cursor parameter . If you have 201 or more certificates in total, the moment the target certificate falls to position 201 or beyond, this halts with sys.exit 1 . With about 12 apps on a personal account it realistically won't happen, but on a team account or a long-lived account it's worth watching. You can prevent it by periodically deleting revoked certificates, or by adding a cursor -based full sweep. 3. ensure profile deletes every profile with the same name 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" It DELETEs every profile that exactly matches PROFILE NAME = "Auraly AppStore" and then creates a new one. If you reuse the same profile name across multiple apps, the other apps' profiles get wiped out together and their next build won't pass. You can prevent this by strictly using a unique per-app name like "{app name} AppStore" . 4. latest version blindly returns the single newest entry python def latest version app id : , v = call "GET", f"/v1/apps/{app id}/appStoreVersions?limit=1" return v "data" 0 if v.get "data" else None Since no sort condition is specified, you get the first entry under the API's default descending creation date . When "1.3.0 in review " and "1.4.0 editing " exist at the same time, submit grabs 1.4.0's ID and tries to submit it. Running 12 apps in parallel, this dual-version state lingers surprisingly long. You need the habit of running asc.py status <app id to check state before operating. 5. The script silently ignores builds with processingState: FAILED for x in b.get "data", : if x "attributes" .get "processingState" = "VALID": continue It just skips anything that isn't VALID ; there's no logic to detect and report FAILED . If Apple received the binary but failed to process it, build for version behaves as though nothing were there. Tell Claude Code to "wait until it becomes VALID" and it will poll forever against a FAILED build. You need a mechanism that sets a timeout around 30 minutes and notifies and halts when it's exceeded. 6. dedup's duplicate check keys on sourceFileChecksum + fileName key = sh "attributes" .get "sourceFileChecksum" , sh "attributes" .get "fileName" if key in seen: The same image under a different file name counts as a different key. If you rename files in a Fastlane metadata folder — screen 01.png → screen 1.png — identical images won't be detected as duplicates. Before running --apply , check the duplicate count with no arguments dry run , and if the count is unexpected, cross-check by hand. 7. set whatsnew pushes the same text to every locale for x in loc.get "data", : lid = x "id" ; locale = x "attributes" .get "locale" st, r = call "PATCH", f"/v1/appStoreVersionLocalizations/{lid}", {"data": {"type": "appStoreVersionLocalizations", "id": lid, "attributes": {"whatsNew": text}}} It PATCHes the text you passed into every entry regardless of locale. Japanese release notes go straight into the English, Chinese, and Korean locales. You need to deal with this before an English-speaking user writes a review saying "I can't read the release notes." The practical designs are either extending set whatsnew to accept {"ja": "...", "en-US": "..."} , or having Claude Code generate per-language translations and passing in that dictionary. 8. The whatsNew field caps at 4,000 characters That's the App Store Connect API spec limit. Exceed it and you get a 422. Tell Claude Code to "auto-generate release notes and run it all the way through submit" and you easily end up with a long text passed through verbatim. You can prevent it by clipping on the caller side with whatsnew = whatsnew :4000 , or by writing "keep it under 4,000 characters" explicitly in the prompt. 9. Every PATCH returns 422 while in IN REVIEW EDITABLE in asc.py contains only these five states: EDITABLE = {"PREPARE FOR SUBMISSION", "DEVELOPER REJECTED", "REJECTED", "METADATA REJECTED", "INVALID BINARY"} WAITING FOR REVIEW and IN REVIEW are outside the set. Try to change metadata during review and the API just silently returns 422. You have to withdraw with reject first, then edit. Running 12 apps at once means one of them is always in review, which makes it easy to get confused about "why can't I update just this app?" 10. Submitting 12 apps at once hits the rate limit 429 The call function has no retry / backoff. 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"{}" Build a loop that runs dedup → submit across all 12 at once and within a few minutes you approach the limit roughly 1,000 requests/minute . Since a 429 is just returned upward as an error with no retry, the apps later in the loop fail silently. You can stabilize it with the bare-minimum measure of a time.sleep 0.1 after each call , or by adding a wrapper that detects 429 and retries with exponential backoff. 11. Completion of eas submit / altool is outside asc.py Binary upload is handled by eas submit or altool , and asc.py has no way to sense its completion. It takes 3–10 minutes from upload until Apple's servers mark it VALID. Run release → submit back to back without accounting for that wait and you whiff with "no VALID build found." Either check the build column with asc.py status before calling release , or wrap it with polling based on build for version . 12. set -euo pipefail in archive.sh is intentional but easy to overlook set -euo pipefail cd "$ dirname "$0" /.." A failure in xcodegen generate or in xcodebuild archive immediately halts the entire script. When Claude Code runs archive.sh, missing the exit-code-1 log means it may not notice the failure. Adding echo "ARCHIVE SUCCESS: $ROOT/build/export/Auraly.ipa" at the end of archive.sh as a confirmation marker, and stating explicitly in the instructions to Claude Code that "if this message doesn't appear, report it as a failure," prevents the misread. Twelve principles distilled from going back and forth between implementation and failure. 1. Archive on a GA-macOS-only machine Build on beta macOS and a beta string gets embedded in BuildMachineOSBuild , and ITMS-90111 rejects you. Even if you develop on a beta environment, restrict the machine that runs archive.sh to official-release macOS only. GitHub Actions' macos-latest runner always uses a GA release, so archiving in CI is the safest design. 2. Print the OS build number at the top of archive.sh echo "macOS build: $ sw vers -buildVersion " The build number stays in the CI log, so if ITMS-90111 recurs you can immediately pin it on "this was built on beta." Just memorizing the pattern — 24G85 is GA, the 25A5xxx range is beta — speeds up diagnosis. 3. Set pricing once in the Web UI and don't hand it to the API Manipulating appPriceSchedules via the API requires included entries for all 175 countries, which isn't practical. The right design is to set "Free" or whatever tier once in the Web UI and never touch it in subsequent submissions. It also drops the risk of pricing being overwritten on every resubmission to zero. 4. Always run dedup immediately before submit python3 ~/.appstoreconnect/asc.py dedup <app id --apply python3 ~/.appstoreconnect/asc.py submit <app id Bake "don't break this order" into your instruction template for Claude Code. Reverse the order and duplicate screenshots go straight into review. 5. Consolidate locales on en-US and don't leave en behind Delete the existing en locale from the Web UI and keep only en-US . The script-side "skip duplicate base languages" is a stopgap; the root fix is consolidating locales. If you have a mix of apps whose primary locale is en and apps whose primary is en-US , there are cases where the skip logic backfires. 6. Check status at two points: before submission and 24 hours after Before submission: verify version state and whether a VALID build exists. 24 hours after submission: verify whether reviewSubmission.state has changed to COMPLETE . Build this check into Claude Code as a routine and you automate detection of both approvals and rejections. 7. Developer Rejection has no penalty — reject the moment you notice If you find a defect during review, immediately run reject → fix → submit . The "let's see if it passes review" posture loses you more in rejection wait time. Developer Rejection doesn't affect the review count. 8. Check EDITABLE state before operating Use the status command to confirm appStoreState is one of the five EDITABLE states before running release . Operating during IN REVIEW only returns 422 with no side effects, but it wastes time and API calls. 9. Make profile names app-specific Name them in the "{app name} AppStore" format so multiple apps never share a name. ensure profile deletes every same-named profile, so a naming collision wipes out another app's profile and breaks its next build. 10. Add 429-aware exponential backoff to call python def call with retry method, path, body=None, max retry=3 : for attempt in range max retry : st, data = call method, path, body if st == 429: time.sleep 2 attempt continue return st, data return st, data This stabilizes the 12-app simultaneous submission loop. You can leave the current call as is and swap over gradually by routing only the rate-limit-sensitive operations through the wrapper. 11. Put a timeout on waiting for VALID When you tell Claude Code to "wait until processingState: VALID ," always attach the condition "if it isn't VALID after 30 minutes, treat it as FAILED, notify, and halt." Polling without a timeout is exactly how an overnight autonomous run gets stuck without anyone noticing. 12. Clip whatsNew to 4,000 characters before calling whatsnew = generated text :4000 Pass Claude Code's generated release notes through unchecked and you get a 422 for exceeding the limit. Making the clip the caller's responsibility keeps set whatsnew itself clean. Across Part 1 and Part 2, I've shown that three scripts — ~/.appstoreconnect/asc.py 272 lines , archive.sh 24 lines , and setup signing.py 72 lines — are enough to fully automate review submission for 12 iOS apps with no human in the loop. The traps that stopped review were a combination of non-obvious Apple-server-specific behavior the true cause of ITMS-90111, the included format for appPriceSchedules, the en / en-US double registration and small assumptions in the implementation pagination, naming collisions, locale consolidation, timeouts, rate limits . Every one of them I stepped on while actually running 12 apps in parallel. Reading the docs won't prevent them. The reality behind ¥1.2M a month isn't "I increased my workload" — it's just "the same three scripts running in parallel across 12 apps." If the pipeline is built correctly, it scales by adding one line with an app ID. The three scripts described here are the foundation for that. Next time I'll cover the design of the agent loop where Claude Code autonomously decides "detect rejection → fix bug → resubmit." 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