Hacker News Reader

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.

This mirrors our experience as well.

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.

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.

I can understand for combersome shared logic.

Nobody is happy to write the same logic in multiple languages. There are other ways to package logic and have it be consumable by multiple teams building native mobile apps for various platforms. If you are trying to solve this by very specific problem by adopting something like React Native or Flutter then I would question many other things beyond this.

> There are other ways to package logic and have it be consumable by multiple team

Really what way? Make a backend endpoint? Convert to C++ and invoke as native code? I'm only speaking for react native it's more than sharing code it's sharing skill, a web/nodejs dev can learn it and jump on company's mobile app when needed, as opposed to have dedicated devs for Android and iOS who sit around doing nothing sometimes and stop company from shipping when they go on vacation.

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.

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

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!

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.

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.

The people willing to put up with mediocre and bad software aren't willing to spend money on it either. Just look at the revenue gap between iOS and Android. It makes sense that people put time and effort into pursuing the fickle users willing to pay money.

> It boggles my mind that anyone invests precious time and effort chasing such a fickle group of users

This "fickle group of users" is eager to spend money, moreso than other groups of users.

It's not "fickle" to want competently built apps made by developers who respect their users.

Or, you know, developers could be thoughtful enough to create a half decent UX. That's not asking for a lot.

I'm happy a significant portion of consumers have been trained to expect better than the bare minimum in terms of UX.

Look how loyal those users are. If you can keep them long enough... they may develop their own loyalty to you.

Also they're rich.

If you've been around that long, you know that Apple changes their UI guidelines sometimes and not always for the better. I no longer know what a "native experience" is supposed to be. (I haven't even used Monterey yet.)

Yup, the downfall of Apple's UI is obvious, public, and heat-breaking.

This is valid criticism. Apple's taste isn't what it used to be.

And then Kai's Power Tools came along with its completely unique UI and everyone loved it. And other developers decided to emulate that idea - that a funky UI is a differentiator.

I don't think it's fair to blanket blame Flutter though. What you are noticing are poorly made apps. What you are not noticing are well made Flutter apps, that are almost indistinguishable from native apps. I guarantee you we all interact with way more different UI frameworks then we are aware of on a daily basis.

Some apps also fail by trying to emulating native UI so hard, when it would be better advised to just adopt a more abstract style. Today's flat UI is just simple shapes after all.

From technical a standpoint, Flutter definitely is performant, capable of delivering smooth scrolling and 60 fps. Your experience may vary of course, but I've been shipping an app with it for 2 years now and things been working out well. Can only really say great things about it.

> What you are not noticing are well made Flutter apps, that are almost indistinguishable from native apps. I guarantee you we all interact with way more different UI frameworks then we are aware of on a daily basis.

That is, indeed true. So the question becomes: does the framework nudge you towards and help you with making well-made apps almost indistinguishable from native apps, or the opposite :)

I'd wager these sentiments have more to do with performance/responsiveness than they do with whether or not UI elements and animations are system defaults. Pretty much every wildly popular application in the market has a totally custom UI.

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.

I develop with React Native in my day job and I'm observing all the UI changes that are happening in the systems. So far there aren't many problems with the differences, for example in the alpha version of Android 12, Google introduced a sparkly ripple effect (they eventually removed it again). But this change was automatically propagated to all our interactive components of our React Native app, no changes to our codebase necessary. And this is the case for many other changes, since React Native uses actual native elements.

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.

I hate when apps implement the swipe-back gesture for anywhere on the screen, rather than just the left edge.

It’s far too easy to be scrolling, accidentally go slightly too horizontal and end up popping the view and losing your place.

I hate it when swipe is inconsistent. Even using two Microsoft products (Todo and Outlook) on my iPhone, in Outlook you swipe right to delete a message from the list, in Todo you swipe left to delete a task from the list :-/ . Lucky "undo" is easy to find.

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.

In the React Native app I'm working on, I actually noticed this gesture on an iOS simulator (I didn't know about it before) and it worked well. React Native uses native components to render the UI, but it uses JS for the logic of what and where should it put the native components. I think this might be an issue in Flutter though.

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

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

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

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.

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

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.

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.

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