Mobile App Development
Flutter app development and native builds for iOS and Android, taken from scope through store approval rather than handed over at the code.
- Six years building software
- iOS and Android app development in-house
- Your code, your developer accounts, from day one
An app is a commitment, not a project. Two app stores, two review processes, and a yearly compliance deadline that removes you from search if you miss it. HelloDevs builds mobile apps and keeps them in the stores afterwards. The first honest question is always whether you need one.
Do you need an app, or a better website?
Do you need an app, or a better website?
An agency selling apps will always say yes. Here is the version that saves people money. Send how it would be used, not the feature list — a reasonable share of these conversations end with a recommendation to improve the website instead.
| How it would be used | Usually the right answer |
|---|---|
| Opened once a month, mostly to look something up | A fast responsive website. |
| Opened several times a week by the same people | An app. |
| Needs to work with no signal, or patchy signal | An app — offline data is the clearest reason to build one. |
| Needs the camera, precise location, or barcode scanning | An app. |
| Your field staff are away from a desk all day | An app, connected to the system you already run. |
| Push notifications are the main reason | Ask what the app does on the days you send nothing. |
| Because competitors have one | No. |
| To be seen in the app stores as a marketing channel | No. There are millions of apps in each store and almost no discovery for new ones. |
Four kinds of mobile app development
HelloDevs takes on these four. The differences matter more to the budget than the platform choice does.
Flutter, native, or neither
Flutter, native, or neither
Most iOS and Android app development now happens on a cross-platform framework, and for the majority of business apps that is the correct call. The performance argument that used to settle this has largely gone quiet. Any agency that recommends the same framework to every client is describing its team, not your app.
- Flutter — the default hereOne codebase, both platforms, one team. Flutter renders its own interface, which means the app looks identical on iOS and Android and handles heavy animation well — it also reaches web and desktop from the same codebase when that becomes useful. Flutter app development is what our own platforms run on, so it is the framework HelloDevs knows deepest rather than the one that happens to be fashionable.
- Native Swift or KotlinWorth the extra cost when the app leans hard on platform features, needs a new OS capability the moment it ships, or does heavy graphics, video or sensor work. Two codebases and two skill sets, so roughly the double cost the saving on cross-platform is measured against. A useful rule: if you cannot name the specific platform feature that requires it, you probably do not need it.
- The honest trade-offCross-platform saves a meaningful share of the cost of building two separate native apps — most estimates put it between a third and a half. What you give up is a small amount of platform-native feel and the very newest OS features arriving a little later. For a typical business, commerce or content app, users will not notice. For a product where the interface is the product, they might.
Getting through App Store and Play review
Getting through App Store and Play review
Most apps get rejected at least once, and almost all of it is preventable. These are the things reviewers actually stop. HelloDevs submits, handles the review correspondence, and resubmits if needed — a rejection becomes our week rather than your delay.
- No demo loginIf your app needs an account, reviewers need working credentials in the review notes. A login they cannot use restarts the clock.
- Missing or thin privacy declarationsApple requires a privacy manifest declaring what data is collected, which third-party SDKs are used, and why each sensitive API is needed. Google requires a matching Data Safety form. A declaration that contradicts what the app actually does gets rejected even when the form is complete.
- Payments handled outside the storeDigital goods and subscriptions have to use the platform's own purchase system. External payment links for digital items are a fast rejection.
- AI features with no consent screenIf the app sends personal data to a third-party AI provider, Apple requires a consent screen naming the provider and the data shared. This rule is recent and catches teams who added an AI feature late.
- Permission prompts with no explanationEvery sensitive permission needs a human-readable reason. "This app needs camera access" is not one.
- Anything unfinishedReviewers press every visible button. Placeholder text, dead links and half-built screens all fail.
- Crashes on first launchUsually a device or OS version the team never tested.
The deadline most app owners miss
Reviewed for the cycle ending 31 August 2026 — re-verify against Play Console Help before the next annual deadline.
The deadline most app owners miss
Google Play runs a rolling annual requirement on the Android version an app targets. Miss it and the app does not break — it quietly stops appearing for new users. As of the current cycle, the deadline is 31 August 2026, with an extension to 1 November 2026 requestable through Play Console — re-verify this date before quoting a build, it moves every year. If your app has not shipped an update in a year, this is worth checking today rather than at the deadline.
- How the rule worksEvery Android app declares a target API level, and Google Play requires that level to stay recent. New apps and any update must target Android 16 (API level 36) — submissions below that are rejected in Play Console. Existing apps you are not updating must target at least Android 15 (API level 35), or the app stops being discoverable to anyone on a newer Android version. Wear OS, Android TV, XR and Automotive each carry their own lower thresholds.
- What it actually looks like when you miss itNothing appears broken. Everyone who already has the app keeps it. But a new customer on a recent phone searches the store and finds nothing, or is told the app was built for an older version of Android. Install numbers fall, the drop-off appears at the app step, and nothing in the code hints at why — it hits growth rather than existing users, which is exactly why it goes unnoticed.
- The part that catches teams outYour own code is rarely the problem. Third-party libraries also have to support the new target, and if one has not released a compatible version you are blocked — waiting on the maintainer, patching it yourself, or replacing it. That is a discovery worth making months before a deadline rather than in the final fortnight.
- Apple's version of thisApple does not run the same rolling target rule, but it does raise the minimum Xcode and SDK version required for submissions, and adds privacy requirements between releases. The practical effect is the same: an app left untouched for long enough cannot be updated without work first.
What an app costs to keep alive
What an app costs to keep alive
The part most mobile app development quotes leave out, and the reason apps get abandoned rather than retired. Budget for this at the start and an app is a good investment — ignore it and the app becomes undownloadable in about two years, which is the most common way apps die.
- A yearly release minimumWhether you changed anything or not. Between the Android target requirement and Apple's SDK floor, a compliance release is unavoidable.
- Developer accountsApple charges an annual developer fee; Google charges a one-off registration. Both must stay in your name.
- OS releases break thingsTwo major OS versions a year, each with behaviour changes that surface in ways testing did not predict.
- Dependency updatesLibraries age, and security patches are not optional.
- Store metadataScreenshots need redoing when device sizes change; privacy declarations need updating when you add an SDK.
- Support has a floorEven a small user base generates questions, and app store reviews are public.
What you get
What comes with the build
Included in every HelloDevs quote. Anything an agency leaves out here comes back later as a change request.
- Scope documentWhat is being built, what is not, and what it costs to run.
- The app itselfFor iOS and Android, tested on real devices rather than simulators alone.
- Backend and APIWhere the app needs one, or integration with the system you already run.
- Store listingsScreenshots, descriptions and metadata written for store search.
- Privacy declarationsApple's privacy manifest and Google's Data Safety form, matched to what the app actually does.
- Submission handledIncluding review correspondence and resubmission.
- TestFlight and Play testing tracksSet up so your team sees builds during the project.
- Crash reporting and analyticsConfigured before launch.
- DocumentationHow it works, how to release it, how to change it.
- Source code and accountsIn your repository and your name from the first commit.
- Running cost estimateIncluding the yearly compliance release.
- 30 days of post-launch fixesIncluded, not billed.
How a build runs
Six steps, tested on real devices
Installable builds on TestFlight and a Play testing track every week, not a demo at the end. Simulators hide most of what actually goes wrong.
- Use-case callHow the app will actually be used, by whom, and how often. If the honest answer points to a website, that is what you will hear.
- Fixed scope and priceIn writing, with the exclusions stated as clearly as the inclusions, and the yearly running cost included.
- Build in weekly cyclesInstallable builds on TestFlight and a Play testing track every week, not a demo at the end.
- Real-device testingOlder phones, small screens, poor connections. Simulators hide most of what actually goes wrong.
- Submission and launchWe handle both stores and the review correspondence. Plan two to four weeks between finished code and being live.
- AfterwardsThirty days of fixes included, then a maintenance arrangement if you want one. No lock-in either way.
Our stack
Pure-play Shopify developers
We develop only for Shopify. No bloated frameworks, no visual page builders that degrade site performance, and no subcontracting. Just clean, hand-crafted code.
The Mobile Stack
Listed because technical buyers ask, and because a vague answer here usually means the work is being passed to someone else. Flutter and Dart for cross-platform — the default for most projects here. Swift for iOS and Kotlin for Android where the product genuinely needs native. Nothing is subcontracted: the people on the first call are the people writing the code.
- Flutter
- Dart
- Swift
- Kotlin
- Node.js
- PostgreSQL
- Stripe
- lib/screens/home_screen.dart01
- lib/services/api_client.dart02
- ios/Runner/PrivacyInfo.xcprivacy03
- android/app/build.gradle04
One API, Both Platforms
Node.js, TypeScript, REST and GraphQL APIs, PostgreSQL, MongoDB, Supabase — the same backend a Flutter app and its web counterpart both call.
final res = await api.get(
'/orders',
auth: token,
);No Subcontracting
Nothing is subcontracted. The people on the first call are the people writing the code, on both the app and the backend behind it.
offshore-handoff.zip
Real Store Pipelines
Xcode and App Store Connect, Android Studio and Play Console, TestFlight and internal testing tracks, with automated builds where the release cadence justifies it.
BuildSubmit
Mobile app development questions
- An app attached to a system already being built adds four to eight weeks. A standalone app with its own backend takes three to five months, including submission. Store review adds one to three weeks on top and often needs a second attempt, so that time is built into the schedule rather than discovered at the end.
- Flutter for most projects — one codebase, both platforms, and it is what HelloDevs uses on its own products. Native is worth the extra cost when the app depends on platform features, needs new OS capabilities immediately, or does heavy graphics or sensor work. If you cannot name the feature that requires native, you probably do not need it.
- A responsive website usually wins if people would open it occasionally. An app earns its cost when usage is frequent, needs to work offline, or needs the camera, precise location or barcode scanning. If push notifications are the only reason, ask what the app does on the days you send nothing.
- Most often a missing demo login, privacy declarations that do not match what the app does, payments for digital goods handled outside the store's own system, unexplained permission prompts, or unfinished screens. Nearly all of it is preventable, and a first rejection is normal rather than a warning sign.
- Usually days rather than weeks for Apple, though a rejection and resubmission can stretch it to two or three weeks in total. Google Play can take longer for new developer accounts, which have an additional testing requirement before a first public release. Plan two to four weeks between finished code and being live.
- More than most people expect, and not because of bugs. Google Play requires apps to keep targeting a recent Android version and Apple raises its submission requirements between releases, so a compliance release every year is unavoidable even with no new features. Developer account fees, OS updates and dependency patches sit on top.
- It stops being downloadable for new users on newer devices. Existing users keep it, so nothing looks broken from the inside — but installs quietly stop, and the app effectively disappears from the store for anyone new. This is the most common way apps die.
- Often yes, and the code gets read before anything is quoted. You get a written assessment covering the state of the code, the target API level, the dependency list and whether finishing is faster than rebuilding. Sometimes it is the rebuild.
- Yes, completely. The repository is yours from the first commit, and the Apple Developer and Google Play accounts are registered in your name rather than ours. If you stop working with HelloDevs, nothing about your app depends on us.
- Yes — that is the most common shape of app work here. The app talks to your existing platform, ERP, CRM or store through an API. If there is no API yet, building one is part of the scope.
- Yes, and it is often the better option. Internal apps can be distributed privately to your own team rather than published publicly, which removes most of the store review process and all of the discovery problem.
- Yes. A mobile app can read products, collections and orders through Shopify's APIs — see Shopify app development for apps that live inside Shopify admin, which is a different job from a customer-facing mobile app.
Tell us how it would be used
Not the feature list — how people would actually use it, and how often. A developer at HelloDevs replies within one business day, including if the answer is that a website gets you there.
Our talk
Tell us how it would be used
Not the feature list — how people would actually use it, and how often. A developer at HelloDevs replies within one business day, including if the answer is that a website gets you there.
