[lachenmayer]

Flutter suffers on iOS because it completely takes over the render surface (ie. it renders everything using Skia), and doesn't offer any escape hatches for native components. In a way, this is an amazing approach: it completely sidesteps a lot of the platform-specific woes that plague React Native, and makes it much easier to support completely new platforms (ie. if you can get Skia to run on it, it can probably run Flutter).

But particularly on iOS, the native components have some incredibly subtle behavior (eg. the "fling" gestures from UIPageViewController, the native modal animations, overscroll, etc.), and these are extremely difficult to get right.

React Native's story for native inter-op has recently become miles better with JSI, which allows native<->JS FFI at much better performance than the previous approach. This has enabled libraries like Reanimated 2 (https://www.reanimated2.com/) and Gesture Handler 2, which take full advantage of this and get React Native apps tantalizingly close to "truly native"-feeling.

[HillRat]

My former firm put a lot of effort into Flutter as a preferred alternative to RN or native app dev -- including standing up a lot of onshore/nearshore/offshore experience -- but we never were able to to make it a viable alternative on anything other than small or trivial apps, due generally to performance problems, weird iOS corner cases, hard-to-debug crashes arising from deep within the framework, and sharp edges on their emulated components. From a governance perspective, we ran into difficulty rapidly spinning up new dev capacity relative to RN (where you can have a web developer productive within a few days, as long as they've got a mobile dev running their pod to oversee integration and build). I'd love to see Flutter become a strong alternative, but I'm not sure Google is willing to drop enough of its NIH syndrome to meet developers where they are, rather than where they want devs to be; until then, it's a tech to push further out on the radar until it's more battle-tested, especially on iOS.

[enos_feedler]

While Flutter and RN might be improving in many ways, it feels like the risk/reward tradeoff is actually getting worse for using a unified app layer. The underlying platforms getting easier to use themselves (Kotlin, Swift, SwiftUI, Jetback, etc) and the developer market getting stronger skill-wise at developer apps. There is more of a consolidation of best practices etc. The reward for building a single codebase becomes very low, but the risk is remaining high. You are adding a layer of indirection and dependency right in the middle of the platform. You basically cannot evolve at the speed of the platform. Sometimes platforms move fast and you want to capitalize on change. This always made it seem like non-starter for me.

[travisgriggs]

This mirrors our experience as well.

[sarsway]

A few years ago I would have agreed that the native subtleties must be a top priority for user experience, but these days I don't think it matters that much anymore.

Flutter's UI can't match native components exactly, but they do a very good job, and I don't think the vast majority of users would be able to notice the difference or cares that much.

The reality is, the native UI homogeneity is long dead anyway. Every app, website, brings it's own set of UI components and styling. It's all inconsistent and people are used to it.

It really does not matter whether your modal dialog is native or not, as long as it follows basic abstract UX conventions of looks and behavior.

[Steltek]

Native UI parity went extinct because platforms kept changing UI guidelines in every major release to keep things feeling "fresh" and new. A native app might inherit a lot from the toolkit but it'll still look weird without an update.

At some point, you're better just doing your own thing rather than be dragged around on the leash of some product manager looking to make a splash at the next conference.

[dmitriid]

> I don't think the vast majority of users would be able to notice the difference or cares that much.

Users do notice these things. They just can't explain it in technical terms like "i feel like this app is built with a non-native toolkit that is why animations are wrong".

They explain it as "this feels off" and "why doesn't it run like X" and "I don't like it" etc.

[burke]

I kind of disagree. I don't mind apps that bring their own visual styling and don't reuse OS components/styling, but I get _really_ annoyed by apps where gestures behave slightly differently. Things such as the exact tolerances required to activate the "fling" getsure, or to swipe from the edge, are really frustrating when they're not quite right. Beyond basic conventions, the minute details of how the user input/output responses work are really really important.

[vineyardmike]

No. I'm a hardcore iOS user and i can recite off-hand specific apps that run "wrong" and why i hate using them (because if their UI). I tend to actively minimize using them when possible too. If your app doesn't support the "scroll to top" gesture when i tap the top bevel of my screen, i will stop using it if i can find alternatives.

Yes, i know that it runs wrong because its ReactNative and not SwiftUI, but you don't need to know why its wrong to know its wrong.

Eg: Alexa App doesn't go back a frame when you swipe from left, you have to click back button.

[saurik]

> ...doesn't offer any escape hatches for native components...

Lest anyone read this the wrong way: you absolutely can embed native components in your Flutter app. They have a scheme called "platform views" that involves splitting the scene hierarchy above and below a native component, and this is used for stuff like web views or map controls that are firmly native components which people want to drop into their app.

[rkangel]

> it completely sidesteps a lot of the platform-specific woes

This is the key point where Flutter wins over both React Native but also the native Android and iOS toolkits. When you design a screen in Flutter, it will behave as you expect on every different version of Android and iOS. You just check it does the right thing as screen size changes (which is usually pretty easy to implement, and very easy to test) and then you get predictable behaviour. It is so rare that you need to fix X screen on Y phone running X version of the OS because it has odd behaviour, and that happens all the time with any of the native toolkits.

That said - I haven't used Swift UI, so it's possible the situation has improved (although I wouldn't bet on it).

[novok]

SwiftUI is still incomplete IMO. It has perf issues and bugs still. Needs a few more years or to stop wrapping UIKit.

[samwillis]

Last year I was looking at using Flutter for something that needed extensive use of a WebView, I very quickly came to the conclusion that they are having massive difficulty to get it working well due to the Flutter architecture. It looks like the situation has improved but just look at the web_view issues, there are a lot of them:

https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3A...

A lot of apps end up using at least one if not a lot of web views, I probably wouldn't use Flutter because of it.

[onli]

If you can control the HTML, https://pub.dev/packages/flutter_html works pretty good.

[Eric_WVGG]

Thank you for taking the time to write that.

I was gonna say, “look, Flutter looks like peering at a screen through a fishbowl, responds like your hands are in some kind of jelly glove, and feels like you’re two martinis into happy hour,” but technical responses are of course better appreciated with this crowd.

[seany]

Corona (now Solar2d) does this as well. Lua into a opengl 2d space.