Mobile apps: where shared code stops, what year one costs

• If the core value of the app is iOS-native craft, a Swift team that already exists is the better call. Talk to one first. We would be assembling that team for your engagement rather than bringing one that has worked together for years. Nothing on our record says otherwise and we are not going to imply that it does.
• If you need people on this on Monday, we are not it. We do not keep a mobile bench sitting idle waiting for work, so a mobile team here is put together for the engagement. That is honest, and it takes weeks rather than days.
• If the answer you have already settled on is Flutter, we have nothing on the record and will not pretend that we do. Ask the firms who can show you Flutter apps they shipped.

There is one place we would push back on the premise instead of walking away. If what the job actually needs is the mobile web, install-free, works offline, quick on a cheap Android handset, that is where our depth genuinely sits. How we tune apps under real device and network load, and our commerce work, are the better read for that. And if the real first step is to launch a market-ready MVP in weeks, or the multi-tenant SaaS backend that sits behind the app, meaning one system that serves every customer while keeping each one's data separate, those are separate reads too.

Shopify moved an app of roughly three hundred screens, and its Point of Sale product, onto React Native, and reports P75 screen loads, meaning the slowest quarter of users, under 500 milliseconds and better than 99.9 percent crash-free sessions. They got there by building FlashList and react-native-skia themselves, and they still write native code for hardware, widgets, Watch apps and background sync. Coinbase reached 100 percent of its iOS users on React Native by January 2021, and did it by starting fresh rather than bolting the framework onto an app that already existed. So this is a finding about where and how shared code is introduced. It is not a finding that the framework is bad.

Which means the question to put to the next firm that quotes you is not native or cross-platform. It is: which of these five surfaces does my app actually have, and what will you write natively for each one.

Take the free route for crash reporting and push, which is Crashlytics, Firebase Cloud Messaging and Google Analytics for Firebase, and the same year comes to 424 US dollars. The backend line stays in either way, because none of those three replaces it. Store commission sits outside all of this and it is a rate rather than a line item: 15 percent under Apple's Small Business Program if you enrol and qualify, 30 percent otherwise, and 15 percent on the first million dollars under Google Play's service fee tiers.

Both are signed public contracts. Each ratio is the annual support fee divided by the one-time build cost, taken from the contract documents themselves: Michigan DTMB contract 071B6600092, and the City of Mauston, Wisconsin award. The Michigan State Police contract was a custom build at 325,200 USD. The City of Mauston, Wisconsin contract was a templated build at 7,490 USD. The gap is not the size of the build. The clearest reading of it comes from Nixa, Missouri, which priced three competing vendors on identical scope inside one procurement document. Their maintenance ratios were 9.4 percent, 13.6 percent and 67.7 percent. Same scope, same document, a sevenfold spread. So the ratio is a vendor pricing decision, not a property of the software you are buying. The 183 percent figure at the top of the range, Owego Apalachin school district, is a whole-platform annual fee rather than app maintenance on its own, which is why it is described here and not drawn beside the other two.

We are not going to publish a build price band. We could not trace the widely repeated 171,450 dollar average to any source that is not an agency selling builds. Try it yourself. We start with a small paid first phase that settles the boundary question for your app. Then a build quoted against what that phase actually found. Then the annual platform work as its own standing line. We write the build and the annual support into our agreements as two separate signed numbers, and from day one every line of code is yours. Send us the hard part of your app if you want the first phase scoped.

Apple runs a review rather than a waiting period. In its 2024 App Store Transparency Report, Apple rejected 1,931,400 of 7,771,599 submissions, roughly one in four. Performance was the largest single reason at 1,235,471. Of the 1,931,400 rejections, 295,109 were approved later after a fix. That is roughly 15 percent, so about 85 percent were not approved after a fix in the same report. Budget a rejection as a date you lose, not a delay you absorb.

That gap is the entire reason the annual line exists. Missing Apple's SDK gate or Google's submission gate stops you shipping updates while the app stays discoverable and installable. Google's separate rule for existing apps is the one that removes it from search and from new installs.

Google states the consequence in its own words: an app over a threshold is likely to be less discoverable on Google Play, and in some cases a warning may be displayed on your app's store listing to set user expectations and provide the option to seek out alternatives with higher technical quality. We write both into our own contracts as terms. If you already have an app, you can pull them out of Play Console tonight and find out where you stand before you talk to anyone.