Loading…
Loading…
Mobile app development for enterprises: native vs Flutter vs React Native, the 7 stages, cost drivers, app store rules, security and when not to build an app.
Mobile app development is four decisions before it is any code: who the users are, which approach to take, what the app connects to, and who maintains it.
There are four ways to reach a phone: native apps, cross platform apps built with Flutter or React Native, progressive web apps and responsive websites. Each one wins somewhere.
Flutter and React Native are both mature. Choose by your team's skills, not by benchmarks.
Cost follows scope, integrations, offline sync and security far more than the hourly rate.
Launch is the start, not the finish. Apple and Google raise their requirements every year, so every app needs a maintenance budget.
Sometimes the best app is no app. A responsive web app or WhatsApp may reach your users with nothing to install.
Search for mobile app development and the first page belongs mostly to agencies, with IBM, AWS and a busy Reddit thread alongside. Most explain the basics well, and most end with a quote form.
What they rarely cover is the decision before the build: whether you need an installed app at all, what the app stores demand every year, and who pays to keep an app alive after launch. Those questions decide more budgets than the choice of framework.
At Aptibit, we build mobile apps, web platforms and the systems behind them, so we have no reason to favour one approach. Our guides to custom software development and MVP development cover the wider build decision and how to scope a first release.
Mobile app development is the process of designing, building, testing and releasing software that runs on smartphones and tablets, most often on Apple's iOS and Google's Android. It covers the app people install, the backend services and APIs it relies on, publication through the App Store and Google Play, and the updates that follow.
A mobile app has three layers. The client is what people install and touch. The backend holds the data, business rules and accounts. The APIs are the contract between them, and most of the effort and risk sits in those last two. Our guide to API development covers that layer in depth.
There are four ways to put software in front of someone on a phone. Each wins in a different situation.
Native apps. Built separately for each platform: Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android. Native gives the deepest access to the device, the smoothest performance and the earliest access to new operating system features. The cost is two codebases, and often two teams. Native wins for demanding graphics, augmented reality, wearables and heavy background work.
Cross platform apps. One codebase, written with a framework such as Flutter or React Native, produces real installed apps for both iOS and Android, published through both stores. Cross platform app development wins for most business apps: field service, customer portals, booking, ordering and internal tools, where features and time to market matter more than platform specific polish.
Progressive web apps. A progressive web app (PWA) is built with web technologies but behaves like an installed app. It can be added to the home screen and work offline, with no store approval needed. Access to some device features and background work stays more limited than in a native app, especially on iPhone. A PWA wins when reach and speed of change matter most.
Responsive web apps. A website designed for any screen size. There is nothing to install, everyone is always on the latest version, search engines can index it, and changes go live the moment you release them. Responsive web wins for occasional use, self service tasks and any audience you reach through search or a shared link.
A useful test is frequency. Daily use in the field favours an installed app. Monthly use favours the web.
Both are mature frameworks that run production apps for very large audiences. The right choice depends mostly on your team.
Flutter is an open source framework, supported by Google, for building natively compiled apps for mobile, web, desktop and embedded devices from one codebase. Apps are written in Dart, and Flutter draws every pixel of the interface itself, which gives a consistent look on every device and fine control over custom, branded designs.
React Native was released by Meta in 2015 and has been maintained by it ever since. Teams write in JavaScript or TypeScript with React, and its components render to each platform's own native interface elements, so the app inherits the look and behaviour of iOS and Android.
Flutter tends to win when the design is highly custom, when the interface must look identical across devices, or when the product must also reach desktop or embedded screens. React Native tends to win when your engineers already work in React, when the app should feel native on each platform, or when you want to share logic with an existing web product.
Two cautions apply to both. Neither removes the need for native skills: Bluetooth, background location, payments and new operating system capabilities often need code written for each platform. And the choice is a long term commitment, because moving from one framework to the other is close to a rewrite. Choose the one your team can maintain for five years.
A mobile app is developed in seven stages, each producing something the next depends on. This is the mobile app development process we recommend.
1. Strategy and discovery. Define who will use the app, the job it does for them and how success will be measured. Decide here whether an installed app is the right answer at all.
2. Requirements and planning. Turn the strategy into a prioritised feature list, the integrations needed and a choice of approach and platforms. Agree what the first release contains, and what waits.
3. UX and UI design. Map the journeys, build wireframes and design screens to each platform's conventions. Test a clickable prototype with real users before any code is written.
4. Architecture and development. Build the backend, the APIs and the app in short cycles. Offline behaviour, sync and security are designed in here, not added later.
5. Testing and quality assurance. Test on real devices, across operating system versions, on poor networks, and against a security standard such as OWASP MASVS. Automate the tests that run on every change.
6. Launch and app store submission. Prepare store listings, privacy declarations and notes for reviewers, then release in stages, starting with test groups.
7. Maintenance and growth. Monitor crashes and performance, act on feedback, and keep pace with each year's operating system releases and store rules.
In our experience, rushing the first two stages is what most often leads to a rebuild.
A simple app can reach users in weeks. A complex enterprise app with many integrations takes months. The drivers are the number of user roles and journeys, the systems the app must connect to, offline sync, the number of platforms and how much backend already exists. Security reviews and compliance sign off take calendar time too.
Allow time for the stores. Apple says App Review typically handles at least 50% of submissions in under 24 hours and 90% in under 48 hours, but a rejection restarts the clock. On Google Play, personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers, opted in for at least 14 days, before releasing to production. A business should register as an organisation.
For reference, our own engagements follow a clear pattern. A focused proof of concept takes 2 to 4 weeks, and a full product typically takes 3 to 6 months, with a detailed timeline agreed before any work begins.
There is no honest single figure. Mobile app development cost is set by scope and risk, and two apps that look alike on screen can differ greatly in price. These drivers decide it.
Scope. The number of distinct journeys, user roles and business rules matters more than the number of screens.
Platforms. One platform, both through one cross platform codebase, or both built natively. Native on both costs the most.
Integrations and backend. Every connection to an ERP, CRM, payment gateway or identity provider adds work, and an app on existing, well documented APIs costs far less than one needing a new backend. This is usually where estimates slip.
Offline sync. Working without a connection, then resolving conflicts when the network returns, is one of the hardest problems in mobile engineering. Price it explicitly.
Security and compliance. Health, finance and government apps need stronger authentication, audit trails, penetration testing and documentation.
Design. Interfaces that follow platform standards cost less than a fully custom, animated brand experience.
Team location. Senior engineering at India cost levels sits well below US and Western European rates.
App stores and maintenance. Apple charges $99 a year for its Developer Program, and Google Play charges a one time $25 registration fee. The larger recurring cost is maintenance: operating system updates, security patches, SDK upgrades and hosting, every year the app is live.
Ask vendors to price these drivers separately. A quote that never mentions offline behaviour, integrations or maintenance is not cheaper. It is incomplete. Our guide to dedicated development teams compares ways to pay for the work.
Both stores review what you publish, and both raise the bar every year.
Apple reviews every app and update against its App Store Review Guidelines. Apple reports that over 40% of unresolved issues relate to guideline 2.1, App Completeness, which covers crashes, placeholder content and incomplete information. A finished build, a working demo account and clear notes for the reviewer prevent most of them.
Google Play sets technical floors as well as policies. From 31 August 2026, new apps and updates must target Android 16 (API level 36) or higher, and existing apps must target at least Android 15 to stay available to new users on newer devices. Apple is just as firm: since 28 April 2026, uploads must be built with Xcode 26 or later, using the iOS 26 SDK.
Apps meant only for your own staff can be distributed privately, and Google exempts permanently private apps of this kind from its target level rule.
Security in a mobile app is harder than on the web, because the app runs on a device you do not control. Anything shipped inside it can be extracted.
The OWASP Mobile Application Security Verification Standard (MASVS) is the industry's open reference for what a secure app must do. It groups its controls into eight areas: storage, cryptography, authentication and authorisation, network communication, platform interaction, code quality, resilience against reverse engineering and tampering, and privacy. In practice: no secrets inside the app, sensitive data in the platform's secure storage, and a server that treats every request from the app as untrusted.
Privacy law follows your users. India's Digital Personal Data Protection Act 2023 requires clear notice and, in most cases, consent before personal data is processed, and gives people the right to correct and erase their data. The EU's GDPR sets similar duties in Europe. Collect only what the app needs.
The stores enforce disclosure too. Apple requires every new app and update to declare the data it collects, including data collected by third party code such as analytics and advertising SDKs. Google Play requires every published app to complete a Data safety form, covering data handled through third party libraries. Both hold the developer responsible, so review every SDK before you add it.
Launch is the start of an app's working life, not the end of its cost. Apple and Google each ship a major operating system release every year, and both raise the minimum their stores accept.
Each year brings the same work: test on the new release, adopt the new SDK, update libraries, fix what broke, refresh privacy declarations and patch security issues. An Android app left alone for long enough stops reaching new users on newer phones.
Budget for this as a fixed annual line, and agree in the contract who does it. Add crash reporting and performance monitoring, so you know what to fix first.
ChatGPT and similar AI tools can help build an app, and can produce a working prototype. They cannot take responsibility for an enterprise product.
AI app builders such as FlutterFlow, Bubble, Lovable and Bolt turn a description into screens and working code quickly. That is excellent for testing an idea, a pitch demo or a simple internal tool. Professional engineers use assistants such as ChatGPT every day to write code and tests faster.
The gap appears where production begins: integration with your real systems, security against MASVS, offline sync, store compliance, privacy declarations, performance on modest phones and maintenance through each year's changes. Generated code still needs someone who understands it, owns it and answers for it. Use AI tools to test the idea. Use an engineering team that uses those tools well to build the product your business depends on.
App developers need a platform language, an understanding of mobile constraints, and the judgment to build secure, maintainable software.
That means Swift for iOS, Kotlin for Android, Dart for Flutter, or JavaScript and TypeScript for React Native. The core mobile app development tools are Apple's Xcode and Google's Android Studio, alongside each framework's own tooling. Around them sit API design, data sync, security, automated testing, accessibility and release management. Strong teams add product designers and quality engineers, and people who have kept apps working through several operating system releases.
Choose on evidence, ownership and fit, not on the lowest quote. Whether you are buying mobile app development services for a first release or a long term product, these questions separate a capable partner from a polished sales deck.
1. Which approach would you recommend, and when would you advise against an app? A good partner will sometimes tell you not to build one.
2. Can we meet the engineers who would build it, not only the sales lead?
3. How will you handle offline use, sync and integration with our systems? Vague answers here predict overruns.
4. Which security standard do you test against? Listen for OWASP MASVS.
5. Who owns the code, designs and store accounts? Insist on a signed IP assignment before work begins, code in repositories your organisation owns from the first day, and store accounts in your organisation's name.
6. How often will we see working software? Every two weeks is a sound rhythm.
7. What does maintenance cost after launch, and who does it? Get it in writing, priced per year.
Our guide to offshore software development services covers contracts, time zones and governance when the team works from another country.
Do not build an app because competitors have one. Build one when an installed app does something the web or a messaging channel cannot: daily use, offline work in the field, heavy use of the camera, location or Bluetooth, and reliable notifications.
For occasional use, a responsive web app often reaches more people at lower cost, because every installed app asks a person to find it, download it, sign in and keep it. For conversations, WhatsApp may be better still. In India and many other markets, it is already where people talk.
Project Sasha, the AI travel and lifestyle concierge we built for Kanoe in Spain, shows the alternative. People talk or type in any language, on the web or on WhatsApp, and Sasha plans whole trips across 350,000 places in Vietnam. Travellers reach it through a browser or a chat they already use, with nothing new to install.
Starting on the web and adding an installed app later for the most frequent users is often the path with the least risk.
At Aptibit, we build mobile apps for iOS and Android that work smoothly even offline, keep data in sync, send notifications and connect seamlessly to your systems. We also build the APIs and cloud infrastructure behind them, so app and backend are designed together.
Every engagement moves through discovery, strategy, design, development, testing and launch, then support and growth. Our product designers start with your users, through interviews, competitor reviews and usability testing, and every screen is approved before development starts. Quality is built in: peer review of every change, automated testing and releases, security testing before a staged launch, and monitoring once the app is live.
A focused proof of concept takes 2 to 4 weeks. A full product typically takes 3 to 6 months, and you see working software every two weeks. You get senior engineering at India cost levels, well below US and Western European rates, and everything we create, from code and designs to documentation, belongs to you under an IP assignment signed before work begins.
For Yatharth Educational Services, a team of 3 engineers delivered the website, an online exam platform and a management system for its schools and university in 6 months. And as Project Sasha shows, we will tell you when an installed app is not the best answer.
Mobile app development earns its place when people use the product often and on the move, and need what only an installed app does well: offline work, the camera, location, Bluetooth, fast access from the home screen and reliable notifications. Cross platform frameworks make apps for both platforms practical for most business budgets.
It disappoints when the app serves occasional use that a website would serve better, when integrations and offline sync are underestimated, when nobody owns maintenance through each year's operating system and store changes, and when downloads are mistaken for value. An app people install once and forget costs as much to maintain as one they open every day.
There is no honest single figure, because mobile app development cost is set by scope and risk. The main drivers are the number of user journeys, the platforms, integrations with existing systems, whether a new backend is needed, offline sync, security and compliance, design ambition, team location and yearly maintenance. Ask vendors to price each driver separately, and treat any quote that leaves out maintenance as incomplete.
A mobile app is developed by defining who it serves and what it must do, choosing an approach such as native or cross platform, designing and testing the screens with real users, building the app and its backend in short cycles, testing on real devices and against a security standard, submitting it to the App Store and Google Play, then maintaining it through each year's operating system updates.
The seven stages of app development are strategy and discovery, requirements and planning, UX and UI design, architecture and development, testing and quality assurance, launch and app store submission, and maintenance and growth. Each stage produces something the next depends on. Rushing the first two, where the users, scope and approach are decided, is what most often leads to an expensive rebuild later.
ChatGPT and AI app builders can produce a working prototype quickly, and engineers use AI tools every day to write code and tests faster. What they cannot do is take responsibility for a production app: integration with your systems, security, offline sync, store compliance, privacy declarations and yearly maintenance. Use AI to validate an idea, and an engineering team to build the product your business depends on.
Neither is better in general. Both are mature and used in large production apps. Flutter, supported by Google and written in Dart, draws its own interface and suits highly custom, consistent designs across many screens. React Native, maintained by Meta, uses JavaScript or TypeScript and renders native platform components, which suits teams that already work in React. Choose the one your team can maintain for years.
A simple app can reach users in weeks, while a complex enterprise app takes months. Timelines depend on the number of user roles and journeys, the systems the app connects to, offline sync, the platforms targeted and how much backend already exists. Allow time for store review too: Apple reviews most submissions within 48 hours, but a rejection restarts the clock.
App developers need a platform language: Swift for iOS, Kotlin for Android, Dart for Flutter, or JavaScript and TypeScript for React Native. They also need API design, data storage and sync, mobile security, automated testing, accessibility and experience releasing through the App Store and Google Play. Strong teams add product designers and quality engineers, and people who have kept an app working through several OS releases.
Build native when the app depends on demanding graphics, augmented reality, wearables, heavy background work or the newest operating system features on day one. Build cross platform with Flutter or React Native for most business apps, such as field service, customer portals, booking and internal tools, where one codebase for iOS and Android saves time and money without hurting the experience.
Yes. Aptibit builds mobile apps for iOS and Android that work smoothly even offline, keep data in sync, send notifications and connect seamlessly to your systems, with product design and user testing built in. A focused proof of concept takes 2 to 4 weeks and a full product typically 3 to 6 months. You see working software every two weeks, and everything we create belongs to you.