Mobile App Development
Cross-platform when it fits, native modules when it doesn't.
Building a mobile app is really three projects running at once: the product itself, the plumbing underneath it (API, offline behavior, push, payments), and the part most teams underestimate, which is convincing Apple and Google to let the thing exist in their stores at all. We build for all three, not just the version that looks good on a laptop screen during a demo.
React Native, Flutter, or native — and when it actually matters
For most product apps (login, feed, forms, checkout) we default to React Native or Flutter and build once for both platforms. Which one depends on the team, not on marketing claims. React Native tends to win when you’re already running React on the web and want to share business logic and types across both; Flutter tends to win when the design leans on custom animation or a brand that shouldn’t look like it’s wearing each platform’s default UI kit, since it draws its own widgets instead of bridging to native ones.
Cross-platform stops being the right call once the app leans hard on the OS itself. The usual triggers:
- Deep hardware access — Bluetooth peripherals with real-time requirements, background location, HealthKit or Health Connect
- Platform-native experiences — CallKit, ARKit, home screen widgets, watchOS companions
- Background processing the OS treats differently per platform, like continuous audio sessions
For those we write native modules in Swift or Kotlin and bridge them into the React Native or Flutter layer, instead of forcing a JavaScript library to fake something the platform was never built to expose. Most apps need zero native modules. A few need two or three. Very few need to be fully native, and when one does, we say so before we start, not after a month of proving it to ourselves.
Expo by default, and an offline layer that actually holds up
We build on Expo and ship through EAS Build unless a specific native module forces a bare workflow for that one piece — it removes most of the code-signing pain and lets us push JavaScript-only fixes as over-the-air updates without a full store resubmission. We used to reach for WebView-wrapped apps on tighter budgets; we don’t anymore, because they read as a web page wearing an app icon and tend to draw more scrutiny in review.
Offline-first is a design decision, not a checkbox — which data lives on the device, how it syncs back, what happens when two edits collide while a user was on a plane. We build that layer deliberately, usually SQLite or WatermelonDB locally with an explicit sync strategy, instead of a “retry when online” wrapper bolted on at the end. Push notifications run through APNs and Firebase Cloud Messaging, segmented and deep-linked into the right screen rather than fired at everyone. In-app purchases and subscriptions go through RevenueCat with server-side receipt validation, because “worked in the sandbox” and “worked in production” are different claims, and the gap between them is where refund disputes live.
Then there’s the store, and what you actually get from us
Apple’s review team and Google’s Play Console policy engine reject apps for reasons that have nothing to do with code quality — a missing privacy manifest, a subscription screen that doesn’t quite match the flow it described, a permission requested without a clear enough justification string. We write the submission to survive that process and handle the resubmission ourselves when it doesn’t, which is common on a first pass and not a sign anything went wrong. Rejections are triaged the same day they land, so a resubmission is usually queued within one working day.
You get working builds on TestFlight and Play Internal Testing throughout the project, not one reveal at the end. Source code, signing credentials, and store account access are yours from day one — we develop inside your own developer accounts wherever the platform allows it, so there’s nothing to negotiate at handover because nothing was ever held back.
This is not the right service if what you actually need is a content app that a no-code builder could put together in a week — we will say so before quoting a custom build. It becomes the right service once the app has to do something a template can’t: real offline behavior, a payment model beyond a single purchase, or platform features a page builder was never built to reach.
What this is meant to achieve
The measures we hold the work to, agreed with you before the build starts.
An app that clears App Store and Play Store review without three rounds of guessing why it got rejected
Offline mode that doesn't quietly drop orders or form submissions when the connection cuts out
Subscription and purchase flows that behave the same in production as they did in the sandbox
A codebase the next developer can actually read, not a pile of unmaintained native forks
A release process your team can run on its own once the engagement ends
Questions people ask before signing
Straight answers on pricing, code ownership, timelines and what happens after launch.
By what the app actually needs, not by trend. If you’re a small team already running React on the web, or the app is mostly forms, feeds, and CRUD screens, React Native is the practical choice since you get both platforms and shared logic with your web app. If the design leans on heavy custom animation or a brand that can’t look like a default UI kit, we lean Flutter. Fully native, with separate Swift and Kotlin codebases, is rare and expensive to maintain long-term, so we only recommend it when the app is genuinely inseparable from one platform’s ecosystem — something built around ARKit or a watchOS companion, for example.
Expo and EAS Build by default. It removes most of the code-signing pain and lets us ship JavaScript-only fixes as over-the-air updates instead of a full store resubmission. If a feature needs a native module Expo’s managed workflow doesn’t support, we drop to a bare workflow for that specific piece rather than the whole project — there’s rarely a good reason to give up the tooling entirely.
It happens on a fair number of first submissions and it’s rarely fatal — a missing privacy nutrition label, a subscription screen that doesn’t quite match what was described, wording on a permission prompt. Resubmission is part of the engagement, not a change order. We write the initial submission to reduce this, but we won’t tell you zero rejections is realistic, because it usually isn’t.
Yes, after we audit it first. We’ll tell you honestly what state the code is in — some React Native and Flutter codebases are fine to inherit, others have enough patched-over native module conflicts that a partial rewrite is faster than untangling them. We won’t know which until we’ve actually looked.
You do — the code, the Apple Developer and Google Play accounts, the signing certificates, all of it. We develop inside accounts you control wherever the platform allows it, so there’s no handover negotiation at the end of the project.
Both, and they’re usually the parts that go wrong when teams bolt them on late. Push runs through APNs and Firebase Cloud Messaging with real segmentation, not a blast to every device. Purchases and subscriptions run through RevenueCat with server-side validation, so an entitlement can’t be spoofed by replaying a sandbox receipt.
Ready to talk about Mobile App Development?
Tell us what you need built. You will get a written proposal with scope, timeline and price before any work begins.