If you stop reading there, the takeaway is "AI agents can ship iOS apps now." That takeaway is wrong in an important way, and the wrongness is the useful part.

Here's the claim I actually believe, and the evidence for it: the agent executed, in one night, a recipe that my failures had spent months writing. Nothing about that night was improvised. Every step the agent took either followed a runbook that a previous failure had paid for, or hit a brand-new failure — and the new ones are now in the runbook too.

What the agent actually did that night

The condensed flow, for people who came for the recipe (all raw App Store Connect API — fastlane turned out to be a dead end on my machine, more on that below):

1. Build & upload: bump CURRENT_PROJECT_VERSION, xcodebuild archive → -exportArchive with an export-only options plist (method=app-store-connect, no destination) → upload the IPA with xcrun altool --upload-app using an ASC API key. 163 MB, 12-second transfer.
2. Wait properly: poll GET /v1/builds?filter[app]=…&sort=-uploadedDate until processingState=VALID. Not "wait a bit and hope" — poll for the actual state.
3. Screenshots via API: for each image — delete the stale appScreenshots in the display set, POST /v1/appScreenshots to reserve upload operations, PUT the bytes, PATCH uploaded=true with an md5 sourceFileChecksum, then poll assetDeliveryState until COMPLETE.
4. Attach the build to the version record, patch reviewer notes, keep releaseType=MANUAL.
5. Submit: POST /v1/reviewSubmissions → POST /v1/reviewSubmissionItems linking the appStoreVersion relationship — not appStoreVersionForReview, which 409s — then PATCH {"attributes":{"submitted":true}}.
6. Verify: read back the version and the review queue; both said WAITING_FOR_REVIEW. Only then report done.

Two things went wrong that night, which is exactly the point. First: we'd deleted the Apple Watch screenshot set, reasoning that v2.0 has no user-facing Watch surface. ASC rejected the review submission item with SCREENSHOT_REQUIRED.APP_WATCH_SERIES_4 — because the binary still ships a dormant, flag-gated Watch app, and if the binary ships it, the listing needs its screenshots. The agent recovered the previous version's Watch images through each localization's old screenshot set (imageAsset.templateUrl, fill in {w}x{h}bb.{f}) and re-uploaded them. Second: one of the new iPhone screenshots came back black — a staged camera capture the agent couldn't retake, because a camera pointed at nothing is one of the few things an agent genuinely cannot fake. We shipped three good screenshots and deferred the hero shot to a metadata update.

Both failures are now permanent lines in the runbook. That's the loop this whole post is about.

The staircase this stood on

Here is what that one night actually consumed, with dates. I went back through the repo's own records to check my memory, because "I couldn't have done this cold" is exactly the kind of claim people flatter themselves with.

May 26 — the first submission took ~7 hours, by hand. Four build cycles, two screenshot redos, a privacy-declaration expansion. It produced a 12-item gotcha list that reads like a hazing ritual: screenshots must be exactly 1284×2778 (a native iPhone 17 Pro screenshot is 1206×2622 — "close" is a rejection); macOS screenshots carry an alpha channel that ASC rejects, and sips silently fails to strip it while PIL and ImageMagick work; the listing's "Requires iOS X" line is derived from the binary's deployment target, not your marketing copy; every data type you declare in App Privacy must appear, by Apple's exact name, in your privacy policy, because the reviewer reads both and matches them.

June 21 — credential archaeology. A headless upload needs an ASC API key. The .p8 had been created back in September 2025 and later removed from the repo; the working copy was recovered from a git blob in the repo's history, validated with openssl, and stored properly. The same session proved the "normal" path — uploading through the signed-in Xcode account — is flaky from a headless CLI context (Xcode 26's account layer can't reliably be reached from a spawned xcodebuild), which is why the API-key path matters. fastlane was also a dead end on this machine (system Ruby, no bundler). Every one of those dead ends cost real hours, once.

