A mobile app's cost and timeline are driven far less by the number of screens than by a handful of decisions: how many platforms you ship natively, whether the app must work offline, how many systems it integrates with, how custom the design is, what compliance applies, and how releases and maintenance are handled after launch. Two apps with the same screens can differ widely in effort because of these choices. Fix them early and an estimate becomes something you can plan around.
We deliberately do not quote figures here. Any number without your scope is a guess, and a guess repeated in a blog post turns into a budget. What we can do is show where the effort goes, so you can see which of your requirements are expensive and decide whether each one is worth it.
Platforms and technology choice
The first driver is how many codebases you maintain.
- One cross-platform codebase (Flutter, React Native, or a web app wrapped with Capacitor) covers iOS and Android with one team. Platform-specific work still exists, such as permissions, push setup, store assets and device quirks, but it is a fraction of the whole.
- Two native codebases (Swift and Kotlin) mean building and testing most features twice, in exchange for the best platform fit. That is right for some products; our post on when to go native covers which.
- Tablets, watches, web and desktop each add layouts, testing and sometimes separate release tracks. Decide early whether "also on iPad" is a real requirement.
The device range matters too. A company app on a known set of phones is simpler to test than a consumer app that must work on older and low-end Android devices, where performance and memory limits appear.
Offline and background behaviour
Offline-first is the single largest multiplier we see on business apps. An app that needs a connection sends requests and shows the result. An app that must work without one needs a local database, a queue of pending changes, a conflict rule for each type of record, schema migrations that protect unsent data, and a lot of testing in awkward conditions: airplane mode mid-save, the app killed during upload, two people editing the same job.
Background work adds to this. iOS and Android both limit when apps can run in the background, so features such as "sync overnight", continuous location tracking or large uploads while the phone is locked need careful platform-specific work, and sometimes a change of expectations. Our offline-first sync architecture post explains the moving parts.
Integrations and the backend
A mobile app is usually the small visible part of a system. The effort behind it depends on:
- Whether a usable API already exists. If your ERP, CRM or product database already exposes well-documented endpoints, the app consumes them. If not, someone builds and hosts that backend, and it is often the larger half of the project.
- The number of systems. Each integration brings its own authentication, data model, error cases and test environment. Payments, maps, SMS, identity providers and ERPs each count.
- Who owns the other side. Integrating with a system your team controls is quicker than waiting on another vendor for credentials, sandbox access and bug fixes.
- Data quality. Duplicated customers or inconsistent product codes in the source system surface in the app and must be cleaned or handled.
For apps against Odoo, the plan and hosting matter: external API access on Odoo Online depends on the pricing plan. Our post on mobile apps for Odoo field teams goes through the options.
Design and user experience
Design effort varies with how much the app departs from platform conventions. Standard navigation, lists, forms and system controls are quick to design and build, and users already know them. A distinctive brand-led interface with custom components, animation and illustration takes longer at every stage: design, build, and testing across screen sizes and accessibility settings.
Other design drivers that are easy to underestimate:
- Roles. A driver, a supervisor and a customer seeing different versions of the same app is three sets of flows to design and test.
- Languages. Each language means translation, longer labels that break layouts, and right-to-left support if you need Arabic or Urdu. In India, supporting regional languages for field staff is often worth it, and worth budgeting for.
- Accessibility. Dynamic text sizes, screen readers and contrast should be built in from the start; retrofitting them is slower.
Security, privacy and compliance
Some requirements are the same for every app: secure sign-in, encrypted storage of tokens, privacy disclosures for both stores, in-app account deletion if users can create accounts. Others depend on your sector and markets, and can add significant work:
- Personal data rules, such as India's Digital Personal Data Protection Act or the GDPR for European users, affect consent flows, data retention, and where data is stored.
- Payments. Selling digital goods inside an app generally means the stores' own in-app purchase systems; physical goods and services use a payment gateway. Each has its own integration and review requirements.
- Regulated sectors such as health and finance may require security reviews, penetration testing, audit logs and documentation before launch.
- Company device policies, such as distribution through mobile device management or single sign-on with your identity provider.
Release, testing and maintenance
Launch is not the end of the cost; for most apps it is the start of the longer part.
- Store release work. Developer accounts, store listings, screenshots, privacy forms, review cycles and test tracks. A new personal Google Play account must also run a closed test with at least 12 testers for 14 days before production, which affects the calendar. Our post on releasing to the App Store and Google Play covers the process.
- Testing on real devices, including older phones your users actually carry.
- Yearly platform updates. Apple and Google raise their minimum SDK and target requirements every year. In 2026, App Store uploads must be built with the iOS 26 SDK, and Google Play updates must target Android 16 from 31 August. An app nobody touches will eventually be blocked from updating.
- Dependency and backend upkeep: library upgrades, security patches, server hosting, monitoring and crash reporting.
Budget for the second year when you budget for the first. The stores will make you.
How to get an estimate you can trust
- Write down the drivers: platforms, offline tasks, integrations, roles, languages, compliance and who maintains the app after launch.
- Separate the first release from the wish list. Ship the smallest version real users will adopt, then add features based on use.
- Spend a short discovery phase on the risky parts, usually the integrations and offline sync, before committing to a full plan.
- Ask for an estimate with its assumptions listed, so a change of scope shows clearly as a change of cost.
If you have a feature list and want to see which items drive the effort, our mobile app development team can go through it with you, or you can get in touch directly.
Questions we get asked
What makes a mobile app expensive to build?
The main drivers are building separate native apps for iOS and Android, offline working with data sync, the number and quality of integrations with other systems, custom design and animation, multiple user roles and languages, compliance requirements such as data protection or payments, and ongoing maintenance. The number of screens matters much less than these decisions, which is why two apps that look similar can need very different effort.
Is a cross-platform app cheaper than native?
Usually, because one codebase and one team cover both iOS and Android. Some platform-specific work remains, such as permissions, push notifications, store setup and device testing. Native apps cost more because features are built and tested twice, but they are the better choice when the app depends heavily on platform features, background processing or demanding performance. The right answer depends on what the app must do.
Why do mobile apps need ongoing maintenance?
Apple and Google update their operating systems every year and raise the minimum SDK and target versions that new uploads must use. Libraries need security updates, backends need hosting and monitoring, and new phone models reveal layout issues. An app left untouched will eventually fail review for updates, lose compatibility with new OS versions, or carry known security vulnerabilities, so maintenance should be budgeted from the start.
Why won't an agency give a price from a feature list?
A feature list rarely states the decisions that drive effort: whether the app works offline, which systems it integrates with and whether their APIs exist, how custom the design is, and what compliance applies. Without those, any figure is a guess. A short discovery phase that answers these questions and tests the riskiest integrations produces an estimate with stated assumptions, which is far more useful for planning.