Mobile apps
We've shipped Flutter and native Android apps for 5+ years — marketplaces, fintech features, media tools, and everything between.
A mobile app is the only software your client ships that a stranger can reject before anyone uses it. Two app stores review it, two operating systems keep changing underneath it, and every user runs a different version on a different device. Writing the screens is the part everyone plans for; the rest is what decides whether the app is still healthy a year later.
We work primarily in Flutter, because one codebase compiling to genuinely native iOS and Android builds removes an entire duplicate workstream — the same reason it was the right call for Task City, a gamified rewards app with a server-validated coin ledger that has been live on Google Play and iterating in production since early 2025. Where a product leans hard on platform APIs, we write native Android in Kotlin instead of pretending a plugin exists.
And we handle the unglamorous half: release signing, staged rollouts, store review policies, crash reporting, and the OS upgrade that lands every autumn whether or not the roadmap has room for it.
A production Flutter app where trust, fraud resistance, and store compliance were the hard requirements.
Platform choice
This is the first question on every mobile project, and the honest answer changes with the product.
Most products. You get iOS and Android from one codebase, one test suite, and one set of bug fixes. Business logic, networking, and state are written once. For anything that is fundamentally screens over an API — marketplaces, booking, social, rewards, internal tools — the platform difference is invisible to users and the saving is roughly a second team.
Deep platform integration is the tell: background services with aggressive scheduling, custom camera pipelines, widgets, accessibility services, tight hardware or SDK work with no maintained plugin. Here a Flutter wrapper becomes a permanent tax, and Kotlin is simply cheaper to own.
A Flutter app can call native code through platform channels, so an otherwise cross-platform product can drop to Kotlin for the one feature that needs it. This is common and it is not a compromise — it is the reason the boundary exists.
We do not have a house answer we sell regardless of the question. If your product genuinely needs two native teams, that is what we will tell you, even though it is not work we would be doing.
Project fit
Engagement
You get an installable build early and keep getting one, so "how does it feel" stops being a hypothetical.
Screens, platforms, integrations, and the store requirements that apply to your category — some of which change what gets built.
Project setup, navigation, state management, and the data layer. Unglamorous, and the part that decides how the next two months go.
Weekly builds distributed to your device through TestFlight and Play internal testing. You use the app on real hardware, not in a video call.
Offline behaviour, error states, crash reporting, performance on mid-range devices, and store compliance review.
Signing, listings, screenshots, phased rollout, and the review back-and-forth — then monitoring once real users arrive.
Store review is the one step nobody controls, and it is where optimistic timelines usually break. We scope it as a range, submit early, and handle rejection correspondence ourselves — it is a routine part of the job, not an emergency.
If the app is the first version of a new product rather than an addition to an existing one, this usually runs inside a wider MVP development engagement — same weekly rhythm, wider scope. Either way the working style is the one described on our about page: small pods, weekly demos, and bad news early.
The device on a developer's desk is not the device your users have. We profile on mid-range Android hardware, watch frame rendering rather than trusting a smooth emulator, keep app start work off the critical path, and size images for the screen instead of the source file. Battery and data use get the same attention, because both show up in reviews long before they show up in metrics.
An installed app can be decompiled, and anything valuable it can claim, someone will try to claim falsely. So privileges live on the server: rewards, purchases, and balances get validated server-side before they count — the pattern behind Task City's transaction ledger, where every reward is its own record rather than a mutable number a client could edit. API keys stay out of the bundle where the platform allows it, tokens are stored in the OS keystore, and permissions are requested at the moment they are used and explained when asked for.
iOS and Android both ship a major version every year, and stores raise their minimum target SDK on a published schedule. An app that is not updated does not stay still — it stops being installable. We keep dependencies few and current, keep business logic out of widgets so it can be tested without a device, and document the release process so a new developer can ship a build on their first week.
Most mobile clients continue on a monthly retainer, because mobile is the one platform where standing still is a decision with a deadline. It covers OS and SDK updates, store policy changes, crash monitoring, and new features. Taking a clean handover to your own team instead is equally fine — the runbook is written for exactly that.
FAQ
One codebase compiles to real native apps on both platforms, so you write business logic, networking, and state once and fix bugs once. For the large majority of products the result is indistinguishable from native to users, at roughly the cost of a single team. It has been our daily driver for over five years.
By what the product actually touches. If it is screens over an API, Flutter wins on cost and speed. If it depends on deep platform integration — background scheduling, custom camera pipelines, widgets, accessibility services, or an SDK with no maintained plugin — we build native Android in Kotlin. Mixed builds using platform channels are common and perfectly normal.
We build for iOS through Flutter, which produces a native iOS binary and covers the vast majority of products well. Native Android in Kotlin and Java is a service we offer directly; deep native iOS work in Swift is not, and we will say so rather than stretch.
Yes — store listings, screenshots, signing, phased rollouts, and the review correspondence including rejections. It happens under your Apple and Google accounts, not ours, so ownership of the listing never has to be untangled later.
It is a routine part of publishing rather than a crisis. We read the reviewer's citation, work out which guideline is actually at issue, make the change, and resubmit with an explanation. Categories with stricter tracks — cash rewards, fintech, health — get their requirements built in from scoping, because retrofitting compliance is expensive.
Yes, and it is a common engagement. We start with an audit of the codebase, dependency health, crash data, and store standing, then give you an honest read on whether it is better to repair or rebuild — including when the answer is repair and the smaller invoice.
For anything used on a commute or in the field, the local database is treated as the source of truth the user interacts with, with sync reconciling in the background and conflict rules decided during scoping. Designing this in from the start is straightforward; adding it to a finished app rarely is.
You do. Apps are published under your Apple Developer and Google Play accounts, and signing keys and keystores are transferred to you with recovery notes. A lost signing key cannot be regenerated — it is the one asset in a mobile project with no backup path, so we make sure it is in your hands.
OS releases, store policy changes, minimum SDK deadlines, dependency updates, crash monitoring, and new features. Mobile is unusual in that skipping maintenance eventually makes an app uninstallable rather than merely dated, which is why most clients keep a retainer running.
Yes — on-device ML and LLM-backed assistants are a frequent addition to Flutter builds. That work is described in more detail on our AI-powered app development page.
Next step
Tell us about your product. You'll get a straight answer on approach, timeline, and cost — usually within 24 hours.