June 25–26 — the recipe gets validated on a real release. Issuer ID resolved, device registration via POST /v1/devices proven (the CLI's -allowProvisioningUpdates does not register unknown devices, another thing you learn exactly once), and then v1.5.7 shipped through the full headless path: archive → export → altool → poll → attach → submit. A pre-submission audit that same day caught a genuine rejection blocker — a feature that had drifted out of its internal-build gate and contradicted a note we'd previously given Apple's reviewers.

July 4 — the release-order trap. A marketing version closes for TestFlight beta review the moment it's released on the App Store (ENTITY_UNPROCESSABLE.CLOSED_VERSION). Learned on v1.5.8, encoded as "do not click Release until beta review clears." This is why the agent left releaseType=MANUAL and why the human keeps the Release click.

And under all of that: the app itself. The "48-hour" v2.0.0 was a carve-out from an app that took 18 months to build — the capture flow, the cloud GPU rendering pipeline it calls (already deployed, already canary-tested), the build system, the signing setup, the device-automation harness the agent used to screenshot its own UI changes on a physical iPhone. The velocity of the last 48 hours was almost entirely stored potential energy.

The part that isn't about Apple at all

There's a second dependency that's easy to miss because it doesn't live in any runbook: knowing when to believe the agent.

Agents report success with the same fluent confidence whether or not the thing succeeded. Early on, I got burned by this repeatedly — "done and verified" claims where the verification was the agent's own optimism. The discipline that fixed it is boring and absolute: verify the effect against an independent signal, never the self-report. It's baked into the submission runbook in small, specific ways: don't trust the upload script's exit code (a trailing tee masks altool's real status — look for UPLOAD SUCCEEDED and a Delivery UUID); don't trust "submitted" until the API reads back WAITING_FOR_REVIEW; don't trust a config change until the serving system proves it changed.

That discipline is why the agent could run for hours without me watching. Not because it doesn't fail — it failed twice that night — but because the process doesn't let a failure masquerade as a success. It took months of being burned to internalize that, and I don't think there's a shortcut. If you hand an agent a task you've never done yourself, you have no independent signal to check it against, and you've built an unsupervised liar with API access.

What the human still did

Worth being precise about, since "end-to-end" invites exaggeration. I decided what the app was and what got cut. I reviewed the store description and What's New before they went up. I confirmed the privacy labels in the ASC web UI — there is no official API path for privacy labels (the endpoints 404 with a valid key; the one tool that automates them rides a private Apple-ID session API). I kept the Release click. And I was the reason there was anything to submit: the judgment calls about what a two-day pivot should contain came from 18 months of watching real users hit the previous app.

The transferable version

If you want an agent to do some multi-step, high-stakes process for you headlessly, I now believe the path is:

1. Do it by hand first, badly. The 7-hour version is not wasted time; it's the tuition.
2. Write down every trap as it bites you, in a runbook the agent will literally read. Mine says things like "READ IT" at the top, and agents do.
3. Make verification independent of the agent. Every step needs a check the agent can't wish into passing: a state read back from the API, a checksum, a serving system's own report.
4. Keep the irreversible clicks human until the boring parts have earned trust. releaseType=MANUAL is a philosophy, not a config value.
5. Feed failures back into the runbook the same night. The Watch-screenshot 409 is already in mine, so the next agent won't pay for it twice.

The headline version of that night — AI ships app in 48 hours — is technically true and deeply misleading. The truthful version is better, I think: an agent turned 18 months of accumulated, written-down, independently-verifiable experience into one night of execution. The leverage is real. It's just not free, and it's not the model — it's the runbook, and the failures that wrote it.

I hit this as a developer trying to get my own dev build onto my watch, but the bug is device-wide: on the same watch, Snapchat and American Airlines failed to install the exact same way. Store apps, TestFlight, enterprise, and dev builds all ride the same broken path.

The bug

On watchOS 26.5/26.5.1, installs from the iPhone's Watch app ("Available Apps → Install", or the "Show App on Apple Watch" toggle) fail after ~1 minute. It worked fine on ≤26.4. Reboots don't help.

You're not alone: Developer Forums thread 827053 has at least six developers reporting the identical failure across enterprise distribution, dev-provisioned OTA installs, and plain Xcode builds — one with an academic project deadline riding on it. Apple has acknowledged it (feedback FB22807635); an Apple engineer replied in June: "it is most likely a regression we have known, and folks are actively working on that." The underlying failure is the transfer socket timing out:

ACXError Code=8 "Failed to create socket"
identityservices Code=20 "Socket open timed out"

As of July 20, 2026, no shipped watchOS release fixes it. The watchOS 26.6 release candidate just went out to developers, with no public confirmation either way on whether the fix made it in.

What's actually breaking (the plain-English version)

When you tap Install in the iPhone's Watch app, the app doesn't come from the internet to the watch — the iPhone transfers it to the watch over their private phone↔watch link (Apple's Identity Services layer, riding Bluetooth). On watchOS 26.5, opening that transfer socket times out — so the install fails after a minute, no matter how many times you retry, reboot, or re-pair. The app never leaves the phone.

That also explains why the workaround works: take Bluetooth away, and the watch falls back to WiFi — where a Mac can hand it the app directly, skipping the broken relay entirely.

What does NOT work (I tried all of it)

• Rebooting phone and watch (in every order)
• Toggling the app off/on in the iPhone's Watch app
• Unpairing and re-pairing the watch (others in the thread also ruled out factory resets and fresh certificates/provisioning profiles)
• Toggling Bluetooth off/on on both devices — this one is worth trying first, because it has worked for several people in the forum thread. It didn't take for me. If it doesn't for you either, the fix below is the reliable path.
• TestFlight instead of a dev build — same phone↔watch transfer path, same failure

If you're a developer, Xcode "Run" against the watch also stalls, for a different reason — see below. That combination (store path broken + Xcode path broken) is what makes this bug so disorienting: every install route fails, each with a different symptom.

The fix that worked (reproducible)

The trick is to take Bluetooth out of the equation entirely and push the app over the network path instead. The forum thread independently converged on devicectl as the working install route; what follows is the complete recipe — including the two pieces that cost me the most time (why Bluetooth has to be off first, and which of the tooling's status reports to ignore).

One honest caveat: this is a developer workaround. devicectl ships with Xcode, so if you're distributing to enterprise users or testers who don't have a Mac with dev tools, they're stuck with the Bluetooth-toggle lottery until Apple ships the fix. (Non-developers: also try installing from the App Store on the watch itself — that path downloads directly to the watch rather than relaying through the phone. Reported to help for adjacent variants of this failure, though I haven't tested it on 26.5 myself.)

1. Turn the iPhone's Bluetooth OFF.

This forces the watch onto WiFi and lets the Mac↔Watch CoreDevice tunnel come up. Keep Mac, iPhone, and watch on the same real WiFi network — not the iPhone's Personal Hotspot, which isolates the devices from each other. (In my case the tunnel had been dead for a day — tunnelState=disconnected, ddiServicesAvailable=false — and came up once Bluetooth was off.)

2. Install with devicectl from the Mac — not Xcode "Run":

xcrun devicectl device install app \
  --device <WATCH-COREDEVICE-ID> \
  --timeout 240 \
  "$HOME/Library/Developer/Xcode/DerivedData/<YourApp>/Build/Products/Release-watchos/<Your Watch App>.app"

Find your watch's CoreDevice ID with xcrun devicectl list devices. Use the Release-watchos build product — it's clean, with no __preview.dylib inside.

Two verification notes, because this path lies to you in both directions:

• devicectl device info details may still report tunnelState=None from stale cache even when the install succeeds. Trust the App installed output of the install command, not the info query.
• If the install command itself succeeds, the app is on the watch — you don't need the iPhone Watch app to agree, and it may take a while to notice.

Why not Xcode "Run"?

Xcode blocks on "Copying shared cache symbols (0%)", and on watchOS 26.5 that symbol download fails with an HTTP 403 ("Symbols for watchOS 26.5 — forbidden"). Here's the thing: that download is debugger support only — it has nothing to do with installing the app. devicectl install skips it entirely, which is exactly why it works when Xcode doesn't.

If you don't need to attach the debugger, devicectl is strictly the better path on 26.5.

Summary

If this saved you a day, it cost me one — file feedback on FB22807635 anyway; duplicate reports are how Apple prioritizes.