Cheffusion Technologies
Mobile

Cross-platform Applications

One codebase where that is honest, two where it is not

How this is usually engaged

Typically twelve to eighteen weeks for a first release on both platforms. We are direct about the trade-off in the first workshop: cross-platform is usually the right answer for form-heavy, content-heavy and workflow applications, and the wrong answer for anything where the interface is the product or hardware access is constant.

Start a project brief
Practice
Mobile Engineering
Sectors
4 served
Process
5 stages
Standard
Built and tested to WCAG 2.2 AA

React Native and Flutter applications that serve iOS and Android from a shared codebase, with the platform-specific work identified and scoped rather than wished away.

01What this solves

The problem this addresses

Cross-platform is sold as half the cost and delivered as two thirds of it, because the sales pitch quietly omits what is not shared: two store submissions, two sets of permissions and privacy declarations, two release cycles, and any screen that touches hardware or platform conventions closely. Teams that budget for one platform and discover they bought one and a half end up shipping an app that feels slightly wrong on both.

02Capabilities

What is included

01

Shared and native boundary design

An explicit map of what is written once and what is written twice, produced before estimating. This is the single decision that determines whether cross-platform saves you money or costs you more.

02

React Native or Flutter, chosen deliberately

React Native where your team already works in TypeScript and the app shares logic with a web product. Flutter where the interface is highly custom and rendering consistency across devices matters more than reusing web skills. We explain the choice rather than defaulting to it.

03

Native modules where required

Bluetooth peripherals, background location, widgets, biometric flows and payment sheets implemented natively behind a shared interface, so the rest of the codebase stays platform-agnostic.

04

Offline data and synchronisation

A local database with a change queue and agreed conflict resolution, shared across both platforms so the sync rules cannot drift apart.

05

Dual release pipelines

Automated builds signing for both stores, distributing to TestFlight and the Play internal track from the same commit, with version numbers kept in step.

06

Accessibility across both platforms

Labels, focus order, scaling type and contrast verified with VoiceOver on iOS and TalkBack on Android separately, because a shared component tree does not guarantee an equivalent experience on both screen readers.

03Use cases

Where this work usually starts

01

Reaching both platforms on one budget

A workflow or content application where the interface is largely forms, lists and detail screens, and where writing it twice would be hard to justify.

Professional Services

02

Extending an existing web product to mobile

A React and TypeScript web application whose validation rules, types and API client can be shared rather than reimplemented in two more languages.

03

Getting a product in front of users to learn from it

An early release where the priority is discovering what people use, with the option to rewrite a heavily used part natively once you know which part that is.

Education

04Approach

How we approach it

We divide the application before we start: the screens and logic that genuinely share, and the parts that will need native work on each platform. The shared layer covers navigation, data, business rules and the majority of the interface; the native layer covers hardware access, background behaviour, notifications and anything where the platform convention differs enough to be noticed. Both stores are treated as first-class from the beginning, with builds going to TestFlight and the Play internal track in the same week.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

  1. 01

    Suitability assessment

    An honest read on whether your application is a good cross-platform candidate, including the case for building native instead.

  2. 02

    Boundary and architecture design

    The shared and native split, the data model and the sync rules, agreed before build.

  3. 03

    Design for two conventions

    One design language, with navigation, dates, sharing and system dialogs following each platform where users would notice the difference.

  4. 04

    Parallel build and dual distribution

    Both platforms built and distributed to testers from the start, so neither becomes an afterthought.

  5. 05

    Store submission and staged release

    Both submissions prepared together, then a phased rollout on each with crash reporting watched.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

  • Shared codebase with platform-specific modules
  • Shared and native boundary documentWhat is written once, what is written twice, and why.
  • iOS and Android release pipelines
  • Store listings, privacy and data safety declarations for both stores
  • Accessibility results per platform
  • Handover documentation and runbook
07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

  • TypeScript
  • Node.js

Mobile

  • React Native
  • Flutter

Data & Storage

  • PostgreSQL

DevOps & Operations

  • GitHub Actions
  • Sentry
The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Secrets live on your server, never in the JavaScript bundle or the Dart binary, both of which are readable by anyone who downloads the app. Credentials are stored through the platform keystore and Keychain rather than in a cross-platform convenience store that writes to plain files. Over-the-air update channels, where used, are locked to signed releases from your pipeline, and we agree in advance which changes may go out that way and which must pass through store review.

Our full security and quality approach
09Questions

Asked before we start

Is cross-platform really cheaper than building twice?

Usually, but by less than the marketing suggests. Expect a meaningful saving on interface and business logic and almost none on store submissions, permissions, release management, device testing or anything touching hardware. Where an application is mostly forms, lists and content, the saving is real; where the interface is the product, it can disappear entirely.

When would you tell us to build natively instead?

When the app depends heavily on hardware or background behaviour, when interface performance is a competitive feature, when you need platform capabilities on the day they are announced, or when you already have native engineers you intend to keep. We would rather lose the wider scope than deliver an app that feels slightly wrong on both platforms.

Can we ship updates without going through app review?

For React Native, some JavaScript-only changes can be delivered over the air, which is useful for urgent fixes. It is bounded, though: anything touching native code still requires a store release, and both stores have rules about changing an app's behaviour outside review. We agree the boundary with you and keep over-the-air use for fixes rather than features.

What happens if we outgrow the shared codebase?

Because the boundary is documented and the native modules are already separate, a heavily used area can be rewritten natively without restarting the project. That is a normal outcome rather than a failure, and it is a good reason to keep the shared layer disciplined from the beginning.

START HERE

Talk to us about Cross-platform Applications

The project brief takes about five minutes and gives us enough to have a useful first conversation about Cross-platform Applications rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a projectSend a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.