// 02 — mobile development
Apps that ship, and
keep passing review.
Building the app is the easy half. Getting it through store review, keeping it alive across OS upgrades, and making it usable on a four-year-old Android with two bars of signal — that is the work most estimates quietly omit.
// what we handle
End to end,
including the boring parts.
The parts that sink mobile projects are rarely the features. They are the release pipeline, the offline states, and the OS upgrade that lands two weeks after handover.
-
01
Cross-platform builds
One well-factored codebase for iOS and Android, with native modules written where performance genuinely demands them rather than as a matter of principle. Most business apps do not need to be fully native; the ones that do, we tell you.
- React Native
- Flutter
- Native modules
-
02
Offline-first data
Assume the network will fail, because in most of India it will. Local persistence, an outbox for queued writes, conflict resolution, and a UI that tells the truth about what has actually synced.
- Local persistence
- Sync queue
- Conflict handling
-
03
Push, deep links and notifications
Segmented push that respects quiet hours, deep links that survive a cold start, and notification payloads that route to the right screen with the right state rather than dumping the user on a home tab.
- FCM / APNs
- Deep links
- Segmentation
-
04
Payments and subscriptions
In-app purchase and subscription flows that reconcile against your own backend, so a refund, a chargeback or a family-sharing edge case does not leave your database disagreeing with the store.
- In-app purchase
- Reconciliation
- Receipts
-
05
Store submission and release
Signing, provisioning, privacy declarations, store listings, phased rollout and the review rejections that follow. We have been through the rejection loop enough times to design around it in advance.
- App Store
- Play Store
- Phased rollout
// the honest part
When you should not build an app.
A surprising number of the mobile enquiries we receive should be a responsive web application instead. If your users open the thing twice a month, will not grant notification permission, and you have no offline requirement, an app mostly buys you an install barrier and two more release pipelines to maintain.
We will say so. It costs us a bigger project and saves you a budget, and it is the reason a fair share of our work arrives by referral.
Where an app genuinely earns its place — daily operational use, offline requirements, camera and scanner workflows, real push-driven engagement, hardware access — we build it properly and stay on through the first few store cycles.
// straight answers
Questions we get
every week.
React Native or Flutter — which do you recommend?
React Native if you already have a React and TypeScript codebase, because the team and the types carry across. Flutter when the UI is highly custom and pixel-consistency across platforms matters more than sharing code with the web. We will recommend one after hearing what already exists in your organisation.
Do you handle the App Store and Play Store accounts?
We can publish under your developer accounts, which is what we recommend so you own the listings, or guide your team through setup. Signing keys and credentials stay yours throughout.
What happens when iOS or Android ships a breaking change?
Under a retainer we track OS betas and keep the app compliant ahead of deadlines. On a fixed-scope project we tell you at handover which upcoming platform changes will need attention and roughly when.
Can you take over an existing app?
Yes. As with web work we begin with a read-only audit of the codebase, its dependency and signing state, and its store standing, then give you a written plan before changing anything.
// next step
Tell us what is actually broken.
A short message is enough to start. The first scoping call is free, and you will be talking to the person who would write the code.