For a long time, cross-platform app development felt like choosing the least painful compromise.
You could maintain separate native apps for every platform and duplicate a lot of logic. Or you could use a cross-platform framework and accept its trade-offs: runtime overhead, abstraction leaks, slower access to new platform APIs, and an app that sometimes felt native-adjacent rather than native.
Electron, Capacitor, CEF, React Native, Flutter, and Compose Multiplatform all solved real problems. They still do. The point is not that these tools are bad.
The point is that the center of gravity is shifting for a certain class of apps: developer tools, terminals, editors, local-first software, creative tools, and other products where performance, platform feel, and long-term control matter.
A different architecture is becoming more practical:
one shared systems-level core, surrounded by thin native UI layers.
The core is usually written in Rust, Zig, C++, or another systems language. It owns the hard, reusable parts of the product: state, persistence, sync, parsing, rendering primitives, business rules, protocols, file formats, and tests.
Each platform then gets a small native shell:
- macOS gets SwiftUI/AppKit.
- Android gets Jetpack Compose.
- Linux gets GTK, Qt, or another native toolkit.
- iOS gets SwiftUI/UIKit.
- Web may get WASM where it makes sense.
The UI layer becomes mostly presentation and platform integration. The product logic lives in one place.
That distinction matters.
The cost of owning the entire UI stack
Recent developer tools show both sides of this trade-off.
Zed built GPUI: a custom GPU-accelerated Rust UI framework with its own rendering, layout, input, and text infrastructure. Warp built a custom Rust-based UI stack with GPU rendering to deliver its block-based terminal experience.
These are impressive engineering efforts. They also show how expensive this path can become.
Once you build your own UI framework, you are no longer just building your product. You are also maintaining a rendering engine, text system, accessibility story, windowing layer, input model, drag-and-drop behavior, platform backends, and all the edge cases that native toolkits have accumulated over decades.
That cost is sometimes worth paying. Zed and Warp are deeply UI-driven products. Their performance goals and interaction models may justify a custom stack.
But it is not a small decision. “We need it to be fast” can easily become “we now own a cross-platform app framework.”
That is a very different business.
Ghostty is the more interesting counterexample
Ghostty takes a different approach.
The complex terminal logic lives in a shared Zig library: libghostty. The platform UI remains intentionally native and relatively thin. On macOS, Ghostty uses Swift with AppKit and SwiftUI. On Linux, it uses Zig with GTK4.
That architecture is not as glamorous as inventing a new UI framework. But it is extremely pragmatic.
Ghostty still gets native platform integration. It still gets high performance. But it avoids reimplementing every primitive of desktop UI from scratch.
The key idea is not “write everything once.”
The key idea is **reuse the parts that should be shared, and keep the parts that should feel native close to the platform.
That is a much healthier abstraction boundary.
The browser engine is not always the right abstraction
Electron won because it made shipping desktop software dramatically easier. It gave teams one UI technology, one rendering model, and access to the web ecosystem.
That was a good trade for many products.
But for performance-sensitive tools, bundling an entire browser engine can feel increasingly heavy. You inherit memory usage, startup cost, packaging weight, and a layer of indirection between your product and the operating system.
The alternative is not necessarily “go fully native everywhere.”
The alternative is to ask a more precise question:
What part of this application actually needs to be cross-platform?
For many apps, the answer is not the UI.
It is the core.
The parser.
The sync engine.
The storage layer.
The protocol implementation.
The terminal emulator.
The indexing engine.
The collaboration model.
The domain logic.
Those are the parts that benefit most from being shared, tested once, and reused everywhere.
The buttons, menus, windows, gestures, shortcuts, permissions, notifications, file pickers, accessibility behavior, and platform-specific affordances often benefit from being native.
FFI is getting good enough
This architecture used to be painful. The boundary between a Rust or Zig core and Swift/Kotlin/native UI code was full of manual glue, unsafe edges, awkward type mapping, and build-system friction.
That is changing.
Mozilla’s UniFFI has made Rust shared components more accessible by generating bindings for languages like Swift and Kotlin. BoltFFI is a newer project pushing in the same direction with a focus on lower overhead and more native-feeling generated bindings.
The tooling is not perfect. FFI still forces discipline. You need to design stable APIs, think carefully about ownership, threading, async boundaries, error types, and data serialization.
But it is no longer exotic.
A small team can now realistically write a core library in Rust or Zig, generate bindings, and expose a clean surface area to native UI code.
That changes the economics.
AI makes the thin-layer model more practical
There is another under-discussed reason this architecture is becoming more attractive: AI reduces the maintenance cost of thin platform layers.
If the core behavior is already implemented and tested, the native UI work becomes more mechanical. A developer can build the feature on one platform, then use an AI agent to draft equivalent SwiftUI, Compose, or GTK changes for the others.
This does not remove the need for platform expertise. Generated UI code still needs review. Native details still matter.
But it changes the ratio.
Maintaining three thin native shells is much less scary when most product behavior lives in a shared core, and the platform-specific code is small enough to review carefully.
AI is bad at replacing product judgment. It is much better at translating known patterns across similar surfaces.
That is exactly where thin native UI layers fit.
This is not a universal replacement
There are still many cases where Electron, Flutter, React Native, or KMP are the right call.
If your team is web-heavy and needs to ship fast, Electron may be the pragmatic choice.
If your product is mostly forms, dashboards, or CRUD workflows, a cross-platform UI framework may be more than good enough.
If your UI itself is the hard part, a custom rendering stack may be justified.
If your team does not want to own systems-level code, a shared Rust or Zig core may create more problems than it solves.
The shared-core/native-shell model is not free. It asks you to own more of your architecture. It rewards teams that care about API boundaries, testing, platform conventions, and long-term maintainability.
But for the right category of software, it is a compelling middle path.
You do not have to duplicate your entire app.
You do not have to bundle a browser.
You do not have to pretend every platform is the same.
You can share the engine and let each platform be itself.
That is the interesting shift.
The future of cross-platform software may not be one framework that abstracts every platform away.
It may be one core that gives every platform something native to wrap.
Top comments (0)