The engineering time that starts after the feature is finished
The wrongest estimate in mobile work is not build time — it is time from finished code to an installed update. App Store review, Android permission-model deadlines, and OAuth production verification sit on someone else's calendar. Plan those as separate workstreams with lead time, not as paperwork after the feature is "done."
The estimate ends where the work doesn't
When someone asks how long a feature will take, everyone involved is picturing implementation. The number that comes back is an implementation number, and it's usually a decent one, because engineers are better at estimating code than they get credit for.
What isn't in it: building for release rather than debug and finding out that a dependency behaves differently under optimization, filling out the privacy disclosures for a new capability, screenshots at every required size, the review wait, and the second review wait after the first one comes back with a question. On a small feature that tail can be longer than the implementation it's attached to.
This isn't an argument for padding estimates, which just makes them wrong in a less useful direction. It's an argument for estimating the two things separately, because they have different shapes. Implementation time responds to adding people. Review time does not respond to anything.
Review is a scheduling dependency, not a task
App Store review is usually fast now, and that's precisely what makes it dangerous to plan around. Teams internalize the good case, plan as though submission is the last step, and then get a rejection that costs a full cycle for something that had nothing to do with the code.
The rejections that have cost us time were about metadata and explanation rather than about the app being wrong. A permission whose usage string was too vague about why the app needs it. A subscription whose terms weren't presented the way the guidelines require. A feature a reviewer couldn't reach, which is a category worth naming, because reviewers work through the app cold and anything behind a login or a specific data state may as well not exist unless you tell them exactly how to get there.
Two habits removed most of this. Reviewer notes that say precisely how to reach every new feature, in numbered steps, including any state the account needs to be in. And an app that does something useful without an account, which for Endeo is true by design and turned out to be worth as much at review time as it is on first launch.
| Gate | What it actually costs |
|---|---|
| App Store review | Screenshots per device size, privacy answers, a rejection cycle you can't schedule |
| Android scoped storage | Permission model changes that alter working code |
| OAuth production verification | A review process on someone else's timeline |
| Store listing | Copy, keywords and assets that are their own craft |
None of it is engineering, all of it is on the critical path, and it's the part nobody quotes for.
Android's permission model moved under us
BuilderHelp's field app scans receipts and captures jobsite photos, so it lives on the storage and camera APIs. Android's scoped storage changes rewrote how an app is allowed to touch files, and the target SDK requirements mean you don't get to opt out by staying put: staying current is a condition of shipping updates at all.
The migration itself was tractable. What cost real time was that the correct behavior differs across OS versions and across manufacturers, and the crews using this app are on a device fleet nobody curated. That's a testing problem more than a coding problem, and it doesn't get solved by reading the documentation, only by running the build on the actual spread of hardware.
The lesson we took is to treat platform requirement deadlines as scheduled work in the roadmap rather than as interruptions. They're announced well in advance, they're not optional, and the only variable you control is whether you handle them on a quiet week or during a release crunch.
OAuth production verification
Signing in with a third-party account works immediately in development. The app is unverified, the consent screen carries a warning, and for a handful of test accounts nobody cares. Moving to production means going through a verification process with a provider, and that process is not measured in hours.
It involves scope justification, a privacy policy at a stable public URL, a demonstration of the flow, and sometimes a domain ownership check. The requested scopes get scrutiny, and the practical advice is to ask for the narrowest set that makes the feature work, because every additional scope is another thing to justify and another reason for the submission to come back.
The specific trap is sequencing. This is easy to leave until the end because it isn't code, and then you're finished, tested, ready to ship, and waiting on someone else's queue with a launch date already communicated. Start the verification when you start the feature. It runs in parallel with implementation and it costs you almost nothing to have begun early.
How we budget for it now
We plan releases with the external dependencies on the calendar as their own items, with their own start dates, most of which are well before the code is done. Verification submissions, privacy disclosure updates, and store metadata are work with lead times, not paperwork you do at the end.
We also submit earlier and more often. A release that goes to review with two weeks of buffer absorbs a rejection without anyone renegotiating a date. A release submitted the day before launch turns a metadata question into a crisis. Frequent small submissions also mean each review has less surface area to go wrong on.
None of this is clever. It's the difference between treating the platform as a deployment target and treating it as a party with its own process and its own schedule. The second framing is accurate, and once a team adopts it the estimates stop being wrong in the same direction every time.
Questions
- What should be estimated separately from implementation for mobile releases?
- Release-config builds, privacy disclosures, store screenshots, review wait (and re-review after questions), platform permission migrations, and third-party OAuth production verification. Those tails often exceed the feature's coding time.
- How do you reduce App Store rejection churn?
- Write reviewer notes with numbered steps to every new surface, including demo credentials and required data state. Many costly rejections are metadata, permission strings, or features the reviewer cannot reach cold — not broken code.
- When should OAuth production verification start?
- Well before code freeze. Scope justification, a stable public privacy policy, flow demos, and domain checks run on the provider's queue. Leaving verification until launch week turns a paperwork lag into a missed date.