AmwerahSolutions
Build · Services

Mobile app development

The cross-platform question is usually asked backwards. It is not “can React Native do this”, because it nearly always can. It is “what does this app do when the phone has no signal, the battery is at four percent, and the user is standing in a warehouse”.

Choosing the approach, honestly

React Native is the right answer for most business applications: apps that are screens, forms, lists and a camera. One codebase, one team, one release process, and a hiring pool that overlaps with your web developers. We use it by default and we are not embarrassed about it.

Native is the right answer when the app is doing something the platform is specifically good at — sustained background location, heavy on-device media processing, deep integration with platform payment or health frameworks, or an interface that must feel exactly like the operating system it is on. Flutter sits in between and wins when the interface is entirely custom-drawn and must be pixel-identical on both platforms.

What we will not do is recommend the approach that suits our staffing rather than your app. If your project genuinely needs native iOS, we will tell you that, and we will tell you what it does to the budget.

The parts that are always underestimated

Offline behaviour. Not caching — actual conflict resolution, when two devices edited the same record while both were disconnected. Someone has to decide what wins, and that decision is a business rule, not a technical one.

App store review. Both stores will reject a build for reasons that are not in your plan, and the first submission of any app should be assumed to fail. We budget for it rather than being surprised by it.

And release management. A web bug is fixed in twenty minutes. A mobile bug is fixed in twenty minutes and then waits two days for review, during which every user still has the broken version. That changes how much testing is worth doing before you ship, which is why we wire over-the-air updates for the JavaScript layer where the platform rules allow it.

Built for real conditions

We test on cheap Android devices on throttled connections, because that is what a large share of Indian users are actually holding. An app that is smooth on the latest iPhone and unusable on a three-year-old budget Android has not been tested, it has been demonstrated.

Battery and data usage are treated as features. A logistics app that drains a driver’s phone by lunchtime does not get used, whatever its feature list says.

Capabilities

What this actually covers

  • React Native apps

    One codebase across iOS and Android for apps that are screens, forms, lists and a camera — which is most business apps.

  • Native iOS and Android

    Where the platform is doing the heavy lifting: background location, on-device media, platform payment and health frameworks.

  • Flutter

    For custom-drawn interfaces that must be identical on both platforms, with one rendering model to reason about.

  • Offline-first sync

    Local-first storage with an explicit conflict resolution policy, because “last write wins” is a business decision in disguise.

  • Store submission

    App Store and Play Console setup, review responses, staged rollouts and the privacy declarations both stores now require.

  • Release engineering

    Automated builds, internal test tracks, crash reporting and over-the-air updates where the platform rules permit them.

How it runs

The sequence

Same shape on every engagement, so you always know what week you are in and what happens next.

  1. Decide the platform approach

    A short written assessment of React Native against native against Flutter for your specific app, with the cost and hiring consequences of each. This is the cheapest decision to get right and the most expensive to reverse.

  2. Prototype the hard part first

    Whatever is riskiest — the sync model, the scanner throughput, the background location — gets built first as a throwaway, before the schedule depends on it working.

  3. Build against real devices

    Cheap Android hardware on throttled connections is part of the test matrix, not an afterthought. So is a phone at four percent battery.

  4. Beta, then staged rollout

    TestFlight and Play internal testing with real users before public release, then a staged rollout so a bad build reaches one percent of users rather than all of them.

What you get

Handed over, in your accounts

Not a demo and a login. These are the artefacts you keep, and they are what makes leaving us possible.

  • Signed builds on both stores, published under your own developer accounts
  • An automated build pipeline, so a release does not depend on one person’s laptop
  • Crash and performance reporting wired before the first public release
  • An offline and sync policy written down, not just implemented
  • Store listing assets, screenshots and the privacy declarations both stores require
  • Source, signing keys and store account access handed over in full

Typically built with

  • React Native
  • Expo
  • TypeScript
  • Swift
  • Kotlin
  • Flutter
  • SQLite
  • Firebase
  • Fastlane

The selection principle is deliberately dull: largest hiring pool, longest support window. See why we choose these.

Questions

Mobile Apps, answered

The things people ask on the first call, written down so you do not have to.

All twenty questions
React Native or native — which does my app need?

React Native, unless there is a specific reason otherwise. It is the right call for apps built from screens, forms, lists and a camera, which covers most business and marketplace apps, and it halves your ongoing maintenance because there is one codebase rather than two. Go native when you need sustained background execution, heavy on-device media processing, deep platform framework integration, or an interface that must feel native down to the scroll physics. We give you this assessment in writing during discovery, before any budget is committed.

How much does it cost to build a mobile app in India?

A genuine minimum viable product with authentication, a handful of core screens, a backend and both stores handled is usually a three to five month engagement. The wide range you see quoted online is mostly a difference in what is included: many low quotes exclude the backend, the admin panel, store submission, and any offline behaviour — which is to say, they exclude the parts that take the time. We quote after discovery with those line items visible, so you can compare like with like.

Do you publish the app under your account or ours?

Yours, always. You own the Apple Developer and Google Play accounts, the signing keys and the listings. This matters more than it sounds: an app published under an agency account is extremely painful to move later, and it gives the agency a veto over your product. We will help you set the accounts up if you do not have them.

What happens after the app is launched?

Both platforms ship a major OS release every year, and each one breaks something — a permission model changes, a library goes unmaintained, a store policy tightens. An app with no maintenance budget is a depreciating asset. We usually propose a small monthly retainer that covers OS compatibility, dependency updates, store policy changes and crash triage, separate from any new feature work so the two are not competing for the same money.

Can you work on an existing app rather than building a new one?

Yes. It starts with an assessment: reading the code, checking dependency health and store compliance, and finding out what is load-bearing. Sometimes the answer is that the app is fine and it needs three specific fixes. Sometimes it is that the dependencies are four years unmaintained and the honest recommendation is a rebuild of the shell around the existing business logic. You get that assessment in writing before we propose any work.

Thinking about mobile apps?

Start with a call rather than a brief. Thirty minutes, no deck, and an honest answer about whether we are the right people for it.