[Mobile app development]

Mobile App Development Services

Getting an app into the stores is the easy part. Keeping it fast on older Android phones, working without signal, passing review every release and telling you what users actually do. That is the work. We build iOS and Android apps in React Native, Flutter, Swift or Kotlin, choose between them honestly, and stay through release and beyond.

  • React Native, Flutter or native Swift and Kotlin: chosen for your app, not our preference
  • Offline-first data, push notifications, payments and analytics designed in from the start
  • App Store and Play Store submission, review and release management
Request a ProposalSee what we build
[Who this is for]

Who this is for

Businesses for whom the app is a product or a channel in its own right, not a wrapper around a website.

  1. Startups launching a first app

    You have a validated idea and a budget that has to cover both platforms. You need a team that will pick the right cross-platform stack, build the version one that proves the model, and leave you able to iterate.

  2. Businesses adding a mobile channel

    You already serve customers on the web or in person (retail, logistics, healthcare, financial services) and need an app that connects to existing systems, works in the field and meets your compliance obligations.

  3. Teams with an app that has stalled

    You have an app already. It crashes on certain devices, the last agency left, the codebase is on an old framework version, or store review keeps rejecting it. You need it stabilised and moving again.

[What we build]

Mobile development services

These are the shapes most mobile engagements take. Most projects combine a build with at least one of the specialist areas below.

  1. Cross-platform apps in React Native and Flutter

    One codebase for iOS and Android when the app is mostly screens, forms, lists and API calls, which is most apps. React Native suits teams that already have React and TypeScript on the web; Flutter suits design-heavy interfaces that must render identically on both platforms. This applies when time to market and a single team matter more than the last few percent of platform fidelity.

    • React Native with Expo or a bare workflow
    • Flutter with a typed API contract to the back end
    • Shared design system across platforms
    • Native modules where a platform API is needed

  2. Native iOS (Swift) and Android (Kotlin)

    Separate native codebases when the app leans hard on the platform: camera and sensor pipelines, Bluetooth and hardware peripherals, background processing, ARKit or Core ML, or animation that must hold 60 fps on older devices. This applies when cross-platform would spend more time working around the framework than it saves.

    • SwiftUI and UIKit; Jetpack Compose and Kotlin
    • Bluetooth, NFC, camera and sensor integration
    • Background tasks, widgets and app extensions
    • Platform-native accessibility support

  3. Offline-first and data sync

    Apps that keep working in a warehouse, on a delivery route or on a poor connection: local storage as the source of truth, queued writes, conflict resolution and sync that resumes cleanly. This applies to field operations, logistics, healthcare and any app used where signal is not guaranteed.

    • Local database with SQLite, Realm or WatermelonDB
    • Queued mutations with retry and back-off
    • Conflict resolution rules agreed with you, not guessed
    • Sync status visible to the user

  4. Payments, subscriptions and in-app purchase

    Taking money in an app correctly: Apple and Google in-app purchase for digital goods, Stripe or regional gateways for physical goods and services, subscription lifecycles, receipts and server-side verification. This applies to any app with revenue, and it is where store review is strictest.

    • StoreKit 2 and Google Play Billing
    • Stripe, Apple Pay, Google Pay and local gateways
    • Server-side receipt validation
    • Subscription, trial and refund handling

  5. Push notifications, deep links and engagement

    Notifications that arrive, are relevant and open the right screen: APNs and FCM, segmentation, quiet hours, universal links and app links, and the analytics to know whether any of it worked. This applies to any app where retention matters more than the install.

    • APNs and FCM with token lifecycle management
    • Deep and universal links into any screen
    • Product analytics and event design
    • Crash reporting and performance monitoring

  6. App store release and lifecycle management

    Getting through review the first time and every time after: store listings, privacy manifests and data-safety forms, TestFlight and internal testing tracks, staged rollouts, and a release cadence your team can sustain. This applies from the first submission onward, and especially when an app has been rejected before.

    • App Store Connect and Play Console setup
    • Privacy labels and data safety declarations
    • CI builds, code signing and over-the-air updates
    • Staged rollouts and rollback plans
