Skip to content

Software

Mobile app development for enterprises and governments

We build mobile apps for organisations that serve large, varied user groups: citizens, customers, field staff and employees. Each app is designed for the device in the user's hand, including poor connectivity, Arabic and English, and the identity and security rules your organisation operates under.

A slim brushed silver slab on a stone plinth, its face a grid of metal tiles with two glowing frosted glass ones

What it is

iOS and Android apps for customers, citizens and staff, built on a shared codebase with secure sign-in.

An enterprise app is judged by the least patient person who has to use it. A field inspector with one bar of signal, a customer renewing a service on a commute, a citizen opening a government service for the first time. We design around those moments, and test on mid-range devices and slow networks, not only on the newest phone in the office. Usability findings from those sessions go straight into the build. Accessibility, including dynamic type and screen readers, is checked on real devices before every release.

Most projects share one codebase across iOS and Android, which keeps behaviour consistent and maintenance affordable. Where a feature genuinely needs native code, such as biometric prompts, background location or a hardware integration, we write it natively and keep it isolated. The app talks to a documented API, so the same backend can serve a web portal and other channels. Keeping the logic in one place also means a fix reaches every user at once. Analytics and crash reporting are wired in from the first build, so you see how the app behaves in use.

We handle the parts that delay releases: store accounts, review guidelines, privacy declarations, app signing and release automation. Updates are staged and can be rolled back. Release notes and store listings are prepared in both languages when the audience needs them. You approve each release before it goes to the stores. At handover your team holds the repositories, the store accounts and the pipelines that publish new versions.

Capabilities

What the work covers.

  • Cross-platform apps

    One React Native codebase for iOS and Android, with native modules where the platform requires them.

  • Secure authentication

    Biometric unlock, single sign-on with your identity provider, short-lived tokens and device binding for sensitive roles.

  • Offline-first design

    Local storage and background sync so field and low-connectivity users can keep working and reconcile cleanly afterwards.

  • Arabic and English, right-to-left

    Layouts that mirror correctly, typography tuned for Arabic, and content that switches language without a restart.

  • Push notifications and messaging

    Targeted, consent-based notifications and in-app messaging, with delivery tracking and quiet hours.

  • Payments and wallets

    Integration with regional payment providers and card tokenisation, designed so card data never touches your servers.

  • Backend and admin

    The API, database and admin console behind the app, so content, users and permissions are managed without a developer.

  • Store release and monitoring

    App Store and Google Play submission, staged rollouts, crash reporting and performance monitoring after launch.

At handover

What you keep.

Typical stack

React Native, Expo, TypeScript, Node.js, Hono, PostgreSQL, Better Auth, Playwright, Figma, Railway.

Named plainly. We pick per project and explain why.

  • Source code for the app and its backend
  • Apple Developer and Google Play accounts set up in your organisation's name
  • Automated build and release pipeline
  • Design files and a component library
  • API documentation
  • Crash and analytics dashboards
  • A release playbook and handover training

How it runs

Four steps, every time.

The solved cube on a black stone plinth, its front face showing the BTI logo in brushed metal and frosted glass
  1. Discover

    We map the product, the funnel or the process and agree where the first useful change is.

  2. Design

    Scope, architecture and rollout on paper. You see what ships, in what order, before anything is built.

  3. Build

    Working increments, reviewed with you as they land rather than revealed at the end.

  4. Operate

    We hand over code, documentation and access, train your team, and stay on until running it is routine.

Questions

Straight answers.

How do we choose the best app development company?

Ask for apps they have shipped to the stores and talk to the clients who run them. Look at how they handle offline use, authentication and Arabic layouts, who will own the store accounts and source code, and how updates are tested and released. A good company explains its trade-offs between native and cross-platform in terms of your users, not its own preferences.

Native or cross-platform?

Cross-platform suits most business apps and reduces cost and drift between iOS and Android. We choose fully native when the app depends heavily on platform-specific hardware or graphics. We explain the choice for your case in discovery.

Can the app work offline?

Yes. We design the data model for it from the start, with local storage, queued actions and conflict handling, so users can keep working and the app reconciles when a connection returns.

Who owns the store accounts?

You do. Developer accounts are registered to your organisation, and we are added as team members during the build. That avoids a dependency on us for publishing.

How long does an app take, and what does it cost?

A scoped first release typically takes a matter of weeks to a few months, depending on the features, integrations and approvals involved. Cost is set before kickoff against that scope, including the backend and store release work.