Umpy is ours โ an officiating app live on the App Store and Google Play, handling assignments, crew chat, searchable rulesets and on-field tools that have to work on a diamond with no signal. Shipping it is why we can be specific about the costs that never make it onto a quote.
The ranges
| Type of app | Both platforms | Timeline | Example |
|---|---|---|---|
| Simple / single purpose | $25,000โ50,000 | 2โ4 months | Booking, catalogue, calculator |
| Standard with backend | $50,000โ100,000 | 4โ6 months | Accounts, sync, notifications |
| Complex / real-time | $100,000โ200,000+ | 6โ12 months | Chat, live data, offline sync |
| Annual upkeep | 20โ30% of build | Continuous | OS updates, store compliance, fixes |
Canadian rates, 2026. The upkeep row is not optional โ an unmaintained app breaks within about a year of OS releases.
The costs quotes leave out
Store review
Apple rejects apps, often for reasons that are not obvious from the guidelines. Budget one to three weeks per submission and expect at least one rejection on a first release. This is real work, not a formality, and it belongs in the timeline rather than as a surprise at the end.
Supporting old devices and OS versions
Your users are not all on the current OS. Every version back you support adds testing and adds edge cases. Deciding this early is a cost decision as much as a technical one.
Push notifications
They sound like a feature and behave like infrastructure โ certificates, delivery handling, per-platform differences, and a backend that has to know who to notify and when. Quoted as a checkbox, they are frequently a week.
Offline behaviour
If your app must work without a connection, the cost changes materially. Umpy has to work on a diamond with no signal, which means local storage, conflict resolution, and sync logic for when the connection returns. That is engineering, not a setting.
Ask this before you commission anything
What does this app do that a fast mobile website could not? If the answer is not offline capability, push notifications, device hardware, or genuinely frequent daily use, a website will serve you better for a fraction of the cost โ and nobody has to install anything.
Native, cross-platform, or web
| Approach | Relative cost | Best when |
|---|---|---|
| Progressive web app | 30โ50% of native | No offline or hardware needs; want zero install friction |
| Cross-platform | 60โ80% of native | Both platforms needed, standard interface patterns |
| Fully native | 100% | Heavy device features, performance-critical, platform-specific UX |
Cross-platform is the right default for most business apps in 2026. Fully native earns its cost when you are leaning hard on device hardware or performance.
What to confirm before signing
- โIs store submission and review included, or billed separately?
- โWho owns the developer accounts โ you should
- โWhat is the annual maintenance cost, in writing?
- โWhich OS versions are supported, and what happens when new ones ship?
- โWhat has the team shipped to both stores themselves?