Native vs Cross-Platform: Choosing for Agency Mobile Projects

A client asks for an app. Someone on the call says "we'd build it cross-platform," and that decision — made in about four seconds — sets the budget, the timeline, and what the app can ever do.

It is worth more than four seconds. Here is the version you can reason about without being an engineer.

The two options

Native means building separately for each platform, using each platform's own tools and languages. Two codebases, full access to everything the device can do.

Cross-platform means one codebase producing apps for both platforms. Considerably less duplicated work, at the cost of sitting one layer away from the platform.

The naive maths — one codebase instead of two, therefore half the cost — is wrong in both directions. Cross-platform is usually cheaper than two native builds but more than half, because platform-specific work does not disappear entirely. And for some products, the cross-platform workarounds cost more than building native would have.

When cross-platform is the right call

For most agency client work, it is. Specifically when:

• The app is primarily screens, forms, and data. Content, booking, dashboards, directories, e-commerce, internal tools. This is the majority of client requests.
• Budget matters more than the last 5% of polish. Usually true.
• The client needs both platforms at once. One team, one timeline.
• The roadmap is uncertain. Iterating on one codebase is faster and cheaper than keeping two in sync.

If the app is a well-built interface over an API, cross-platform is not a compromise. It is the correct economic decision, and users will not be able to tell.

When native earns its cost

• Heavy device capability use. Sophisticated camera work, Bluetooth peripherals, background location, health data, offline-first sync at scale. These are where cross-platform frameworks are weakest.
• Performance is the product. Games, real-time media, intensive graphics or animation.
• Platform-specific UX is a selling point. Widgets, watch apps, deep OS integrations, platform-native design conventions.
• Regulatory or security constraints that specify platform-native implementations.
• One platform only. If the client genuinely needs iOS alone, cross-platform buys you nothing.

The honest middle

Two things that get skipped:

A mobile web app may be the answer. If the client wants "an app" but the product is content or forms with no need for push notifications, offline use, or device hardware, a responsive web app is dramatically cheaper and has no review process. Ask why it needs to be in a store. Sometimes the answer is good. Sometimes it is that the client thinks apps are how software works.

Cross-platform still needs platform knowledge. Push notifications, deep links, permissions, store configuration, and build signing all differ per platform regardless of framework. "One codebase" does not mean "one platform's worth of expertise."

What the app stores actually cost you

This is the part agencies new to mobile underestimate, and it is not code:

Review takes real time, and first submissions get rejected. Frequently for reasons unrelated to quality — metadata, privacy disclosures, account deletion requirements, a login for reviewers, unclear permission justifications. Plan for a review cycle in the timeline rather than treating it as an overrun.

Store assets are a deliverable. Screenshots per device class, description, keywords, privacy policy, support URL, data disclosure forms. Someone has to produce these; put it in scope or in exclusions.

Account ownership matters more than people realise. Publish under the client's developer account, or yours — never a partner's. Whoever holds the account controls the app. Getting this wrong creates a painful migration later.

Updates go through review too. A hotfix is not instant. Build that into any support expectations you sell.

What to tell the client

Frame it as a trade, not a technicality:

"Cross-platform gets you both platforms for meaningfully less, and for what this app does, users won't see a difference. Native costs more and takes longer, and it's the right call when the app depends on device capabilities — which yours doesn't. If that changes, here's what switching would cost."

Clients accept a recommendation with a stated trade-off far more readily than a technology assertion. It also protects you: the reasoning is documented, so a later change of requirements is visibly a change, not a mistake.

Questions before you quote

• What does the app do that a mobile website could not?
• Which device capabilities does it need — camera, location, offline, push, Bluetooth?
• Does it need to work without a connection?
• Is there an existing backend, or is that in scope too?
• Whose developer account will it publish under?
• Which OS versions and devices must be supported?
• Is there a deadline tied to something external?

That last one matters more for mobile than web, because you do not control review timing.

If you are selling apps you cannot build

The mobile-specific knowledge — framework choice, store configuration, review handling, release management — is the part that is hard to hire for on one project. It is why agencies commonly deliver mobile through a partner while keeping the client relationship.

That is white-label mobile app development: the build and release happen under your brand, in your or your client's store account. If you are weighing that against hiring, the cost comparison framework applies here too.