When native wins over cross-platform frameworks

The short answer

Go native when the product itself is made of platform features. If the value of your app comes from what iOS or Android lets it do, a shared UI layer saves you little, because the platform-specific part is the product.

When native is the better choice

• Deep operating-system integration: Screen Time and app blocking on iOS, accessibility services on Android, widgets, Live Activities, App Intents and Siri shortcuts, or background processing that the system restricts tightly.
• New platform APIs from day one: a native app can adopt a new iOS or Android release the moment it ships, while a framework needs its own support first.
• A platform-native look and feel: SwiftUI on iOS and Jetpack Compose with Material 3 on Android follow each platform's design language and behaviour by default.
• Demanding graphics, camera, audio or sensor work, where you want the shortest possible path to the platform frameworks.
• The app is a long-lived core product, and the team will keep investing in each platform for years.

What AI-assisted development changes

The classic reason for cross-platform was cost: one codebase instead of two. Code is now written much faster with AI assistance, and a second implementation that follows a finished first one is a task AI tools do well. The saving from sharing a codebase has shrunk, while the price of a second native app has dropped.

Review and testing still take human time on both platforms, so native is not free. But for products that need native quality anyway, the cost gap is now small enough that it should not decide the question.

A real example: Momento

Momento, AppJoy's own app, asks why you are opening an app before it opens. On iOS this relies on the Screen Time API, plus widgets and Live Activities. On Android it relies on an accessibility service. AppJoy first built it with Flutter and then rewrote it as a SwiftUI app and a Kotlin app with Jetpack Compose, because the core of the product is platform-specific and the shared layer would have been thin.

When cross-platform still wins

• You need a website and an app that share code, as with HighratedHotels on Expo and Next.js.
• The interface is custom-designed and should look identical on both platforms.
• Hardware access is the main need and a good plugin exists. caberQU talks to its device over Bluetooth Low Energy from a Flutter app, so Bluetooth alone is no reason to go native.
• Budget or time is tight and the app is a standard business app.

Questions to ask before you decide

• Which features only exist on one platform, and are they the core of the product?
• Do you need a website that shares code with the app?
• Who will maintain the app in two years, and which skills do they have?
• Is a prototype in one framework enough to find out? A rewrite is possible, as Momento shows.