I’ve given Flutter a try with one of my client’s apps, and in some cases, it’s obviously better than native development. Mainly because you can develop for both platforms. I’d be curious to hear where other developers think Flutter is a good framework to use instead of developing native code.
Lots of businesses are desperate for cross platform mobile dev (I'm not looking at you <really well funded tech company with slick native apps>), it seems to be an inevitability at this point.
In the meantime React Native has come along and I don't think it's made a good name for itself in the mobile dev world. RN projects get littered with poorly implemented third party libraries that aim to bridge a piece of native functionality or SDK into the react context. I've just spent the last 6 months as a contractor running around fixing companies' RN apps for Android that had obscure build issues and dependency problems, along with all the weird UI stuff that just doesn't work the same as it does on iOS and it's not been fun.
After playing with Flutter for a bit it looks great. I just hope it isn't susceptible to the same issues I faced with React Native.
Agree with this. React Native development is just a horrible overall experience. The ecosystem is fragmented in so many ways with so many strange third party dependencies. It seems as if there is no 'best practice' yet. Its performance and resource usage hasn't been great either, compared to native.
After messing with it for a couple of months, I would much, much rather duplicate my work with native Swift and Java/Kotlin codebases than one huge spaghetti code javascript codebase that I don't understand.
You can actually use Kotlin on iOS, look at the jetbrains samples for Kotlin/Native. You still need to use the iOS frameworks of course but all the genuinely OS independent code can be shared.
If they can avoid the issues of RN, then Dart/Flutter could be the go-to platform for early round applications that let you build a solid cross-platform app with which to prototype your business model. It will probably never be an ideal platform for mature, premium apps, but if it serves a purpose as the place to go to build a solid working MVP, then that's more than enough to keep it around.
In my opinion, Flutter combined with Firebase (one of Google's other projects) is probably the best possible combination to build an MVP today, on both quality and speed to implement.
There's probably a market here for one-off white label apps too...
My experience with Flutter was it was only really suitable for UI code. Lack of efficient parallelisms among other things really kills the ability to do non-trivial work. If you happen to be able to stay in Flutter's async APIs then the illusion holds up OK, but otherwise you have to just kick over to native code to do anything interesting. At which point the multi-platform story obviously falls apart.
It's really not unlike the web platform. If you're in the semi-narrowly supported "good" path it's great, but if you hit the limits of things you're pretty much immediately out of options.
And also really bad interop with some really critical components like WebView.
Just that once you do that you're no longer a portable cross-platform app, and there's limits to what you can do with that pipe in terms of data marshaling and the overhead from that.
I have not. I didn’t want to put the time into learning the .NET stack and C# because I am from a .NET town and did not want to get stuck here. What're your thoughts on it?
I'm a native dev that is aggressively against the JS-based hybrid frameworks, and I will do every project in Xamarin from now on after working in it for a greenfield project. It's the best option out there until Kotlin Native gets legs.
If you can tell that we're not using OEM widgets, we consider that a bug. Please file it and explain what the difference is. We're definitely not perfect, but fidelity is a high priority for us this year.
Personally, I'd prefer actual native if that was my aim, as opposed to something that looks exactly like it, but actually has layers of styling beneath it in order to look the same. Why? Because if I want the native look, I'm more inclined to be sensitive to my app's size and performance.
That said, I do understand that many people want the seeming of a native app, even if there's a bit of a blowout in size and performance... it's just not my cup of tea however.
Given our architecture, it doesn't cost us any more performance to look like the OEM widgets than a bespoke widget set, and indeed it shouldn't cost us any more to look like the OEM widgets than it should cost the OEM widgets themselves to look like the OEM widgets, because we're targeting the GPU directly.
Just using the GPU isn't enough. On iOS and macOS you have a compositor that has exclusive access to the display that native widgets will use. If you do all the rendering yourself on the GPU, you'll incur an extra hidden full window blit on the compositor side, which is definitely noticeable, especially in power efficiency.
It does cost more in developer hours though. Every update to every emulated UI requires an update on your end. There will be a lag between that update where apps will be noticeably different than native. Can you honestly guarantee Flutter will always keep up with all the environments you plan on targeting? Will Windows, MacOS, iOS, and Android always look and feel the same? That seems like a lot more work to maintain than building a bridge.
I'm not sure what it would mean for me to guarantee anything. So far, we've generally been able to release updates ahead of the OS. For example, IIRC we implemented support for the iPhone "notch" before the notched iPhone came out. Similarly, our support for Material widgets has actually been ahead of Android's in many ways. You're right, though, maybe one day it will not be.
In practice, we've found many apps these days don't even try to use the OEM UI style. Instead, they make "branded apps" with very customized widgets. Flutter really shines at this; it's very easy to make custom widgets. (Indeed, all our widgets, including the ones that look like OEM widgets, are just "custom widgets"... it's because it's so easy to make high-quality custom widgets that we're able to make OEM-like widgets so quickly.)
Relying on native components means that differences in platforms get propagated up into application developer land. Consider: Two "native" components have slightly different behaviours. Therefore, the framework also implicitly has two slightly different behaviours. Therefore, the developer using the framework has to cater for two slightly different behaviours. This is where the real pain of cross platform development happens, and the reason it has such a bad rep.
By bypassing the target environment's native controls, they're paying more heavily in render code, but they're getting rid of all of that propagation of pain to higher up the development stack. As a developer, that's a cost I'm willing to pay.
(* For reference, I have used Flutter, Xamarin, React Native and Java at various points in time, and Flutter has very rapidly become my preference. It has a consistency that I appreciate. But of course, ymmv.)
I agree simply for the reason that native simulation is a moving target and not something that can ever be truly complete. If you push your app into production and never release another update then your app will atrophy over time as updates to native UI widgets outpace your application's UI; not so with native or RN. You're also betting on the fact that maintainers will make updates to the rendering engine in a timely and comprehensive fashion in perpetuity.
I’m not sure why this is downvoted, as it summarizes Flutter pretty well. Flutter’s “Cupertino” theme is obviously an emulation if you use it for more than a minute. If you want your app to look like an Android app on both platforms, though, I think it does pretty well at that.
The emulation is a feature with well understood trade offs. One of the point is to decouple as much as possible from the OS, I believe one of the advantages is that in flutter's mdoel it should be easier to make one-off apps that need less updates.
IMO, UI frameworks that try to mimic native components virtually always fail, because they end up being an almost-but-something-I-cant-put-my-finger-on-feels-wrong situation, e.g. performance isn't quite there or the physics is different.
Much better IMO to go for a "minimalistic", neutral interface where people won't always be comparing your app to better native controls.
As a user, I care quite a bit. As a developer, though, I get paid to tell people that their software doesn’t follow platform UI conventions and I run their code through mental checklists (“does the title animate properly during a controller pop, does this custom view break accessibility”) so I think it’s pretty obvious that I have a very specific slant on this issue. Keeping that in mind, I think that many users do care but they don’t necessarily make it the only thing they care about, nor are they particularly good about vocalizing their concerns. To them an app is just “weird”, or “unusable”, depending on what the framework actually breaks.
Slant is putting it mild - you gotta start putting a disclosure in these kinds of comments or something. You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech.
You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter.
I say this as someone who prefers native controls, has written/launched apps in ObjC/Swift/etc. There's increasingly little reason to bother with the stack.
> You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech.
I dabble in Android and Linux as well ;)
> You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter.
Agree on both counts, but I like to think that users aren't completely clueless. There are certain things that they do feel acutely: animation physics that differ from the system's (particularly for things like scrolling), lag, choppiness, lack of proper accessibility support…
> There's increasingly little reason to bother with the stack.
I disagree with this (this isn't just an iOS thing, by the way: I would say the same for every other platform I've interacted with). It is almost certain to be the case that the team that wrote the platform libraries is smarter, better, and cared more than you did about the UI (there are some very notable exceptions, but I think it's very obvious when this is the case). Going with the native stack means lock-in and sometimes more work, but in exchange you get a significant amount of functionality "for free" (sometimes without even realizing that this functionality existed) and automatically share a common design language with the rest of the system, which is a usability plus for users almost all of the time.
I agree. Typical users aren't going to complain "hey this app doesn't feel native" or even know what that means!
However, they will likely find it harder to use without an explanation why. If most of the apps a user uses follow the guidelines of Android/iOS, and they are primarily a user of one platform, and your app doesn't follow either, it seems obvious that they won't be able to use their built-up knowledge of how apps work in general to navigate your app.
Most people I know, including myself, have found it initially a little more difficult to navigate around apps from the platform other than the one we are used to using daily.
Apps that insist on creating the same UI on both platforms can be a mixed bag, IMO. Sometimes executed well, sometimes poorly. Because of this, I usually prefer apps that separately comply with each platform.
I am however interested in playing around with Flutter soon!
I kinda wonder about this stuff. Seems like it depends on your user base and I'd like to see the user study.
Helping older relatives who find touchscreens to be disconcerting (due to mistaken touches that they don't instinctively recover from by hitting the back button), I think native look and feel doesn't go nearly far enough to make things easy to use, for some audiences anyway.
> If most of the apps a user uses follow the guidelines of Android/iOS, and they are primarily a user of one platform, and your app doesn't follow either, it seems obvious that they won't be able to use their built-up knowledge of how apps work in general to navigate your app.
I just checked my 8 most commonly used apps, exclusing Chrome / Gmail, FWIW I am using Android.
1. Spotify - Doesn't follow any sort of UI standards. Also randomly decides to go into drive mode.
2. Clock - Built in, follows guidelines. About 50% of the time I hit the "trash" icon when I want to reset a countdown timer.
3. Development tool, not counting this
4. Libby, awesome app to checkout books local libraries. They have some seriously cool (but not always discoverable!) UI elements that custom solve problems that have. Their audio scrubber and speed changer for audio books are really cool.
5. Tabata timer - Doesn't follow any guidelines, really really needs a "stop" button instead of relying on back button to stop a workout.
6. Audible - Custom purpose driven UI, similar to Libby but different enough it can be a bit troublesome going back and forth.
7 and 8. Games, always have a custom UI, no problem using them.
I agree. I have an app that is made with Ionic and has about 16,000 paying users. The target group aren't techies/designers. Nobody ever wrote me something like "your app feels weird". Users care more about what problem they can solve with the app.
One of my competitors has a native app, but they require an internet connection, and saving a data point has substantial lag. Parts of the UI (a graph) require a few seconds to be fully loaded, whereas my stupid Ionic app renders much bigger graphs much faster, has no "saving" lag, works offline etc.
My point is: you can screw up a native app easily as well, especially if you don't keep in mind what's blocking and what is not. Sure, at the end of the day, you can squeeze more performance and a better feeling out of a fully native app than anything Cordova-based, but this 5-10% optimization is something that non-techies really don't care about (unless maybe your app has no other USP).
None of my mobile phone apps look like any of my other mobile phone apps.
I've never really considered it to be a problem. The thing that looks like a play button makes the media start, the square makes the media stop. The speech bubble looking thing makes some sort of conversation happen, and the photo looking icon either opens a camera or lets me add a photo from my camera roll. That last one gets a bit annoying.
But I seriously don't care. So long as every app is consistent with itself. The number of apps that follow "platform guidelines" is astonishingly small, typically those from the OS creator (Google or Apple) and people who used the sample template and who didn't bother to customize anything.
Which is another thing, if an app looks too much like other apps, it looks cheap. Sure I want proper back button and keyboard integration (numeric inputs should use the numeric keyboard and so forth), but apps that look like they fell out of a sample catalog don't feel premium.
There isn't a consistent "this is how all retail stores are decorated" standard, there isn't a set of mandated "this is how all grocery stores are laid out" regulations, why in the world do people go around insisting that all apps should look the same?
Sure, use the default platform picker if it is appropriate, but if it isn't (and finding the year picker on the Android date picker is darn nearly an easter egg, and Android's keyboard entry for time is also not up to snuff), then use something else!
I give 0 cares if an app has properly rounded text inputs. What makes an app feel good is nice animations, no stutter performance, quick load times, and a self-consistent look and feel.
When apps look and behave the same, it allows users to bring knowledge from one app to another, gradually developing into expertise.
The Mac has a profound depth of power-user acceleration: keyboard navigation, keyboard shortcuts, modifier keys, drag and drop, context menus, type-select, arrow keys, etc. Learning this stuff isn't wasted because it applies to every app (or at least that's the vision).
Controls look consistent, which signals to the user that their knowledge applies here.
Mobile obviously needs different UI paradigms, and yet it doesn't really have much of anything. There's still no good convention for basic operations like Undo. And part of the reason is that every app has to be a snowflake.
RN definitely feels native... assuming the developers utilized the built-in components properly. RN is an actual native component whose state is backed by a JS bridge.
There certainly are poorly written / optimized RN apps. There are also apps that due to their nature/goal shouldn't be RN even at an early stage. (Startup, navigation, threading, network issues for one). However, I would argue that a properly written RN app, within the confines of the problem RN attempts to solve, does not feel heavy and is actually indistinguishable from native.
From my experience I would surmise a lot of badly performing RN apps stem from poorly written JavaScript, especially bad state management (lots of devs who perhaps have only written web JS in the past?).
Curious where this is an issue. React Navigation feels and is, according to their documentation, composed of native components.
Vs. what you can do natively it has severe limitations and the documentation isn't the best (though I think it has improved recently).. but feels native to me.
I am using a lot of apps that still have a jellybean feeling to them, if it does not crashes and it is not a swipe-hell (I have an underpowered phone) it is fine to me.
To me, smartphones are like plungers: They are dirty, ugly (from a software perspective), and I don't like using them, but they are pretty convenient to have most of the time.
I only want them to get the job done and then get out of my sight, so I don't care about the UI being pretty. I would say "elegance is reserved for desktop PCs", but those are ugly too (x86 is horrible, all OSs suck).
Flutter is a reasonable choice if you are developing a "simple" app that won't grow in scope.
By simple I mean that you don't need anything special from the device, no access to the sensors, no deep integration with the OS.
I think that enterprise apps would be an obvious target (because otherwise, for most of these small apps, the first question to answer is why not just have a website?)
