Skip to content
PRS India

iOS, Android and cross-platform

Mobile App Development

Flutter, React Native and native apps that keep working offline, on old phones and on a metro platform with one bar of signal. We put them in both stores, with a release pipeline that you own.

Last updated

  • Offline-first sync with safe write queues and a clear rule for clashing edits
  • Cold start under 2 seconds on a 3GB Android device
  • Automated builds to TestFlight and the Play Console on every merge
  • Crash-free sessions above 99.5% before we call it launched
What this is

Built for the phone your customer actually owns.

An app is not a website in a frame. It is software that has to work on a five-year-old Redmi with 3GB of RAM. It has to work on the Delhi Metro, where the network drops between Rajiv Chowk and Barakhamba. And the user decides in about eight seconds whether to keep it or delete it.

We build mobile products for teams who have a real reason to be on the home screen. Examples are a delivery fleet that works offline, field-service work with a camera and a signature, a members app where push is the main channel, and a fintech flow that has to pass an RBI audit. If your users would be just as happy with a good mobile site, we will tell you so. That saves you a year of app-store upkeep.

Cross-platform by default, native when the hardware needs it. Flutter and React Native cover most of what people ask us for. They do it with one codebase, one release flow and one set of tests. Sometimes you need Bluetooth Low Energy, an SDK that only comes for iOS, background location that has to survive Doze mode, or 120fps drawing. Then we write native modules, or the whole app in Swift and Kotlin. We tell you so before you sign.

  • Cross-platform first. Native modules only where the hardware needs it
  • Offline-first design, not something added at the last minute in month five
  • Store submission, signing and automatic releases handed over to you
The first decision

Flutter, React Native or native — honestly.

  Flutter React Native Native (Swift / Kotlin)
One codebase, both stores Yes Yes No
Performance on 3GB Android Excellent Good Excellent
Custom, brand-heavy interfaces Excellent Good Excellent
Shares code with a React web app No Yes No
Deep hardware and BLE work Via native modules Via native modules Native
Hiring pool in India Large and growing Very large Smaller, pricier
Typical cost vs native ~60% ~65% Baseline
Where apps break

The failures we are hired to fix.

Almost every rescue job we take fails in one of these six places. You cannot see any of them in a Figma file.

  • It dies the moment the signal does

    The delivery partner walks into a basement and the app shows a spinner until the OS shuts it down. Twenty minutes of proof-of-delivery photos are gone.

  • Nine-second cold start

    Every SDK the marketing team ever asked for starts on the main thread before the first screen shows. Users delete the app before they see your logo.

  • Crash-free rate below 97%

    Nobody set up Crashlytics or Sentry, so no one can see the crashes. Your Play Store rating is dropping and no one can say why.

  • Payments fail silently

    UPI intent returns to the app with no reply, the order is charged but never confirmed, and support matches refunds by hand every morning.

  • The keystore is on somebody's laptop

    The old agency has the signing key. You cannot send an update for your own Android app unless they agree.

  • Push notifications reach half the users

    No plan for topics, no token refresh, and OEM battery savers shutting the service down. Your only way to bring users back is leaking.

How we build

From idea to both stores.

You are in a TestFlight build by week six. Not staring at a Gantt chart.

  1. 01

    Product shaping and platform call

    1–2 weeks

    We map the main job of the app, the phones it must work on, and the network it will really have. We choose Flutter, React Native or native, and we write down why, including what we give up. You get a scope, a list of test devices and a price.

  2. 02

    Interaction design and prototype

    2–3 weeks

    We follow the normal rules of each phone, not a web layout squeezed into a phone. That covers gestures, screen changes, offline and error screens, and the screens that explain permissions. Before we build, we show a clickable prototype to five real users like yours.

  3. 03

    Backend and sync engine

    3–5 weeks

    The API, login, push and sync. This is usually the 40% of the work that other quotes forget. It includes safe storage on the phone, a write queue that survives the app being closed, and a rule for clashing edits that we agree with you clearly.

  4. 04

    App build in two-week increments

    6–12 weeks

    Every merge makes a signed build in TestFlight and the Play internal track. You install it on your own phone the same day. Widget and integration tests run in CI. The low-end phone sits on a desk here and we test it by hand every sprint.

  5. 05

    Store submission and launch

    2–3 weeks

    Listings, screenshots, privacy labels, the data-safety form, the account-deletion flow, and the review rounds, including the rejections. On Android we roll out in steps of 5%, 20% and 100%, with the crash dashboard open all the way.

  6. 06

    Post-launch tuning

    30 days, then ongoing

    We watch crash-free sessions, ANR rate, cold start and where users drop off, using real traffic. We fix defects at no charge. Then we hand over the pipeline and the keys, or stay on to build what comes next.

