6 ways an iPhone automation fails without throwing an error (from 1,547 real posts)

Disclosure: I'm on the team that builds Foundry, the tool this comes from. This is a debugging write-up; the link is at the bottom.

We post short-form video from a rack of real iPhones: 9 phones, 47 accounts, 1,547 posts since Aug 21. The official Instagram, TikTok and YouTube apps are driven through iOS UI automation (WebDriverAgent), and a coding agent queues the work through a CLI.

Yesterday I wrote about what broke first. This one is narrower: the failures that never raised an exception. The run looked green and the post was simply not there.

1. The phone's count was full and one account posted nothing

Our scheduler covers a failed post with another post on a different account of the same phone. Sensible, until we looked per account: one phone showed 10 of 10 for the day while one of its YouTube accounts had posted zero for five days.

Fix: count planned against live per account, never per device. A fallback that keeps the total looking healthy is hiding a dead lane.

2. A system alert is not in the app's element tree

Apple's App Tracking Transparency prompt is a system alert. It does not show up in Instagram's accessibility tree, so the poster saw the Instagram screen behind it, tapped "Continue" on that, and nothing happened. Forever.

Fix: before acting, read what is actually on screen (system alerts included) and tap the exact label, in our case "Ask App Not to Track". Do not match on a generic button name that also exists behind the alert.

3. The same app behaves differently on a different iPhone model

On one iPhone 12 Pro, tapping a video tile in YouTube's picker opens the trim page right away. Our check that "the right clip is selected" took its picture after the tap, scored a black corner of the trim page, and refused the correct clip 13 times in a row.

Fix: take the proof before the tap, and only use it once the tile has left the screen. Then we made it stricter after review: a near-blank clip is accepted only with the pre-tap match and a second signal (the selection tray's length).

4. A counter that wobbles is not a receipt

For TikTok we first confirmed a post by the profile's video count going up. That count wobbles by one on its own, so it produced both false passes and false fails.

Fix: wait while TikTok's upload chip is showing, then confirm. Pick a signal that only the event you care about can cause.

5. A dropped session can need a human hand, and no retry will fix it

When an automation session ends, the phone may want its passcode before automation mode comes back. The log line is Timed out while enabling automation mode, and the phone's own log says the daemon "requires authentication to enable automation mode". One morning all nine lanes dropped at once and stayed down until someone walked to the rig.

Two things helped:

• Settings > Developer > Enable UI Automation, switched on by hand once per phone.
• A watcher that runs every 30 minutes, stays silent when healthy, and when lanes are down with posts overdue it names the blocker (Mac screen locked, phone with no USB session, passcode) for a human.

Our agents never answer a Trust or passcode prompt. That is a person's job on purpose.

6. The fix itself was too loose

Two of the fixes above went onto the rack, then an independent review found the first versions accepted too much. We reworked both. The lesson we wrote down: review before you install on the machine that is posting, not after.

The audit that caught all of it

One script, run for any date range:

• planned posts against done posts, per phone and per account
• every miss listed with its cause
• "done" YouTube rows checked against the public channel feed
• "unknown" TikTok rows checked against the public profile

Three days in early October came back 159 of 165 live. After the fixes, the next full day was 61 of 62. The six misses were the interesting part, because each one was a green run.

If you automate real devices

• Verify against the public result, not your own log.
• Count per account or per tenant, not per device.
• Treat system alerts as a separate layer from the app.
• Take proofs before the action that changes the screen.
• Decide in advance which prompts only a human may answer.

We packaged the poster as Foundry: a Mac app, a CLI and an agent skill, running on your own iPhones and your own accounts. 7 days free: https://runfoundry.app

If you run device automation at any scale, what was your worst green run?