At 22:40 on 6 November an email arrived from Apple Developer: the Tap to Pay on iPhone entitlement had been assigned. Thirty seven days after we asked for it. Nobody can use it yet. The app it belongs to is sitting, for the fourth time, in a completely different Apple queue, and moving it now would cost that build its place in line.
That is the shape of the whole story. Tap to Pay on iPhone turns a worker’s own phone into a card terminal, no separate reader to buy, charge or carry. Getting it in front of a customer meant clearing two Apple processes that do not talk to each other: an entitlement, granted by Apple’s Wallet team to the developer account, and an ordinary App Store review of the app itself, run by a different team on its own clock. We had treated them, early on, as one thing with one finish line. They are not.
Two Apples, not one
We asked for the entitlement on 30 September: a form on Apple’s developer site, Stripe named as our payment processor, a guess at how many iPhones we would have in year one. The development entitlement, which lets a registered test phone take a real card in a debug build, came back the same day. The publishing entitlement, the one that lets a real customer in a shipped app use it, is a different and slower question: Apple only opens it once it has reviewed a checklist and three screen recordings showing every path a worker can take through accepting Apple’s own terms, the merchant education screen and a live transaction.
Meanwhile the app itself, Tap to Pay switched off, still had to pass the ordinary App Store review that every TipBop release goes through. That review does not know or care that a separate team is looking at Tap to Pay footage. The two queues ran the entire time side by side, and the only thing joining them was us, watching both.
Why a phone, not a reader
A reader would have meant a second object for every worker to own and a second thing to go wrong mid-shift. The whole appeal of Tap to Pay, for a product that already runs on nobody installing anything, is that the hardware is the phone the worker is already holding. That is also exactly why the two Apple gates exist: Apple treats “a phone as a card terminal” as sensitive enough to review on its own, separately from reviewing the app that phone is running.
Thirty seven days, mostly quiet
The evidence pack was the real work on the entitlement side. A long checklist, each row needing either a line of code to point at or a recording to prove it: the merchant sees the “Tap to Pay on iPhone” option before accepting Apple’s terms, accepting them opens Apple’s own education screen, a card is actually taken, a PIN is asked for where the UK needs one, a declined card falls back to our QR code. Three videos: a new worker signing up, an existing worker enabling it from three different places in the app, and a full checkout. Apple revised its own guide while we were filming, which moved some of what counted as proof.
Both numbers come from the same constraint: nobody could put a real card against a real phone until the development entitlement existed, and nobody could rehearse the full flow for the cameras on anything but a registered device. Every one of those seconds is counted from the recording, not a guess, because the checklist has a row that asks for the number and Apple reads what you write.
Four rounds with the other Apple
How long Apple's app review took, each time we tried
Four builds of the same app, waiting on the same reviewers. The one we pulled ourselves took the longest.
Source: TipBop App Store Connect submission notes, 1.0 and 1.1
Build 26 came back fast: Apple wanted more detail on how a reviewer signs into the demo account, not a defect in the app, and we answered it in the review notes. Build 31 then sat for fourteen days, long enough that a mandatory sign-in change on our own side made it obsolete before Apple ever looked at it again, so we withdrew it ourselves and resubmitted as a new version. Build 35 is the one we own without qualification: Apple rejected it under Guideline 4 because the setup screen asked a worker for their name after Sign in with Apple had already given it to us. We had the name sitting in memory and asked for it again anyway. The fix was to show it instead of asking, and it shipped as build 36 two days later.
There is a near miss from earlier worth saying out loud too. In September we had planned to show the Tap to Pay tab in TestFlight even before the entitlement existed, as a preview. We caught it ourselves before Apple did: an App Review install carries the same kind of sandbox receipt as a TestFlight one, so a reviewer would have opened a tab that could never complete a payment, which is exactly what Apple’s Guideline 2.1 exists to catch. We pulled the preview before anyone at Apple saw it, which is the better place to find that kind of mistake than a rejection letter.
What it cost, and what would change the sum
A sceptical reader might ask why a payments feature took this path at all while the app had two installs on Android when we last looked, on 29 October, and nothing yet on iOS. The honest answer is that a small, slow launch is what makes a two-gate, five-week wait tolerable in the first place. Nobody is being told to wait for a feature they are actively trying to use; the cost is entirely engineering time and queue position, not a customer standing at a till with a declined tap. We can afford to lose a week to a withdrawn build precisely because there is no queue of real workers behind it yet.
That changes once there is. If Tap to Pay becomes something real workers are asking for by name, waiting on Apple’s clock stops being a line in a decision log and starts being a support ticket. The trigger to revisit this is not a date, it is demand: the first time a worker says they turned down a tap because the feature was not there yet is the point to start asking Apple, in writing, what a faster path looks like, or to reconsider a reader for the venues that cannot wait.
What it has already cost us is plainer. Keeping the Release flag off while Debug carries the entitlement means a second entitlements file, a parity test holding both in step, and a feature that has never once taken a real card outside a rehearsal, because the one device allowed to try was also the one device every recording depended on. And the entitlement being granted on 6 November buys us nothing this week: Tap to Pay was due to ship in the version now waiting as build 36, and pulling it out to add Tap to Pay would mean resubmitting and losing the queue place again. It ships in whichever release comes after this one clears.
