6 ms·

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 nati

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/ 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.

Eric_WVGG 5y ago
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.
samwillis 5y ago
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%3Aopen+label%3A%22p%3A+webview%22 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 5y ago
  If you can control the HTML, https://pub.dev/packages/flutter_html https://pub.dev/packages/flutter_html works pretty good.
  - samwillis 5y ago
    That does look good if you have control and its somewhat simple html. The particular use case I was looking at was integrating a web based rich text editor based on contenteditable. It had to be a proper webview, and the issue is that the interaction with the text (cursors/selection/typing/onscreen keyboard) was completely broken.
sarsway 5y ago
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.
- dmitriid 5y ago
  > 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.
  - thehappypm 5y ago
    Exactly this. For example when I started playing Wordle the first time, I was like what is this keyboard this just feels kind of odd!
  - mariodiana 5y ago
    I think long-time users of Apple's various platforms will notice, especially. I bought my first Performa back in 1996. That old OS -- especially up against Windows 95/2000/XP apps -- conditioned people to be UI snobs. If I download an app from the App Store, and something rubs me the wrong way within the first few seconds, I will almost always ditch it. I want a native experience, and I don't think I'm alone.
    - Steltek 5y ago
      It boggles my mind that anyone invests precious time and effort chasing such a fickle group of users. Anything less than Apple's vision of perfection and harmony or you'll be dumped in a heartbeat. "Think Different" indeed.
rkangel 5y ago
> 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 5y ago
  SwiftUI is still incomplete IMO. It has perf issues and bugs still. Needs a few more years or to stop wrapping UIKit.
- The_rationalist 5y ago
HillRat 5y ago
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.
- travisgriggs 5y ago
  This mirrors our experience as well.
- enos_feedler 5y ago
  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.
  - nsonha 5y ago
    there are developers who are just happy to write the same logic in multiple languages, and there are those who find it extremely mind-boggling, this is regardless of how nice/easy to learn those languages are.
saurik 5y ago
> ...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.
seany 5y ago
Corona (now Solar2d) does this as well. Lua into a opengl 2d space.

Eric_WVGG 5y ago

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.

samwillis 5y ago

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%3Aopen+label%3A%22p%3A+webview%22 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 5y ago
If you can control the HTML, https://pub.dev/packages/flutter_html https://pub.dev/packages/flutter_html works pretty good.
- samwillis 5y ago
  That does look good if you have control and its somewhat simple html. The particular use case I was looking at was integrating a web based rich text editor based on contenteditable. It had to be a proper webview, and the issue is that the interaction with the text (cursors/selection/typing/onscreen keyboard) was completely broken.

sarsway 5y ago

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.

dmitriid 5y ago
> 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.
- thehappypm 5y ago
  Exactly this. For example when I started playing Wordle the first time, I was like what is this keyboard this just feels kind of odd!
- mariodiana 5y ago
  I think long-time users of Apple's various platforms will notice, especially. I bought my first Performa back in 1996. That old OS -- especially up against Windows 95/2000/XP apps -- conditioned people to be UI snobs. If I download an app from the App Store, and something rubs me the wrong way within the first few seconds, I will almost always ditch it. I want a native experience, and I don't think I'm alone.
  - Steltek 5y ago
    It boggles my mind that anyone invests precious time and effort chasing such a fickle group of users. Anything less than Apple's vision of perfection and harmony or you'll be dumped in a heartbeat. "Think Different" indeed.

rkangel 5y ago

> 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 5y ago
SwiftUI is still incomplete IMO. It has perf issues and bugs still. Needs a few more years or to stop wrapping UIKit.
The_rationalist 5y ago

HillRat 5y ago

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.

travisgriggs 5y ago
This mirrors our experience as well.
enos_feedler 5y ago
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.
- nsonha 5y ago
  there are developers who are just happy to write the same logic in multiple languages, and there are those who find it extremely mind-boggling, this is regardless of how nice/easy to learn those languages are.

saurik 5y ago

> ...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.

seany 5y ago

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