Cross-platform app

A native app is written separately for each platform, usually in Swift for iOS and Kotlin for Android. A cross-platform app is written once with a framework, and the framework produces the app for both platforms. Your customers download it from the App Store and Google Play like any other app.

Two examples of such frameworks:

• React Native, which Meta released in 2015 and still maintains. Its core components map to each platform's native interface building blocks.
• Flutter, which describes itself as an "open-source framework for building beautiful, natively compiled, multi-platform applications". It targets mobile, web, desktop and embedded devices from one codebase.

The trade-offs

• One codebase, one team. Features, fixes and tests are written once for both platforms, which can lower build and maintenance effort compared with two native apps.
• Not everything is shared. React Native's own documentation says you'll want to reuse as much code as possible, but that some code, such as visual components, may need to differ between Android and iOS.
• Device-heavy features. An app built around advanced graphics, unusual hardware or heavy background processing may need native code alongside the shared code, or a fully native build.
• Check before you commit. Confirm that the framework supports each device and operating-system feature on your list.

For booking, ordering, membership and field-service apps, cross-platform is a sensible default. Go native when a specific feature requires it, not by habit.

How it relates to Worcia

Worcia's mobile apps service builds iOS and Android apps either cross-platform, with React Native or Flutter, or natively with Swift and Kotlin, chosen per project for your features, budget and team. For budgeting, read how much it costs to build an app, or see the customer booking app use case.