Offline-first

The lift has no signal. The app should not care.

Offline is where most Indian apps quietly fall apart. A form that loses twenty minutes of a field agent's work because the lift had no signal is not just a small UX annoyance. It is the reason the agent goes back to paper.

We treat the database on the phone as the truth for the session. The server is what it matches up with later. Writes wait safely in a queue on the device. Clashing edits follow a rule we agree with you at the start: last edit wins, the server wins, or a person merges them. We do not leave it to whatever the sync library happens to do. Uploads carry on after the app is closed. The user sees what is waiting, what has synced and what failed, because silence is worse than a bad number.

What you get

Everything a shipped app needs.

A release pipeline you own

Fastlane lanes for signing, versioning and upload. Every merge to main makes a build in TestFlight and the Play internal track, tagged and linked back to a commit. Your team can release without us on day one, and without us on day four hundred.

Push that actually arrives

FCM and APNs with token refresh, topic groups, links that open the right screen, and fixes for the OEM battery savers that silently stop background services on Xiaomi, Oppo and Vivo phones.

Payments that reconcile

Razorpay, PhonePe or Cashfree with UPI intent, cards and netbanking. We also check webhooks on the server, so a charged but unconfirmed order cannot happen, not just unlikely.

Crash and performance telemetry

Sentry or Crashlytics with source maps, ANR tracking, cold-start traces and a dashboard of where users drop off. You will learn about a bad release from a graph, not from a one-star review.

A device matrix, not a MacBook simulator

We keep a low-end Android with 3GB of RAM, a mid-range Samsung and an older iPhone on the desk. We measure cold start, jank and memory on them, because that is what your customer is holding. A screen that drops frames on the cheap phone does not go live.

The stack

What we reach for.

Chosen for the phones people really use, and so you can hire people for them later.

Flutter
Dart
React Native
TypeScript
Swift / SwiftUI
Kotlin / Compose
Our release bar

Numbers we will not launch below.

These are release checks, not hopes. If a build misses one of them on the low-end phone in our test list, it does not go to the store, whatever the calendar says. Holding the line here is why our apps do not get a one-star average in week two.

Talk about your app
99.5%
Crash-free sessions

Measured across the device matrix

1.8s
Cold start

3GB RAM Android, cold cache

18MB
Median download size

Android app bundle, split per ABI

60fps
Scroll performance

No dropped frames on core screens

FAQ

Before you brief an agency, ask these.

Still have a question?

Flutter when the design is custom and you want it to look the same on both platforms, with the best speed on low-end phones. React Native when you already have a React web team and want to share code and hiring. Native when the app works close to the hardware, such as BLE devices, ARKit, background location that must survive Doze, or a vendor SDK that only comes for one platform. We recommend, we explain why in writing, and you decide.

Yes, and we build the pipeline so you can do it without us later. That means Fastlane lanes for signing and upload, automatic builds to TestFlight and the Play internal track on every merge to main, store listings with screenshots, privacy nutrition labels, and the data-safety form. We also handle the rejections, which do happen. The usual causes are account deletion flows, reasons for permissions and payment-policy questions.

For physical goods and services in India we connect Razorpay, PhonePe or Cashfree with UPI intent, cards, netbanking and wallets, plus UPI Autopay for subscriptions. For digital content Apple and Google require their own in-app purchase system and take their cut. We build StoreKit 2 and Play Billing with receipt checks on the server. We will tell you plainly which group your product falls into before it becomes a rejection.

We buy the phones. Our test matrix includes a low-end Android with 3GB of RAM and an older iPhone SE, not just flagships. We measure cold start, jank frames and memory on those phones. We set a limit on app size, move everything non-essential off the start-up path, and load images late at the size the screen needs. If a screen drops frames on the cheap phone, it is a bug and it blocks the release.

A single-role app with auth, a core workflow, push and payments is typically 12 to 16 weeks and lands in the ₹8L to ₹18L range. A platform with many roles (customer app, partner app, admin console, offline sync, live tracking) takes 20 to 30 weeks and costs more. The backend is usually about 40% of the work, which is the part most quotes quietly leave out. Ours does not.

You do. The Apple Developer and Google Play accounts are in your company name with your billing. The signing certificates and keystores are handed to you in a vault that you control. We have taken over too many projects where the old agency held the keystore hostage. It will not happen here. You can remove our access on any day and still send an update.

Show us the workflow that breaks when the signal drops.

Bring the field process, the phone your users really hold, and the limit that everyone else told you was impossible. We will tell you what it takes.

Let's talk mobile app development

Bring us the hard version of the problem.

A senior engineer reads every enquiry. You'll get a real answer — scope, risk and a number — within one business day.