The seven-day wall: why your iPhone automation stops working every week

Everything worked on Monday. On the following Monday the phone is on the same desk, on the same cable, unlocked, listed by every tool that enumerates iOS devices — and xcodebuild fails on signing, WebDriverAgent never comes up, and whatever is driving the phone reports it as offline.

Nothing is broken. A provisioning profile expired, on a schedule Apple published, and every layer above it went down with it.

What actually expired

If you signed WebDriverAgent with a free Apple ID — what Xcode calls a personal team — the provisioning profile it minted is valid for seven days from the day it was issued, and that is documented behaviour, not a fault. A paid Apple Developer Program membership costs $99 a year and mints development profiles good for up to a year.

This is the single most common reason iPhone automation stops working every week, and Apple's own forums carry the same thread over and over — 69248, 68164, 70282.

A free team gives you seven days of working automation and then a build failure. The paid track is the same build on the same phone, with the clock set to a year.

The chain, and the one link with a clock on it

The confusion comes from how much of the chain is still healthy on day eight. Your certificate has not expired. The App ID still exists. The runner is still installed on the phone. Only the profile that ties them together has lapsed, and the failure surfaces at the far end — as a runner that will not launch, which reads as a device problem.

Four of the five links are fine on day eight. The failure appears at the fifth, which is why people go looking for cables.

The two limits nobody mentions until they bite

Two more ceilings sit alongside the expiry, and rebuilding WebDriverAgent eats into both.

Three apps at a time, on a free team only. Free provisioning allows three apps installed at once. The WebDriverAgent runner is one of your three.
Ten new App IDs per rolling week — this one applies to paid accounts too, so upgrading does not clear it. Every distinct bundle identifier you register spends one, and WebDriverAgent's stock identifier — com.facebook.WebDriverAgentRunner — is a globally registered App ID you cannot provision under your own team, so you have to override it. Every time you change that string while trying to get a build to work, you have spent one of ten.

Why a free Apple ID was never meant for this

Free provisioning exists so a person learning to write an app can put it on their own phone and try it out over a weekend. The seven days are the point of the feature, not an oversight — it is a trial of the toolchain, not a distribution channel. Automation that runs unattended is a use Apple did not design it for, and building on it means accepting a scheduled outage every week.

The three ways out

Pay the $99. Development profiles last up to a year, the three-app ceiling goes away, and the weekly failure stops existing. For anything that runs without a person watching, this is the only honest answer.
Re-sign on a schedule. A weekly job that rebuilds and reinstalls the runner. It works, and it means a cron entry now owns whether your automation runs on Tuesday.
Re-sign by hand when it breaks. Fine for a phone you sit in front of. Not fine for anything that has to fire at nine in the morning.

An expiry is not a crash, which is why it costs an afternoon

Here is the part that turns a five-minute fix into a wasted day. When the profile lapses, nothing announces it. WebDriverAgent simply stops answering. A controller that only knows "the phone responds" or "the phone does not" will report offline — and offline sends you to cables, ports, hubs and USB drivers, none of which are the problem.

The distinction that matters is between the phone is not here and the phone is here but the control layer is not answering. Those are different faults with different fixes and they must not share a word.

Ten seconds to tell them apart

Two questions, in this order. Device enumeration does not depend on WebDriverAgent at all — idevice_id -l talks to Apple's own USB multiplexing daemon — so if the UDID prints, the cable, the trust relationship and the USB path are all fine and you can stop looking at them.

Enumeration and control are separate layers, so ask about them separately. A phone that enumerates but will not answer /status has a control-layer fault, and a lapsed profile is the most common one.

The second question is WebDriverAgent's own health endpoint. It answers /status with a readiness flag, and that flag is the only trustworthy signal — a runner can die from a phone reboot, a pulled cable or a build timeout without anything telling the Mac about it.

What NOISEY does, and what it will not do

We hit this and misdiagnosed it as a dead cable first, which is why the desktop app now draws the line in three places.

The iPhone setup checklist in Settings → iPhone runs seven checks — Xcode, the iOS platform support package, the device tools, an Apple Developer team, the WebDriverAgent checkout, a trusted iPhone, and Developer Mode — and each failed row carries the fix in the words you need, not a stack trace. The team row prints the team it will sign with, so you find out on day zero whether you are on a personal team or a paid one, rather than on day eight.
Before every session the app probes WebDriverAgent's /status rather than trusting its own bookkeeping, and it remembers a runner that is already listening — the XCTest process outlives the xcodebuild that started it, and outlives the app, so a restart would otherwise spend three minutes rebuilding something that was already there.
The two failures get two different notices: No iPhone on this Mac and iPhone not ready yet. That is the same split the status dots already make on the Android side, where offline and error mean genuinely different things.

What it does not do: there is no background job that re-signs your phone on a timer, and NOISEY never holds Apple credentials. Signing happens when you ask for something, using the team already signed in to Xcode. A tool that quietly re-signs and reinstalls a runner on a schedule is a tool that can silently spend your App ID budget and silently change what is installed on your phone, and neither should happen without you asking.

A cold start — build, sign, install, boot the runner — is minutes, not seconds. The launcher allows it 180 seconds and then gives up loudly. If it gives up, the phone is usually locked: WebDriverAgent cannot start against a locked screen, and the developer disk image will not mount against one either, which is also why an iPhone needs a human unlock after every reboot before any automation can start.

If a phone is missing and you want the checklist rather than the theory, the docs walk it, and Activity prints the error under any job that failed, with the attempt count. Nothing fails silently is a rule, not a slogan — an automation that stops working every seventh day is exactly the kind of failure that gets blamed on the wrong layer.