Services / Mobile Development

Cross-platform or native — decided per project, not by habit.

We will tell you when native is worth the cost, and when it is a waste of budget.

Typical first engagement: 8–14 weeks, fixed scope
Starts with: Platform decision, written with the trade-offs
Ends with: Store-released build, CI pipeline and release runbook

The problem

What this practice is actually for.

Mobile projects rarely fail on rendering. They fail on offline behaviour, sync conflicts, push reliability and a release process nobody documented.

So the platform question gets answered quickly, then attention goes where the risk is: state and sync, release engineering, and the operational tail after launch.

One written platform recommendation with the cost of each option
Offline-first data and conflict resolution designed rather than discovered
Automated builds and signing, so releases are not one person's private ritual
Crash and performance monitoring wired up before the first store submission

In the work

What Mobile code looks like when we write it.

Running 0.0s

pipeline main ● live run

Offline-first, because the network is not a given.

The hard part is what happens when a request fails mid-flight and the user backgrounds the app. Deterministic sync, written conflict rules, a build pipeline anyone can run.

Scope a Mobile engagement →

Capabilities

Mobile Development — the full stack.

6 capability groups

Cross-platform: React Native, Flutter, Kotlin Multiplatform (KMP), Expo tooling
iOS: Swift, SwiftUI, Xcode, App Store review and release process
Android: Kotlin, Jetpack Compose, Java, Android Studio, Play Console release process
State & data: Offline-first sync and conflict resolution, local persistence (Room, Core Data, SQLDelight), background upload that survives process death
Delivery: Push architecture, deep linking, feature flags, staged rollout, CI for mobile builds and signing
Quality: Crash-free session monitoring, startup and frame-time profiling, automated UI testing

Typical engagements

How this work usually starts.

Indicative scope and duration

Fixed scope

Consumer app build

From platform decision to store release: architecture, interface, API integration, analytics, crash reporting and a documented release pipeline.

10–14 weeks · iOS + Android

Fixed scope

Field / offline app

Applications that must work with no connectivity: local-first data, deterministic sync, conflict resolution and background upload that survives being killed.

8–12 weeks · offline-first

Advisory

Platform and codebase review

Assessment of an existing app: architecture, crash trends, release process, and whether a rewrite is genuinely cheaper than repair.

2 weeks · written recommendation

What you get

Deliverables, every time.

Released build

Shipped through App Store and Play Console with the submission process documented for your team to repeat.

Build pipeline

Automated builds, signing and distribution to testers, so any engineer can cut a release.

Sync specification

The offline data model, conflict rules and retry behaviour written down, because this is where mobile bugs live.

Monitoring baseline

Crash-free session rate, startup time and key funnel instrumentation, with alert thresholds set.

Questions

What clients ask before they commit.

React Native when you have a React web team and want shared knowledge. Flutter when the interface is highly custom and you want identical rendering across platforms. Native when you depend on platform-specific hardware, need the last increment of performance, or you already have iOS and Android engineers. We write the recommendation down with the cost of each option, and we are happy to be argued with.

Yes, including the parts nobody enjoys: review responses, privacy declarations, screenshots and staged rollout. We document the process so the second release does not need us.

Usually. We start with a short review of architecture, dependency health and crash trends, then give you a maintenance plan or an honest case for rebuilding. We would rather tell you the codebase is worth keeping than sell a rewrite.

Also from Windsor Harlow

Other practices

→

Have a Mobile problem worth a senior pair of eyes?

Tell us the system, the constraint, and what happens if it is not solved. A senior engineer replies within one business day.

Scope an engagement →