The best option is probably Flutter right now: https://flutter.dev/

If you don't mind writing the UI native, sharing only business logic code, Kotlin is an option: https://kotlinlang.org/docs/multiplatform.html#kotlin-multip...

Kotlin also can do the UI if you use Compose: https://www.jetbrains.com/lp/compose-multiplatform/ ... however, iOS support is still in alpha, and Web is "experimental". If you're not willing to cope with that (expect to have to change your code as they develop the framework) then Flutter is the way as it's pretty stable already on all platforms.

If you already know Typescript and React, you may also consider React Native (but I can't attest to its performance on iOS or anywhere else): https://reactnative.dev/

FYI. Much of the Flutter team is laid off by Google recently and it will be soon added to the killed by Google list. Afaik, there is no future for it and Google is not looking to build anything cross platform like earlier plans

https://www.reddit.com/r/FlutterDev/s/7z3xDQeZeG

That's unfortunate. I actually liked Flutter.

Don't worry, it's a lie.

Until it isn’t. Too much faith on Google.

C'mon, just because they lied 295 times before doesn't mean they'll do it again. =)

I think they are just outsourced

First comment on that Reddit thread:

---

Hey folks! Kevin, product manager on Flutter and Dart here.

The layoffs were decided AT LEAST a couple of layers above our team and affected a LOT of teams. (I think I can say that). Lots of good folks got bad news and lots of great projects lost people. Flutter and Dart were not affected any more or less that others. It was a tough day...tough week.

It was crazy to be seeing demos and new things working and discussions about new customers the same day we lost colleagues and friends.

We're sad, but still cranking hard on I/O and beyond.

We know ya'll care SO MUCH about the project and the team and the awesome ecosystem we've built together.

You're nervous. I get it. We get it.

You're betting on Flutter and Dart.

So am I. So is Google.

Building anything on top of Google tech that isn't Android or GMail is a huge risk, and the fact that the higher-ups will just randomly decide to fire large parts of teams confirms that caution is the right approach.

That's so true. They have built a reputation for killing stuff.

Reddit post from Project Manager is pretty pointless. If Google decides to get rid of Flutter, they are not going to tell Kevin before hand, they are likely not even going to tell Kevin boss before hand. Stadia employees were swearing up and down that Stadia was full steam ahead despite layoffs until it wasn't. When it happened, it was clear from all Twitter posting that no one except really high up Google Executives knew Stadia shutdown was coming and they didn't tell anyone.

True, but you could say the same thing about anything. That does not help anyone.

It does help. Words mean less than action. If random people are killed from a division due to decisions "many layers above" it means that division is really not valued. Google will kill off flutter in the future. One should not be building long term apps on it. React native and react luckily have been taken over by the open source community and will live long. Shame though, I really liked flutter. Fuck Google.

Not always, if Google Cloud CEO came out and said "We are invested in Flutter", I'd give it more weight since he has real power at Google.

I'm just saying Kevin statement is meaningless. If you look at Google actions before, they do not slowly remove support from things and announce it. They silently layoff, go quiet then BAM, X is gone without warning and little time to deal.

The doom and gloom comes from much the same pontificating and rumormongering. Except somehow less official, and that's what you want us to go with?

Doom and gloom comes from everyone who has followed Google history. Google does not do what I call "Enterprise orderly shutdown of services" which is decrease releases/features, announce depreciation, give shutdown date and shutdown. They just do layoffs, radio silence and BAM, SHUTDOWN!

The Stadia people were saying the same thing up until the day they were shut down.

Was Stadia the #1 online game streaming service at the time? It's rhetorical.

> You're betting on Flutter and Dart.

> So am I. So is Google.

RIP Dart and Flutter.

That's definitely not true as of today.

There were some rumors that made people think of the worst, and as we speak about Google, a lot of people panicked that Google is dropping Flutter.

However, that was not the case.

They moved some roles to new locations, meaning (they claim) the team size change is net zero. https://x.com/MiSvTh/status/1785767966815985893

I get your frustration. Google just killed two of my favorite products this month (or more accurately, I found out about them this month), and then I heard about the Flutter downsizing rumors. I worked with Flutter for years now, and I decided that I can't let my professional fate in a company like that and started learning something new to switch to. Even if today it looks like they let Flutter live, it's better be prepared and pack up while I can leave on my own terms.

Downvoted you because the top comment in the link straight up goes against your comment. I hope you’re not spreading FUD on purpose.

Quit spreading lies about Flutter. It’s one of the most popular cross platform development environments, if not THE most popular, out there and that’s not going to change anytime soon.

So what if it’s popular? It’s a revenue driver and majority of development is still made by Googlers, as far as I know. If tomorrow Google drops all development, who’s going to pick it up? Or in your opinion GitHub stars would prevent them from dropping it?

maybe Ubuntu? the web development flow (so closely tied to firebase) might suffer a little bit, but I imagine a fork for non-web env's would be quick and welcome

People keep saying this about Go in every new Go version post and they keep getting disappointed. If you don't like Google languages, products or services then just quit using them and move on to something else.

> If you don't like Google languages, products or services then just quit using them and move on to something else.

Already did 5 years ago.

I stopped trusting Google's judgement of products when they killed both Reader and Wave.

My grandfather told me about the Reader shutdown.

Those that do not learn from history are condemned to repeat it.

Reader extension(s) for Chrome are fine replacements.

Ok this is good to know. Man I thought for a moment flutter will be something Google doesn't kill but no. They are such shareholder automated processes driven that they are imploding from the inside. I'll switch to react native unfortunately. Flutter is definitely better tech but betting on any product from Google is a death knoll.

If you use oidc, you can't use Flutter with web or desktop as build targets. It requires a feature that isn't supported by Flutter on those platforms.

The one flutter website I have come across is an absolute piece of garbage. Completely destroys the ability to modify or even inspect the HTML source. See for yourself

https://sunrisetv.ch/de/vod/1/details/vod/crid:~~2F~~2Fog.li...

You can export the flutter build as HTML, but the point with flutter is not to be a ”website”, it’s supposed to be seen as a ”web-app”.

If you are going to create simple static homepage or interactive website, I don’t think Flutter is the right tool. Full fledged cross-platform applications is what Flutter is meant for.

I agree, who cares if a website supports accessibility, no one in the world is vision impaired and uses screen readers right? right?

That's not even my point.

Websites should still support accessability, I would even go as far to say it's a must. I just don't want people to mix up web-applications with websites. I've seen some people create a simple "websites" with Flutter which is totally pointless because it could just been created with html + css.

There is also a section in the Flutter docs that talks about accessability and how you can create accessable apps but I don't know how well it translates to Flutter web.

https://docs.flutter.dev/ui/accessibility-and-internationali...

Why would the ability to modify HTML matter at all? Most users don't even know what HTML is, much less how to open the dev console.

Yeah, why does it even matter if you can control a page? Let’s just make it a fucking canvas, power users and those who care about web experience can go to hell.

Regular users know how to install an extension that interacts with the DOM, though

And it has laggy scrolling. What’s the benefit?

I would also add Tauri to the list as they now support mobile as well https://v2.tauri.app/blog/tauri-2-0-0-beta/

I think all cross platform frameworks come with some kind of drawbacks and in most cases, learning about the underlying native platforms is unavoidable (like widgets, visionOS support etc).

So I wouldn’t worry too much or get into a FOMO decision block - I’d pick the one that feels most fun and fits your use case.

A long time ago, nativescript[1] seemed to be a strong alternative to reactnative. Is that still the case?

[1] https://nativescript.org/

I would say React Native with all the Expo stuff. While Flutter is okayish, web is bad in terms of feel and accessibility since it renders to a canvas. Also, iOS still has issues with lag even after introducing Impeller rendering engine.

Look at Bluesky's client. The app performs decent on all supporting platforms and has single codebase.

https://github.com/bluesky-social/social-app

I tried quite a lot of multiplatform frameworks in the context of mobile, and for me Flutter is in a completely different league than the rest of them. I really love it.

What's your definition of decent performance?

My company has built quite a few complex capacitor + Angular + Ionic apps and the performance on iOS is fine. Some even got featured by Apple, so that should be some indication that quality and performance was alright.

We use Tauri, but I think that it’s important to know that we solely use it for internal tools. I have no idea if it’s a good tool for consumer facing products. It works well enough for what we use it for, which is mostly for our solar park technicians where using cross platform Typescript on terrible internet became too much work for our small team.

We use Tauri at GitButler and love it.

Agreed. Tauri for desktop, capacitor for mobile. Bring your own front-end library either way.

Flutter is so far in front of anything else out there I think at the moment.

In Go land, there's Wails

https://wails.io/

What are all the target platforms? The website doesn't have a list, or I'm unable to find one.

EDIT: never mind, I found it https://wails.io/docs/reference/cli#platforms

It doesn't seem to support Android, IOS or web.

Wouldn’t those be the server platforms?

Aren’t those platforms for the dev machine on which you would write the code and build you app?

Edit: looks like it’s for the server machine

My team achieved better than native performance using RN when rewriting a very large iOS app. And that was in 2018, before Hermes and a lot of other optimizations.

It takes some careful usage of requestIdleCallback and avoiding doing work in the UI thread but it is not rocket science. You do have to avoid a lot of the going advice and bloated libraries / frameworks though.

| better than native performance

Maybe better than the native you had before the rewrite lol

“The app we had before” had 50M+ users, developed by a large iOS team, including a lot of experienced developers working on performance, and generating billions. I think it was a valid baseline.

> better than native performance using RN

You had an app written natively in Objective-C or Swift, switched to single-threaded javascript React Native, and then your app ran faster?

Unoptimized native application, probably written in a yolo let’s ship it faster way, is slower than rewrite that learned from mistakes of previous application. What makes you surprised?

Though JS is single-threaded, it only builds the render tree and is more than fast enough if you’re careful. RN has a separate UI thread for actual rendering, I/O is offloaded and extensions can use extra threads.

The largest bottleneck historically was the bridge between obj-c and js (now superseded by JSI), and not the speed of the engine itself.

Businesses do seem to like AvaloniaUI and Uno.

https://avaloniaui.net/

https://platform.uno/

Thanks, which of the two would people recommend for a C# beginner? And is oidc well supported on all target platforms?

If you are to use Avalonia, which I highly recommend, it may be best to start with WPF. The Visual Studio Community Edition has really good IDE support for WPF and there is a huge amount of information on how to do things in WPF which thankfully hasn't changed in a very long time. Plenty of old books and blogs that go into all manner of detail. Once you have what you wanted working as you want it is straightforward to port the WPF to Avalonia for cross platform support.

Yes this would necessitate using Windows, an OS which I abhor, but as of now . In time I hope that will change with improvements in both JetBrains Ryder and Avalonia.

Both frameworks have various packages that add OIDC support to them so that shouldn't be an issue.

As for beginner - there's quite a bit of learning curve in terms of writing GUI applications themselves. Avalonia is kind of like WPF* but good(tm) and cross-platform. Uno platform is more like Xamarin and MAUI except in a better shape as of today. From technical perspective, Avalonia focuses on consistent rendering on all platforms with Skia while Uno tries to use native controls instead. I generally would not advise using Avalonia for mobile over Uno. In mobile case you might actually want to also give MAUI a try as, despite harsh criticism it has been receiving, it has improved significantly.

* either platform supports various declarative UI libraries (that are either part of their ecosystem or community-maintained), so you are not married to XAML thankfully.

That's a great answer, very helpful. I just picked up Avalonia for a test drive. Why do you think Uno is better than Avalonia for mobile?

Performance on mobile devices and UI libraries. Avalonia ecosystem is predominantly focused on desktop, which is not the case for Uno. But I liked the fact that setting up and AOT compiling Avalonia templates was a breeze so use it for side projects. For something more serious that has to target mobile, I would investigate how much MAUI has progressed in terms of quality and if problematic, would just go with Uno.

I’m getting on pretty well with Ionic + TypeScript, using React and Redux. Performance hasn’t really been an issue, although I’m also not doing anything that performance heavy. I’d recommend it. I like that it ends up being comprehensible HTML + CSS, as well as simple React that I’m already comfortable with and can debug.

For the last 4 years the answer is Flutter.

Has been posted here before also, so adding it for people not aware of it already - https://areweguiyet.com

Native UI for anything that requires polish. I’ve been through too many iterations of frameworks that promise everything and don’t deliver. You’re up and running faster, then soon after you’re patching the core libraries after an OS update to try to get the FPS closer to native, or match a system animation more closely. The time saving only exist if you never polish your UI.

Core logic can be shared. I use gomobile - mostly love it but 3mb overhead for runtime (so not for web). Kotlin multi platform looked good, but I found it missing pretty basic libraries (which exist for Kotlin Android, so no one is building multi platform equivalents). Rust with Mozilla’s language binding layer looks good but I haven’t tried it.

I don’t think that premise of “native UI for anything that needs polish” is true these days.

Canonical the company behind Ubuntu have said for some time now that all future app UIs of theirs would be done in Flutter starting with the very first thing people see the installation process.

Google just rewrote Google Earth’s UI in Flutter.

BMW are doing all of their in-car entertainment systems in Flutter.

Are any of those better than the alternative, or just cheaper?

I suppose if the alternative is “this only exists on one platform” or “this doesn’t exist at all” then maybe, but I find it a bit sad how keen we are as a profession to accept compromise and mediocrity to save developer time and expense.

I get it, but I don’t like it.

2/3 of those examples had no requirements for cross platform and still chose it anyways. Additionally all 3 of those examples decided to take what they already had with native and decided to rewrite it because of the benefits.

I’m saying the “gap” between Flutter and native in this case is much much much smaller than you seem to think it is. Quite a bit has changed there in the past year or two.

That isn’t my opinion but that was the result of many major and very competent teams coming to that conclusion and putting their money where their mouth is in order to substantiate the claim.

Two of the examples mention are platform providers. If they standardize on flutter as their native UI, that’s fine and they are following my suggestion. If they port a BMW app from my dashboard to iOS / Android, I’m 99% sure you’ll see the issues I mentioned.

Google earth is fine, but doesn’t feel native. I think that’s fine for some apps (games mostly).

Could you maybe provide a single clear example of how Google earth doesn’t feel native?

Welcome screen was a popover on iPhone (only available on iPads, should be a sheet on iPhone), with rounded non standard button and non standard horizontal lines.

“Signed in as” toast wasn’t designed for iOS rounded bottom and “swipe up” bar leaving ugly stripe.

Sheet easing is off, and FPS stutter.

No swipe from left to go back support.

Non standard animations all over. Visible FPS issues (on newest HW)

I could go on and on. Feels like an android app running in an emulator.

I think several of your examples appear to be confusing Google’s material design system with the frameworks capabilities.

You asked how it doesn’t feel native. Using a design system from a different platform, and not complying with the interface guidelines of the current platform, is a big part of not feeling native.

And the frame drops and lack of system gestures, and lack of standard nav stack are major infractions on usability outside of design.

You already answered your own question imo. The web is the best thing we have so far and nothing comes closer to the full package. It literally is write once and write everywhere.

All the other alternatives are young frameworks that have not been battle tested and have weird quirks once you want anything relatively complicated.

> what's the best method to build cross-platform mobile & web apps nowadays ?

Uno (https://platform.uno):

* open-source

* targets Android, iOS, Windows, Mac, and Linux (https://platform.uno/platforms/)

* C#

* automatically implements views and controls using each platform's native UI frameworks

* good IDE support: Visual Studio, VS Code, Rider (though you are not limited to those)

* Figma plugin for design collaboration

Also in the .NET world, Maui Blazor Hybrid is interesting. Uses HTML and the platform-native web renderer for the front end, and compiles to native code (not WASM)--i.e. clicking a button on your HTML invokes native code. Depending on your front end library, the app will look and feel more or less like a native app or web app.

An older article but puts it in context with Electron and how they differ https://www.codemag.com/Article/2111092/Blazor-Hybrid-Web-Ap...

I mean I guess that's fine if you're into .NET but how about those who prefer to avoid that

Why would you avoid .NET?

Not generally a huge fan of locking myself into Microsoft platforms

If you mean windows, it has been so many years since .NET has been able to run on many different platforms; and by now, most of the ecosystem supports majority of platforms too..

You get an amazing runtime with near native performance, access to value types, no type erasure, access to low-level operations when utmost performance is needed, very good cross platform and architecture SIMD support, three different great IDEs with two of them being cross-platform, AoT compilation that keeps getting better, WASM target with a good framework (Blazor), and so on.

Modern .NET is truly amazing and highly undervalued IMO.

It's all open source, Native AOT, batteries-included stdlib. A very productive and well rounded platform.

Flutter

Expo targets iOS, Android, web.

For mobile, this looks promising: https://skip.tools

Transpiles SwiftUI over to Kotlin/JetPack Compose. Native all the way down. Haven't used it in production, but the demos work and are native after going through XCode and Android Studio.

> first-class development environment (Xcode)

this made me lol. As somebody who does mobile dev professionally, the worst thing about iOS dev is how terrible XCode is compared to Android Studio.

There's no way I would want this.

I tried React Native, but ended up re-writing and going with SolidJS + Capacitor, and I love the setup. I've barely thought about performance since switching, people think the iOS/Android apps feel native, there's almost never any differences in behavior between the platforms, it's a fantastic setup for a solo dev.

I would mention as an alternative QML, although I wouldn't claim it is the "best method". It's marketed as being mobile-capable, but I've heard problems about scrolling inertia and vsync delays.

I'm curious to know what others think about it.