Every mobile project we've taken on this year has run longer than quoted, which is a pattern worth being honest about rather than blaming one-off bad luck each time, especially once we sat down and actually compared quoted hours against logged hours across all four mobile projects from this year side by side.
The consistent underestimate was device testing time, we'd budget for building the feature but not for the hours spent chasing down a bug that only appears on one specific Android version or a particular screen size. A layout that looked correct on the two or three devices sitting on our desks would reliably break in some small way on a device we hadn't personally tested, a slightly different screen density, an older WebView version with a rendering quirk, and there was no way to catch that without either owning an implausibly large device collection or budgeting real time for it. We're now padding mobile estimates by roughly a third compared to an equivalent web feature, purely for that testing tail, and tracking actual hours against that padded number project to project to see whether a third is the right multiplier or whether we need to adjust it up or down as we get more data.
Also underestimated: app store submission back-and-forth, which has its own review cycle and rejection possibilities that a web launch simply doesn't have to deal with. A web feature ships the moment we deploy it. A mobile app update sits in a review queue for anywhere from a day to over a week depending on the store and the season, and a rejection for something as small as a missing privacy policy link or an icon that doesn't meet a size requirement means resubmitting and waiting through the queue all over again. We've started building a several-day buffer into any launch date that depends on app store approval, communicated clearly to the client as a range rather than a fixed date, rather than promising a specific day and then having to explain a review delay that was entirely out of our hands.
A smaller thing we underestimated: client-side asset preparation, generating every required icon size and splash screen variant for both platforms is genuinely tedious and easy to lose half a day to if it's not accounted for as its own line item rather than assumed to be a five-minute afterthought tucked into "polish."
None of this means mobile work isn't worth doing, it's some of our more interesting client work this year, but it does mean we're quoting it differently now than we quote an equivalent web project, and being upfront with clients about why a mobile estimate carries more built-in buffer than a comparable web one has, if anything, made those conversations easier rather than harder, since it's a concrete, explainable reason rather than a vague markup.