Are you a native mobile developer? I am (was I'm moving to ML/AI/Data engineering) and I don't think flutter is in any way easier or nicer than the native toolchains for mobile. Both Swift and Kotlin are better languages than Dart IMO, the IDE and tooling is far superior for both also. Flutter is faster but once to deploy a substandard quality of app for sure but matching the quality of a native app? That takes just as long in Flutter as building a native app in each tool chain. I've built apps in React Native, Flutter, Ionic, and Swift/Kotlin. I'd reach of Swift/Kotlin for developer experience, performance, and quality of app EVERY time.
I am a native app developer. I have only built one small app with Flutter. Here's where I disagree:
- I've used Xcode since version 2 and like it, but in my opinion it's a worse developer experience than Flutter. Refactoring and code navigation were much better in both Android Studio and VS Code.
- Flutter's hot reloading is fantastic. Meanwhile, SwiftUI previews seem to be built on the same technology as IBDesignable, that is, they're just barely stable enough for a short WWDC demo.
- I am very sensitive to non-native controls on macOS, but UIKit doesn't even have a standard button class, the first thing that everyone has to reinvent (Apple included). I wouldn't pick Flutter for business apps with loads of text editing, but it feels perfect for social game-ish apps, like QuizUp or Duolingo.
- In my experience (German freelancing market), the typical native app developer does not care about the user experience anymore. Ever since RxJava and Swift have hit the scene, the focus has moved from impressing the user, to one-upping your coworkers with exotic language features and avant-garde architecture patterns.
Dart is a dumb language like Go, and I think that's exactly what's needed to bring UX back into the spotlight.
I'm a native app developer too (iOS and Android) and I've got some experience with Flutter.
I agree with most of your comment, but the only thing I'd add is that from what I've seen if your concern is the quality of apps then Flutter definitely is not where you'll go to find that. If anything, Flutter developers seem to care even less about the end-user experience and instead simply focus on their own productivity. The end results are often horrible with a ton of jank, UI weirdness, etc.
> but UIKit doesn't even have a standard button class
Doesn't anyone else use UIButton? Granted, the native iOS app I developed was intended primarily for blind people, so I didn't really make it visually polished.
Yes, the visual polish is what I mean. It's not rocket science to style UIButton, but the lack of a good default style means that mediocre native apps often have weird/inconsistent highlighted button states, and so on.
And because it's built in, unlike the bolted-on Rx framework family, it doesn't bother me much. I found the language to be much more focused and pragmatic than Swift, but as I said that was just my experience after a single project.
I am, and I agree, native toolchains can be better but that is expected, they have a lot more resources dedicated to their development. I also am responsible for an app built using flutter, it's been on production for almost two years with a very good rating in the app stores and over a hundred thousand users, isn't that what matters? that the technology enables you to solve problems? Flutter did that for us, keep happily working on Xcode if that works for you, for our startup this announcement is great news.
If you had to pick a multiplatform solution (for whatever reason) which one would you pick? I've been exploring this space a bit, and it's really hard to form an opinion on this.
I've been in that situation 3 times, I choose React Native and Flutter each once. I was forced to use Ionic. I would NEVER use Ionic again, terrible experience and very difficult to get decent quality/performance. I like Flutter's technology much more. I like that it is natively compiled. I dislike that it has it's own UI toolkit. React Native with TypeScript is a highly productive environment but I LOATHED the developer experience and any code that had performance goals was way harder to be successful with, not impossible but the threading model that RN imposes (it doesn't really thread at all) was hard to make the UI snappy and crisp as it should be. I've played with Xamarin also since I was a .net dev for 10+ years (I'm old in the industry 25 years now) and the developer experience was actually pretty good but the compile times and the UI performance were not. Though that was not a production level app and I might have been able to make it work.
tldr; If I HAD to do cross platform I'd use the following logic to choice one:
If I have a team of react JS/TS devs: React Native
else if I have a .net team: Xaramin
else: Flutter
Then I'd apply for a job writing native apps in Swift/Kotlin and run away ;)
Sorry to hear you had a bad experience with Ionic. The stack has improved considerably in recent years and actually Capacitor, our replacement for Cordova, was just rated the highest satisfaction mobile tool on the latest State of JS survey. Cordova was definitely a sore spot for Us but we’ve since moved beyond that and you can use any web stack to build apps with Capacitor (seeing a lot of React + Next.js apps of late)
This area is one that I've been pondering for a long time. In my view, the most sensible approach is to abstract the entire UI and write to the abstracted UI. Then you write the translation piece in whatever toolkit(s) and platform(s) you care about (and in whatever language is most appropriate). This hard separation of the platform and toolkit opens the door for some nice benefits (cross platform being the first and most obvious).
However, the benefits don't need to stop with cross-platform. By adding location independence to the non-application part of the code, you get the flexibility to decide later (even after the application is written) whether to deploy it as a "fat" app (application logic running locally) or "thin" (UI commands and events routed over network to your app running on a server).
I've been experimenting with these ideas for years and it's all doable. I've done various UI/toolkit implementations such as: Cocoa/ObjC, Gtk/C++, wxWidgets/C++, win32/C++, Delphi VCL/Pascal, HTML/JS, Java Swing, Java SWT, etc.
I look forward to being able to share publicly (once I decide which license to use).
If if a CRUD frontend for data, just go with mobile Web.
If doing games, Unity.
If I require some native access, Xamarin.
Finally, using C++ in a MVVM approach with native Views for anything else.
Those answers are for personal projects, at work we just do mobile Web, and with Chrome and Chrome Edge teams pushing the agenda of Web APIs =~ ChromeOS, we get to do most of the stuff we care about.
If you know the native platforms then Xamarin.Native. Shared business logic, platform-specific UI. Over time create your own Xamarin.Forms like DSL to do shared UI.
What are your thoughts on the business end of deciding to build two separate versions of the app in two languages (not to mention the web) vs the efficiencies of one code base?
We're close to needing to make this decision and I'm real hesitant to introduce two additional languages (we're already React for the web but haven't build apps yet) vs a React Native app where our team can be immediately productive.
We made this choice at Rdio back in like 2012. Our mobile apps were written almost entirely in C#, shipping on iOS, Android, and even Windows Phone 7/8. About 70% of the code was identical on all platforms, even the super-hairy audio bits. Contrary to the prevailing notions at the time, our app had native levels of quality and performance. We could roll out a new feature an all platforms in only a little more time that it would have taken to do it for one.
That agility didn't come for free, however - we gained speed, but also traded routine bugs for exotic ones. In addition to simple null-pointer errors and the like, we got to spend two weeks digging into the Mono runtime to find a locking bug that drained users' batteries. We had our own sqlite wrapper because the built-in ones on Android and iOS had too many incompatibilities. We had our own red-black tree, for some godawful reason. We had a standing weekly call with our Xamarin reps to discuss toolchain bugs.
Ultimately, the pain ended up outweighing the savings of sharing code. At the time Rdio went bankrupt, we had substantially rewritten the apps in Java and Obj-C. RIP.
I was with a team that went the React Native route. At first it was fine until we had to go slightly off the rails.. and I was rebuilding .so files based off random gists and updating linkage assemblies.
React Native works until it doesn't and then you are getting into very detailed platform specific territory.
A lot of the cross platform promises were untrue - we quickly learned the importance of QAing both builds and frequently had platform specific patches.
I have had the exact same experience. I’m not a big fan of React or React Native, but I can see that it does increase code reuse; but...
As you say, platform-specific glitches will always crop up so you’ll always need a bit of native work. If you’ve thinned out native development team this can make things hard. Instead of a team of 5 or 10 native developers working on bread-and-butter UI stuff, you only have enough work for 1 or 2, but it’s all grungy stuff like talking to low-level frameworks and working around platform bugs (or React Native bugs, of which there are plenty). That’s not a recipe for clean and maintainable code.
A related issue is that React and React Native aren’t 100% compatible. You can’t just move existing React code directly over as you might elect. It is possible to write code that works on both, but it isn’t trivial.
QA definitely needs to be done separately on each platform.
I would not recommend Ionic. I've been using it in a medium sized app for about 3 years now and I get the feeling it's good for getting started, but once your app grows past a certain size it's starting to create more issues than it solves.
Some examples from the top of my head:
- various performance issues (e.g.: memory leaks which haven't been fixed for years [1])
- their push/pop router navigation seems like a really bad idea
- worse developer experience than using Angular directly (e.g.: last time I checked this, the save/compile/reload cycle of an Ionic project was an order of magnitude slower than the same project without Ionic)
This heavily depends on the framework you choose to use, and modern Ionic uses the stock tooling your framework does, so build times should be on par with any other project of that framework type. Earlier versions of Ionic had custom tooling and much slower build times.
This was happening in an Ionic 4 project which was already using the stock tooling of the framework (Angular CLI). But I remember it being worse in Ionic 3 with its custom tooling, so overall things do seem to be improving with time.
My findings at that time (it was a while ago) seem to match exactly the slowdowns described in this issue [1]. Just importing the IonicModule in a new Angular project (without actually using any Ionic component) made the dev server build times jump from around 200 ms to a couple of seconds. And the situation only seemed to get worse as more Ionic features were being added to the app.
Just to make it clear, I understand that this is an open-source project and I don't expect anyone to fix my issues. And I'm also very grateful to you and the Ionic team for giving us Capacitor which is such a big improvement from Cordova.
So I don't like being all negative in here. But I did encounter a fair share of issues with Ionic and I'm only sharing my experience here as just another data-point in case it helps someone make a well-informed decision.
And I have to say, the overwhelmingly positive reaction to Ionic in general did make me question my own abilities several times. Maybe I just don't "get it". I still haven't ruled that out as a possibility.
Thanks for the info. I do think the choice of Angular here is significant. Angular builds have historically been very heavy. Later versions have sped things up and Ionic apps have gained from that. I haven’t seen slow builds in React, for example.
-the push/pop router navigation is insane, it by default keeps all views in memory all the time for react it will reload every view with any state change by default.
I have seen this a lot. Most of those people are Web Developers. They want their Web technology to move towards cross platform native apps. And are frustrated with people bashing or stopping this progress.
On the other hand you have Native Apps developers, while equally being excited about Cross Platform UI and toolset have been burned more than enough. And this didn't even start with Smartphone. It goes back to earlier PC history with Java or even further. None of them were good enough.
At the same time Native Apps developers dont understand why Web Dev or those who has Web Dev background now working on cross platform toolchain constantly push and produce the same thing years after years.
As a native Android developer (who is also doing Flutter atm) I look at compose as a seismic shift in the Android space. Flutter wont be able to compete
