Native or Cross-Platform? How to Choose in 2026

Native or cross-platform is the question that shows up as a budget line, and in 2026 it shows up with a new temptation attached. A coding agent will draft the Flutter screen, or the second SwiftUI screen, before the meeting is over. The draft is not the decision. The decision is which of those screens you are willing to review, ship and keep.

We build both kinds of thing, and we say so on the home page as two offers rather than one toolkit. Native iOS is a direct build: I write it in Swift and SwiftUI, mostly with AI, and I review it before it ships. Android, and the rest of a dedicated seat, comes from the engineering team in Davao City, managed from Antwerp, joining your team and your sprints. This article is how we choose between a shared UI and a native one. It is not a ranking of frameworks.

What native or cross-platform is bundling

The phrase covers three different shapes, and quotes often use it for all of them.

• One UI toolkit for both stores: Flutter or React Native, with a native escape hatch where the toolkit runs out.
• Shared logic and two native interfaces: Kotlin Multiplatform, or Swift on Android beside a Kotlin UI. The screen is written twice. The rules underneath are not.
• Two native apps. Swift and SwiftUI on Apple platforms, Kotlin on Android, and nothing shared except the product decisions and the API.

The middle shape has its own article. Swift on Android, official since Swift 6.3, is a way to share Swift logic with a Kotlin app. It is not a way to ship one interface to both phones. Read that before you treat "Swift everywhere" as an answer to this question.

Swift on Android in 2026: a real option beside Flutter, React Native and KMP?

What agents changed, and what they did not

Drafting got cheap. Review did not. A second implementation means a second set of platform bugs, a second store listing, and a second person who has to understand the diff an agent produced. An agent that can paint both screens does not sit in the App Store review, and it does not notice that the Android back gesture and the iOS swipe-back are different promises.

So the 2026 version of this choice is not "which technology is best". It is "what do we already own, and what are we prepared to review twice". We will not tell you native is the cheaper build. Sometimes the shared UI is the honest scope. Sometimes it is how a one-screen prototype becomes two codebases you do not have the review capacity to keep.

The example we can show: FeedbackKit

FeedbackKit is our own product. It collects feature requests, votes and comments from inside someone else's app, so we do not get to pick that app's toolkit. The public repositories are the proof of how we handled that.

• A Swift SDK for iOS, macOS and visionOS, with drop-in SwiftUI views. The README says there is no watchOS or tvOS target.
• Separate SDKs for Kotlin, Flutter, React Native and JavaScript, published on Maven Central, pub.dev and npm.
• A Vapor SDK and a Hummingbird SDK, for a server-side Swift app that wants the same feedback API without a mobile UI.

What is shared is the feedback model: submit, vote, comment, status. What is not shared is the pixels. The admin app, the one our side uses to triage, is native SwiftUI on Mac, iPad and iPhone. That split is deliberate. A library that lives in a host app has to speak the host's UI. An app we own can be native, because we are the ones who will review it.

FeedbackKit on GitHub

The July article is the engineering of the loop itself, and a later one covers the on-device translation in the admin app. This post does not repeat either. It also states no minimum OS version: we have left that number out until the public pages agree.

Building an in-app feedback loop for your SwiftUI app

A way to choose

1. If the product is the Apple experience and Android can follow, start with native iOS. A second UI is a second review, even when an agent drafts it in a day.
2. If both stores have to ship in one release and the UI is ordinary forms and lists, a shared UI toolkit can be the right scope. Make the quote say which toolkit, and who reviews the native edges it cannot reach.
3. If you already have a Swift app, read the Swift on Android piece before you rewrite it. Sharing the business rules is a different saving from sharing the screen.
4. If you are embedding inside other people's apps, do what FeedbackKit does: one SDK per host toolkit, and a native app only where you own the screen.

What this article does not claim

• No measured comparison of Flutter, React Native, KMP and native Swift. We do not have one we would quote.
• No claim that agents made a native rebuild cheaper than maintaining the app you have. That decision has its own article.
• No client project. The only product in this post is ours.

If you want the native iOS half built directly, that is the offer with my name on it. If you want Kotlin, a shared toolkit, or a team that joins the repository you already have, that is the Davao team, managed from Antwerp. The quote should say which of those you are buying. The next article in this batch is about how to read one.

How to read an app development quote