[Alongside the build]

Also part of the engagement

[Technology stack]

Technologies we work in

  1. UI/UX design and prototyping

    Interactive prototypes tested on real phones before code is written, following Apple and Material guidelines where users expect them.

  2. Device and OS testing

    Testing on real devices across screen sizes, OS versions and low-end Android hardware, not only the simulator on a developer's laptop.

  3. Back end and APIs

    Firebase or a Node.js API in your cloud, designed with mobile constraints in mind, payload size, pagination, versioning for app builds that users never update.

  4. Security and compliance

    Secure storage, certificate pinning where warranted, biometric authentication and data handling that meets store policies and regulations such as GDPR.

React NativeExpoFlutterSwift / SwiftUIKotlin / Jetpack ComposeFirebaseNode.jsSQLite / RealmApp Store ConnectGoogle Play Console
[Our approach]

How we approach mobile work

  1. Stack chosen for the app, stated in writing

    Cross-platform versus native is a trade-off, not a doctrine. We set out the reasoning (team, features, budget, device targets) before the first line of code, so nobody is surprised a year in.

  2. You own the app and the accounts

    Developer accounts, signing certificates, repositories and back-end infrastructure are in your name from day one. Losing access to your own app is a failure mode we design out.

  3. Tested where users are, not on the simulator

    Older Android devices, small screens, poor connections and interrupted sessions are the normal case for most of our clients' users. We test for them deliberately.

[How it works]

What the engagement looks like

  1. 01

    Discovery

    What the app must do, who uses it, on which devices and where, what it connects to and how it earns or saves money. This is where the cross-platform-or-native decision is made.

  2. 02

    Plan, design and estimate

    User flows and an interactive prototype, a technical design covering stack, data and sync, store requirements, a phased scope and a cost range.

  3. 03

    Build and test on devices

    Short increments with a build on your phone via TestFlight and internal testing at the end of each, plus automated tests and a device pass before every release.

  4. 04

    Release and iterate

    Store submission handled, staged rollout, crash and analytics dashboards live from launch, then a cadence of updates or a handover to your team.

[You own it]

What you receive at the end

Everything runs in accounts you control from the first commit. Ending an engagement is an access change, not a migration.

  • Source code in your repository
  • Apps published under your developer accounts
  • Design files and interactive prototype
  • Technical design and API documentation
  • Automated tests and CI build pipeline
  • Handover session and release runbook
[Project examples]

Relevant projects from our portfolio

Illustrative SahulatPay wallet, transfers, top-ups and administration interface collage (illustrative concept UI)Illustrative concept

E-Wallet & Mobile Application

SahulatPay Digital Wallet

A close-loop digital wallet for SahulatPay: backend services, a Flutter application for Android and iOS, and production deployment to both stores.

Explore project
Illustrative AssanPay payment platform collage with blurred merchant dashboard and payment receipt details (illustrative concept UI)Illustrative concept

Payment Infrastructure

AssanPay Payment Gateway

A regional payment gateway platform with merchant and admin dashboards, payment APIs, hosted checkout and integrations for e-wallets, QR payments and cards, plus a Flutter merchant app for Pakistan.

Explore project
[FAQ]

We’ve got the answers you seek

Anything not covered here? Ask us through the contact form and we’ll answer within a working day.

  • Yes. Our SahulatPay project included backend services, a Flutter application for Android and iOS, and production store releases. We scope the application workflows and backend dependencies together.

Tell us what the app needs to do

Who uses it, on which phones, where, and what it connects to. We'll come back within one working day with an honest view on stack and roughly what it would take.

Request a ProposalSee Our Work

Trusted by teams across fintech, e-commerce and SaaS

SahulatPayAssanPay1BDesignPalsTyconpayNimbusVaultixCoreGrid

Explore other services

  1. Custom Software DevelopmentComplete software projects built around your business.
  2. Custom Web Application DevelopmentModern, responsive web applications.
  3. SaaS Application DevelopmentApplication engineering for your software product.