Flutter app development
Most of our app work is in Flutter. We build one codebase for both stores, add AI features, subscriptions, ads and sign-in where your app needs them, and write native code for the few parts Flutter can't do well.
We build Flutter apps all the way to a live listing on Google Play and the App Store. The Flutter apps we've shipped include AI features, RevenueCat subscriptions, AdMob ads and Firebase sign-in, so we already know where those parts break.
A typical delivery includes:
Examples of the kind of app we mean (these are examples, and none is a past project): an AI app that turns a typed request into a finished document, with a free daily allowance and a subscription for unlimited use; a booking app for a salon or tuition centre with reminders and a staff view; a content app with ads for free users and none for subscribers.
The app never holds the AI provider's key. It calls a backend, and the backend picks the model, so you can switch models without an app update. The app asks for structured JSON and checks every field before showing anything. A generation counts against a user's allowance only after the result has arrived and been saved, so a dropped connection never costs the user a generation.
We use RevenueCat with one "premium" entitlement, a restore button on the paywall, and the purchase tied to the user's account so it follows them to a new phone. The app waits for the subscription status before deciding anything. We learned that from a bug: a rewarded ad finished loading before the subscription status arrived, and a paying subscriber was asked to "watch an ad to download". Premium is now checked when the ad loads and again at the moment it would show.
Debug builds only ever request Google's test ads. Google warns that clicking too many live ads outside test mode can get the account "flagged for invalid activity" (AdMob docs, checked 1 November 2026).
Every native ad has a visible "Ad" label and its own background and border. That rule came from an AdMob policy notice about native ads that looked too much like the app's own cards. The native ads policy asks for the text "Ad", "Advertisement" or "Sponsored" on each one, at least 15px, and says ads "must be clearly distinguished from content" (checked 1 November 2026).
New users start as guests, and signing in with Google or email links the guest account, so nothing is lost. Account deletion works in the app and from a web page, because Google Play asks for both an in-app path and a web link (Play Console Help). Google Sign-In fails in production until the Play App Signing key's SHA-1 fingerprint is added to Firebase, a detail that can break a first release.
New apps and updates on Google Play must target Android 16 (API level 36) (Play Console Help). Apps that generate content with AI "must contain in-app user reporting or flagging features" (Play policy), so the report button goes in from the start. Both checked 1 November 2026.
Flutter is the right call when most of your app is screens, forms, payments and calls to a server, which covers most business apps. Native code is needed when the hard part lives in the phone's own media or audio engine, or on a surface Flutter can't draw. We're a Flutter-first studio, so weigh this knowing our preference.
| What your app mostly does | What we would build | Examples |
|---|---|---|
| Screens, accounts, payments, AI calls to a server | Flutter only | Booking, marketplace, content and AI generation apps |
| Screens, plus one thing only the platform does well | Flutter with a small Kotlin or Swift module, or a C library through Dart FFI | Low-latency audio, a home screen widget, a device API with no maintained plugin |
| Real-time video or audio processing, often on one platform | Native Kotlin or Swift | An Android video editor |
Flutter talks to Kotlin and Swift through platform channels, and to C libraries through dart:ffi. A small real case: to enforce a free allowance per device on Android, one of our apps needed a stable device ID. The id that the popular device_info_plus plugin returns on Android is the firmware build label ("a label like M4-rc20"), shared by every phone of that model and firmware. So the app reads Settings.Secure.ANDROID_ID through a few lines of Kotlin instead.
Home screen widgets are another: "you can't directly draw the UI of a Home Screen widget using the Flutter framework" (Google codelab), so we would write the widget in SwiftUI and Kotlin.
A keyboard instrument app we built uses Flutter for every screen, but its sound comes from SoLoud, a C++ engine, through the flutter_soloud package. What that build taught us:
When we built an Android video editor, we wrote it in Kotlin on Jetpack Media3 instead of Flutter, because the whole product is the media engine. Media3's CompositionPlayer previews the same composition that Transformer exports, and Transformer runs on Android's hardware codecs and OpenGL (Android docs). When that much of an app lives in Android's media libraries, a Flutter layer adds a bridge without removing any Kotlin. Two lessons from that build:
Our rule: if your app mainly shows screens and talks to a server, choose Flutter. If it processes video or audio in real time, ask which parts will be native before you agree a plan. If it needs fully native builds on both platforms, see mobile app development.
If you already have a Flutter app and need more hands on it, you can hire our Flutter developers on a monthly retainer instead of a fixed-scope build. The same engineers work on your app every month, in your repository and your issue tracker, and join your calls in the hours that overlap with yours. The work is what a Flutter app needs after launch: new features, upgrades to new Flutter and SDK versions, store releases and fixes. Everything we write stays in your repository. For a wider team that also covers web, backend or AI work, see hiring developers in Pakistan.
Already have a finished app? Our launch and store setup work covers signing, listings, review and release on its own. To keep shipping after launch, the monthly product retainer keeps the same engineers on your app.
You own the code, the store accounts and the cloud accounts from day one:
To publish under a company name, both stores ask organisation accounts for a D-U-N-S number (Google, Apple), so start that early. Your written agreement sets out ownership in full; this page is a summary, not legal advice.
Your written plan gives real dates for each milestone once we've seen the scope. A tightly scoped first version is built in weeks.
What moves the date: each extra kind of user (customer, staff, admin), AI features tested on real inputs, subscriptions on both platforms, native modules tested on real devices, and how quickly your side tries each weekly build.
Two store steps nobody can speed up:
Pakistan Standard Time is UTC+5 all year, with no daylight saving (PKT). Our hours are Monday to Friday, 10am to 7pm PKT (05:00 to 14:00 UTC). Against a 9am to 5pm day:
| Where you are | Our hours in your winter time | Overlap in winter | Overlap in summer time |
|---|---|---|---|
| London | 5am to 2pm | 5 hours | 6 hours |
| Berlin, Paris | 6am to 3pm | 6 hours | 7 hours |
| Dubai | 9am to 6pm | Full day | Full day (no clock change) |
| Riyadh | 8am to 5pm | Full day | Full day (no clock change) |
| New York | Midnight to 9am | None | 1 hour |
For US clients we also take calls from 6pm to 10pm PKT (13:00 to 17:00 UTC), Monday to Friday. In New York that's 8am to 12pm in winter (EST) and 9am to 1pm in summer (EDT).
The Gulf gets a full shared day, the UK and Europe most of one. With the US, live calls and urgent replies happen in your morning, through that 6pm to 10pm PKT window, alongside the weekly build and a short written update. If you need live calls outside that window, say so on the scope call and we'll tell you whether we can do it.
We reply to email and the contact form within one business day, and we're on WhatsApp at +92 308 6475141. The people on the calls write the code. For a team on your product month to month, see hire developers in Pakistan.
We don't publish a price list. After the scope call you get a fixed written plan with the price and dates for each milestone. Cost moves with the same things as the timeline. On top of the build, budget for the store fees above and the running costs of the services in your accounts, such as Firebase and AI usage.
For most business apps, yes. Flutter draws its own interface, and where the phone's own frameworks do the work, such as widgets or real-time media, we write that part natively.
Both ship good apps. We recommend Flutter for new apps because that is where our depth is. If your team writes React and will maintain the app itself, React Native may suit you better, and it's in our stack too.
Yes. We read the code, run the analyzer and existing tests for a baseline, and follow the patterns already there instead of rewriting. Each bug we fix is reproduced from the logs first and gets a test named after it.
Yes, through a backend, so the provider key never ships inside the app. For chatbots that answer from your own documents, see AI chatbot development.
Within one business day, Monday to Friday, 10am to 7pm PKT (UTC+5). Tell us what you're building and we'll start with the scope call.
Building apps1 November 2026
Flutter vs React Native for founders: our decision rules, why Google calls the React Native Firebase and AdMob libraries unofficial, update costs and our Flutter bias.
Contact
Tell us about the problem in a few lines. An engineer will reply, usually within one business day.