§ CAPABILITY

Mobile App Development

Mobile applications where the release process is designed alongside the app. Store review, staged rollout and the long tail of OS versions are part of the engineering, not an afterthought.

Who
Delivered by a senior team assembled for the engagement, against a defined scope.
Request a call How the work runs

What you're seeing

A bad build is live and the only fix is another store review.
Usually means There is no staged rollout and no remote kill switch. A mobile release cannot be rolled back the way a server deploy can, and that has to be designed for before the first submission, not after the first incident.
Support tickets describe behaviour nobody can reproduce.
Usually means There is no crash reporting tied to build and OS version, so the reports arrive as prose. The distribution of versions in the wild is usually wider than anyone assumes.
The app was built assuming a network and users are complaining on trains.
Usually means Offline behaviour was left to the data layer's defaults. Retrofitting it means rewriting the data layer, which is why this is a design decision rather than a feature.

The release path is part of the build

A mobile release cannot be rolled back the way a server deploy can. Once a binary is approved and downloaded, it is on devices until a replacement passes review — and review is days at best.

That single fact reshapes the engineering. Staged rollout, so a bad build reaches one per cent before it reaches everyone. Crash reporting keyed to build and OS version, so the pattern is visible while it is still one per cent. A remote flag for anything risky, so a feature can be turned off without a submission. And an escape hatch for the case where the client is unrecoverable and the only lever left is on the server.

None of these are features and none of them appear on a roadmap. All of them are far cheaper before the first submission than during the week of the first bad one.

Offline is a design decision

What the application does without a network, and what happens to conflicting edits when it reconnects, shapes the data layer.

The two viable answers are very different. Read-only caching with a clear staleness indicator is cheap and honest, and it is the right answer for most business applications. Full offline editing with conflict resolution is a substantially larger piece of work and it changes how every write in the application is modelled.

What is not viable is deciding later. Adding real offline behaviour to a data layer built on the assumption of a network is not a feature, it is a rewrite of the part of the application everything else depends on.

The version tail

There will be users on a build from eighteen months ago and an OS two majors behind.

Without a written support policy, whether that is supported gets decided per bug report by whoever picks it up, and the test matrix grows until running it fully stops happening. With one, it is a business decision with a date: these versions are supported, this is when support ends, and this is how those users are moved forward.

Where it sits

This is a capability inside Software Development, and it is almost never bought alone — the application is a client for something, and that something is usually built alongside it as Backend & API, with a versioning policy that has to survive users who never update.

The release mechanics overlap directly with Release & Deployment Verification, which is the same discipline applied where a rollback does exist.

How the work runs

  1. Decide cross-platform or native

    Against what the product actually needs from the device. Cross-platform is right for most business applications and wrong when the value is in platform-specific capability.

  2. Design for the network being absent

    What the application does offline, how it resolves conflicts on reconnect. Deciding this late means rewriting the data layer.

  3. Build the release path

    Signing, build automation, staged rollout and crash reporting set up before the first submission rather than during it.

  4. Plan the OS-version tail

    Which versions are supported, when support is dropped, and how users on old builds are moved forward.

What arrives

  • An application on the platforms the product needs
  • Automated signing and build pipelines
  • Staged rollout with crash reporting and a rollback path
  • A written OS-version support policy

What it costs your team

Around three hours a week, plus store account access and whatever your legal review of the listing requires.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • The release path is built before the first submission

    Costs It spends early weeks on signing, automation and rollout mechanics with nothing user-visible to show.

    A server deploy can be reverted in minutes. A mobile release is in the hands of users until a new binary passes review, which is days at best and unpredictable at worst. Staged rollout, crash monitoring and a remote switch for a bad feature are the substitutes for a rollback, and building them under pressure after a bad release is the worst version of the same work.

  • Cross-platform or native is argued, not defaulted

    Costs It is a decision that takes a week to make properly and cannot be revisited cheaply.

    Cross-platform is right for most business applications, where the value is in product logic and the device is a screen. It is wrong where performance, background execution or a platform capability is the product. Defaulting either way — to native for prestige, or to cross-platform for cost — commits the whole build to an assumption nobody stated.

  • The supported OS-version range is written down

    Costs It means dropping users deliberately and telling someone that is happening.

    Some users never update. Without a stated range, the answer to 'do we support this' is decided per bug report by whoever picks it up, and the test matrix quietly grows until nobody runs it. Naming the range makes it a business decision with a date rather than an accumulating engineering tax.

Frequently Asked Questions

Building software that runs on a phone and everything the store distribution model requires around it: signing, review submission, staged rollout, crash reporting, and support for users who will not update. The application is roughly half the work; the release and upkeep path is the rest, and it is the half that is usually underestimated.
React Native for applications whose value is in product logic rather than device capability, which covers most B2B mobile. Native where performance, background behaviour or a platform API is central to what the product does. We make the case either way rather than defaulting, because the decision is expensive to reverse.
Either, but the developer accounts should be yours. The accounts and the listings are assets that must not depend on a supplier, so we run the submission process alongside whoever will own it rather than in place of them.
Usually days, occasionally much longer, and it is not predictable. Release planning assumes a review window rather than an approval date, which is why the rollout mechanism matters more than the submission calendar.
Assume some will never update. That requires an API versioning policy so old builds keep working, and a way to force an upgrade when a build becomes genuinely unsupportable. Both are decided at design time, because both are contracts with the server.

Sources

Page reviewed