The problem with Ionic and React Native has always been the JS/Native bridge. Works great when you're coding it, but to debug any problem rationally you need both native platform and JS expertise. This problem then fans out into every plugin, every open source library, every native-specific "exception", every random device issue.
Then the minute you want deal with any native problem, both Android and iOS (and their stores) have nothing to help you. Play Console stack traces just started supporting Kotlin. Forget trying to debug a pile of JS on top of a pile of Java for some obscure plugin that is ANR'ing.
Flutter at least tries to fix this problem by taking the Unity approach: One-click build for each platform, where the framework owns the native problem. Then push everything to native graphics as much as possible, down to DSL-specific management of threads. However Flutter has been slow to be adopted into big projects, and made the mistake of choosing Dart over Kotlin. It's stuck in a purgatory of having fans, but not the level of success to qualify as a "breakout" for Google.
The hard truth for mobile development right now, is the same hard truth that existed in 2010: Nothing beats native. You try to do too much cross-platform, you wind up chasing two rabbits with no dinner. Even if Google solves every development problem under the sun, Apple is going to Apple. They own the highest-paying customers, they do what they want with the opaqueness of obsidian, and are the very definition of "full stack" from chips to platform.
I am rooting for Flutter, I am rooting for a cross-platform utopia, but outside of game platforms it feels like we are farther than even 5 years ago.
With the utmost respect to the gargantuan levels of effort put in by hundreds of developers:
I've never worked with tools where I had to guess/pray every morning "Will my app compile and run today?" until I worked with React Native.
Seemingly randomly my apps would not build and I had to waste entire days chasing down random Github issues and comments in unrelated packages to get things running. I have never since experienced something like that either.
I'm thankful that I don't have to work with React Native anymore. Even my younger brother has given up and just bit the bullet to work exclusively with Swift natively for mobile apps.
> I've never worked with tools where I had to guess/pray every morning "Will my app compile and run today?" until I worked with React Native.
Happened to me building a Kivy Android app using Buildozer. That marked the end of my use of Kivy and Buildozer. I really want to use Python to build apps, but not as much as I want to not randomly have apps suddenly refusing to build out of the blue, and Kotlin is a damn nice language.
The problem with Flutter is Dart. I considered it for a cross-platform project for my company, but ruled it out because it uses a language that essentially nobody knows. And when I say nobody, remember that the real world (and the contractors available in it) is not Hacker News.
I wish Google would settle on a language or two and stop with the seemingly endless parade of new ones. Kotlin for mobile, and ? for everything else. Or just... Kotlin.
Thanks. I don't know Javascript or Typescript, and nobody else among our developers did either. I know Swift and C++, and our products' firmware and other software is written in C++.
It's not that grasping it would be hard. It's just that nobody has time to dick around with it and making tooling for it. We ended up using Qt and constructing the UI in QML, which worked out quite well for a cross-platform desktop app. Still haven't tried mobile with it.
Fortunately dart is fairly predicatable. It does few special things and they're all very approachable for anyone familiar with the other gc'ed oop languages(java, c# etc.). While I wish it had some more useful features, its mundanity was a big boon when picking it up.
The main reason for Kotlin's recent popularity is from its use on Android. Not that long ago it wasn't all that popular while many jvm better-than-java languages were competing. Same for Go.
If a substantial amount of Android (or other/cross-platform) dev happens with Flutter, Dart will become just as common. As a language, it's not great, but it's also not bad either.
It's true that Kotlin wasn't a breakout success 5 years ago. However, I would argue Kotlin's design decisions made it destined for its current success, whereas Dart has not.
The most obvious of this was same-build compatibility with Java. Mixing Kotlin and Java made it super easy to switch, and made using it a no-brainer vs other solutions. Android Studio also has a button that auto-converts Java to Kotlin, so in many cases a wholesale rewrite isn't even necessary.
At this point, Kotlin has also become a goto for backend Java for stream processing and other open-source JVM projects. It's rapidly replacing things like Scala for Flink, as an example.
Maybe Dart survives by the sheer force of will of Flutter, but I don't think there's a chance it catches Kotlin.
Kotlin also seems very similar to Swift, which is handy. The last time I saw the topic debated on this site, the consensus was that native is still the best way to go when developing mobile apps, even when you have to support both iOS and Android.
My biggest fear is running fine … and then when compiled something different. And it happens.
For “simple” apps I’m very happy with react native. I can’t say enough good things about it there … but I’m really nervous (especially as the primary developer) as if I’ve got this debugging black hole/ sword of damocles hanging around.
For web developers who want to hit both app stores I still highly recommend it. But with the note that you want to be deliberate about changes / know about that black hole.
Yep. Also, the decision is different when you don't use the app store for distribution.
I know lots of niche business-specific use cases where they don't care if it crashes half the time. If you need something on mobile quickly for a narrow use case, RN / Ionic can be your friend.
You nailed it, if we had a framework that took flutters approach but let you build in typescript or kotlin things would look a lot more appealing for cross platform dev.
The antitrust pressure on apple is forcing the last holdout (iOS Safari) to step into line.
We've got our B2B customers using web apps on iPads managed via MDM solutions right now. Camera, location, push, Home Screen icon, etc all working flawlessly.
It took us almost 3 years to get to this point, but it's very stable now.
I agree you still need App Store presence for B2C, but there are paths here too with vanilla web stacks.
Agreed re: B2B, but I've looked at a handful of the Webapp / PWA solutions for B2C app store and it's still pretty far away.
B2C users really demand a consistent experience despite the state of the device, and it's hard to get a web stack to do this well. Logical offline behavior is one, but even things like the click response being slightly too slow vs native UI can turn people off.
Beyond that, you hit the same problem with RN / Ionic: Native plugins don't work as well, native support isn't there, and it becomes very hard to debug. This is especially true if you "present" the app to the user as native but use a web stack. For a website in a browser users tend to have patience for things like slow buttons, for native they do not.
As a point of comparison, think about how responsive a game engine can be. That is the user experience people expect on mobile. It's a heavy lift to get web there, and if you don't someone else will build a native experience that will.
It’s getting there. Look up react-native-web, tamagui, and solito. Almost all the code is shared between web, iOS, and Android and the web experience feels like a native app[0].
Is there a specific use case you have in mind that would be infeasible to do as a web app? I'd even be interested in arguments about poor UX, because a lot of this has been resolved recently.
Top of my mind. Discovery, apart from devs (even that is a stretch), when I say app people quickly open play store/app store. When I say you just gotta click add to the home screen. They're like, you don't have an app? Isn't that just a failure of UX?
I once tried to convince a founder so hard to go with webapp, I gave every advantage I could think of, then in our survey not one of our users was comfortable, they all weirded out. But hey web app works if it's forced like in a enterprise or MDM setting, but people would rather open app stores.
Despite the flak, consumers trust app stores at some level than a random website, even if its more secure since it can't access a lot of APIs, but they don't know that.
Every framework ionic, flutter etc I've tried since Cordova has had some weird feel to it. I can quickly recognize a webapp packaged as native in the first two mins, most of the users I worked with just think it's slow or janky since they Don't understand it's a webapp vs native.
Exactly. I wanted to consider Flutter, but no way could I sell my company (already stretched thin with developer resources) on a platform using a language that nobody (including me) knows and that has essentially no payoff for learning outside this one thing.
Dart is pretty straightforward, but there are some idiomatic concepts you need to get just to get started. Laying out a View and updating values is the most obvious one, but also how startup and libraries integrate also comes to mind.
The biggest problem with Dart is that it looks nothing like other UI languages ... by design. It ostensibly was supposed to be a uniform UI layout language, but it suffers from the "XKCD standards" [1] problem of now making its own decisions with no basis for comparison.
To code a cross platform app, you already likely need to know Objective C, Swift, Kotlin, Java, and/or JS. If you do Unity, you need C#. Dart looks like none of these, and is at best half-loved by Google as much as say, Go.
I almost want to just spend time writing a Kotlin -> Dart compiler, but I feel like that would make the problem worse. "Now we have 16 standards".
Maybe someone then will make dart to kotlin transpiler and port whole flutter to kotlin? I seen unity framework that ported pretty much whole flutter to c#/unity
Yep, this is a problem that Flutter shares with Unity: It's BYO(everything) and not at all APK optimized. You use native, Android won't re-download libraries that are already on the device. Drops your APK size, increases your rankings.
FWIW, Apple doesn't care as much, and their users are used to it, so that's a plus I suppose.
Not the same but also related: Using RN and Ionic can just destroy battery life and CPU for apps because you are essentially running a full JS engine on top of all the native stuff. This can cause them to get aggressively killed when backgrounded and / or punished in other ways.
Sure you checking the right build? Production builds are usually much smaller in size than debug builds. I had a complicated app that was only 20 MB in production, but like 300 MB in debug.
As someone who has deployed projects to the App Store/Play Store in both React Native and Ionic for my day job - Ionic is a breath of fresh air compared to React Native.
Ionic+Capacitor delivers on the promise to leverage existing web development knowledge to build mobile apps.
React Native somewhat delivers on the promise. But the whole ecosystem loves breaking changes, and debuggability is a nightmare. There are more libraries for native libraries, but the headache of actually integrating them is significant.
Capacitor, in comparison, seems very well designed. Where web tech stops and native tech starts is very clear.
Expo is a huge bait and switch that makes it hard to fix down the line. It's all rainbows, butterflies and QR codes at first, until something goes wrong or you outgrow expo. Then you're in the 5th circle of hell where you've coupled half your app to expo and need Java, gradle, and IOS experts to fix it.
Next project I have to do on mobile it'll be React native all the way from the start.
Yep was going to say this, Want to use a library that is too low level for expo support? Tough! you eject from Expo and now you have to do the low level RN stuff for everything and not just that library.
We haven’t had to fully eject with the dev builds -
Have you hit the limits of that new(er) workflow? We have lots of packages not available in expo go (and a few that required some config finagling) https://docs.expo.dev/development/create-development-builds
It's based on another project that it seemed like Google was going to kill, Dart. I don't think I have good enough priors for this situation but I certainly understand your concern.
The only reason why Dart didn't die was Ad Words team, they had just migrated from GWT into AngularDart when the whole thing imploded, so they rescued the Dart project as it was easier than yet another rewrite into something else.
Been playing around with Flutter the last few months. Still has some rough edges, but the ability to target every major platform with a single code base is very cool. The way the UI is laid out with the widget tree is new to me but fun to learn and seems like a very scalable way to build a UI.
React, Vue, and Svelte are the ones most attached to angle brackets for building apps now. I like HTML Custom Elements and surprisingly the slot mechanism often isn't the best way to do things. You can just use functions that call createElement a lot of the time or a library like Snabbdom. Templates are more for static content.
VsCode, Atom, and CodeMirror all do a lot with the web platform without a high angle bracket to line of code ratio.
Web app staples like Floating UI and split-grid don't suffer from a lack of angle brackets.
It's not the specific angle-bracket syntax that matters, but that there's a ton of verbosity around widgets creation, children arrays, and other properties that could have been massively reduced with the right transformations or even just some decorator-style syntax.
I’m frankly surprised Dart made a come back at all. I remember hearing a good bit about it and it’s lofty ambitions years ago, but then it seems like it kinda just fell off until Flutter.
In my opinion it was a huge mistake for them to use dart for flutter. I suspect that there would be a lot more excitement around flutter if it used javascript or kotlin (since a lot of android developers are already using kotlin).
(They gave some explanation of why they picked dart at the time but it wasn't at all convincing.)
Flutter is a really good start, it's the closest thing I've found to what I'm looking for. I don't even think Google's going to kill it anytime soon.
I don't like Dart though, it has an over-reliance on codegen, and I far prefer JSX's XML syntax than the constructor syntax Flutter uses for its layouts.
I don't think that's very likely. Google is clearly still investigating heavily in Flutter, they use it for some of their own apps and devices, and they are clearly aware that the native Android API is not very good.
The only thing that would make me suspect that they would kill it is the ongoing performance issues due to shader compilation. But they have actually started fixing that properly by creating a new renderer that doesn't do on-demand shader compilation.
The developer tools that Google has released generally don't get suddenly killed. They mostly kill user facing apps that aren't very popular. And Reader.
Forcing me to use Dart because you made the poor decision of developing it, and now need a reason to continue funding it if I want to use Flutter? No thanks.
This link says absolutely nothing about Flutter usage.
It's about apps that are already written in native iOS code, which are currently using custom Material Design components (which are mostly/entirely in obj-c), and that going forward those custom Material components are going to be phased out and apps will use standard UIKit elements instead.
This tells you absolutely nothing about Google's commitment to flutter.
So it says nothing about using Flutter even though the entire purpose of Flutter is to write cross platform apps and Google is moving toward not writing cross platform apps and are using standard UIKit components.
They also aren’t using Dart and are using Objective C.
But that doesn’t mean they are moving away from Flutter for first party apps?
They aren't moving away because these Google apps weren't using Flutter in the first place. The only ones that were are like, Google Pay and Google Classroom.
Because you can add arbitrary keys in a new release and there is no migration SQL needed like you would need to do if adding new database columns (or tables).
The thing he missed is that you can implement arbitrary key/value pairs in a RDBMS table; you don’t need a NoSQL database necessarily:
CREATE TABLE NAME_VALUE
ID INT,
NAME VARCHAR(32),
VALUE VARCHAR(512);
Querying on WHERE clauses with multiple keys/names can be tedious but works fine as long as performance is not your first priority.
Point likely stands - any schema migration is not an easier problem on either side - you just move the migration logic to your code instead of the database.
That's the part of NoSQL I've never understood. With a "normal" SQL DB my app has to be able to migrate between versions of data, but the code ever only supports the current version. With NoSQL, you will either have to support every possible version (which might be unique per entry), or implement migrations yourself. How is that not strictly worse?
Instead of having to use flutter, I'd rather see iOS embrace TWAs like Android so I don't have to use Ionic/Capacitor at all.
While I'm wishlisting, I'd like more native controls exposed via JS for PWA/TWAs, like widgets, messaging, and password manager APIs.
Don't talk to me about writing native apps, I'm a solo dev and couldn't care less about it. I don't have the cycles or the users "demanding it". PWAs are fine if you know what you're doing.
Here is the thing, for most forms over data applications mobile Web works just fine, PWA or not.
When I returned to Web/Cloud development a couple of years ago, all the applications use Web frontends, and the tablet / smartphone users manage just fine, no need to package Web sites as "native" applications.
Naturally there are a couple of exceptions, like games.
Has anyone here have experience with this? We're currently looking at a forward-looking stack for our multi-platform app, and to be fair the general feedback we read is that they all suck in certain ways. What's the least bad out there?
I greatly enjoy building in Maui. By weird chance my first programming gig was in UWP and it’s a pleasure to be working in C# .NET again, able to build UIs with xaml and dynamically out of the code, but with a bigger prospective audience than “people who install uwp apps.”
That said, I’m only playing with it right now - I’m doing some weekend projects hacking against LLM APIs and it’s a great way to stand up a simple app quickly that runs on my phone and debugs at the computer and could theoretically one day be on the mobile app stores. But I would tentatively agree with other replies that it might be a little early for commercial adoption. I haven’t encountered any show-stopping bugs or limitations yet, but at the same time when researching for troubleshooting and bug fixing I will find git issues that were resolved less than a year ago for things like images not displaying on android. The built-in MediaElement for video playing only just came out and doesn’t support true full screen playback yet.
The other factor from it being new is just the lack of community discourse about it. The docs are great but you’re not going to find many discussion on git and SO about it yet, and the search space is cluttered with results about Xamarin.Forms that are sometimes relevant and sometimes completely not. So IMO that means people should give it a try! But maybe hack on it first before committing to shipping commercial software.
Has MS released a commercial/production app built on Maui yet? Are they eating their own dogfood?
If I wrote an article about trying to develop in Xamarin.Forms (MAUI) it would read like the Flutter article that brought us here. Way better than Flutter but still needs work. I spent years on the bleeding edge and mostly ended up with builds failing and other nagging problems. Drained all of my energy. I went back to web dev and have been using Vue 3. Pry it from my cold dead fingers.
I don't entirely understand why someone would use Ionic to begin with when both React Native (+React-Native-Web) and Flutter both exist.
Don't get me wrong, I don't like any of those options, but these B-list options are fairly obviously miles ahead of whatever these other C-list frameworks are promising.
An A-list framework to me would look something like:
- Typescript-esque syntax without being tied to JS
> The only viable option today, in my opinion, is Flutter
I guess it is viable in that Flutter targets, iOS / Android, web and desktop with a "single codebase" but the author of the article isn't aiming for all those platforms.
I think I’ve rebuilt one app in early every web/hybrid framework. They all failed including ionic.
For one reason or another, beyond the usual and small trade offs between platforms, they have all ultimately failed, become overly complicated to maintain and add more logic to. Especially an issue has been the special punishment of having the same codebase work in a dev environment on Mac/windows/Linux.
One tech I see being part of the next curve (the prior curve being things like reactnative, etc) is Flutter, or others like it.
First class dev environments, first class documentation.
Because it seems you have some experience in the field: is there a way to develop and support a multi-platform app in 2023 without suffering? The idea of having to hire 2(x n)FTE to handle developing mobile apps which will, at the end of the day, look and feel the same to the user, is killing me. What's the least worst option out there?
I'm currently a Android native developer with 7 years experience and have used Appcelerator/Titanium and Iconic + Angular before that. IMO if you're writting an app that only makes API calls and draws to the screen, then using cross platform SDKs is going to save you time.
But if you need to use any platform specific native SDKs like camera/push notifications or other 3rd party native SDKs, you're going to be in a world of pain.
Nope, you can limit the suffering for your devs by using Expo (RN) or Flutter (Needs Dart).
The issue is as soon as you stray off the well laid path similar to the old create-react-app problems you have to choose "do things their way" or "Suffer all the problems you avoided with the framework + all the problems of the library you added".
For example at work I help maintain a React-Native app that is one of the core parts of our business, We investigated Expo but we use sodium in the app for keypair generation and its not supported. So we can't have any of Expo's benefits because of one unsupported library. (its supported in iOS and Web but not Android...)
* There are packages that implement sodium in expo but they score too poorly on their security scores for us to use them.
I think it depends on the app. Some apps have a lot more interaction with the platform than others. E.g. writing a camera app in Flutter is going to be like 80% platform native code. Writing e.g. a GitHub app is probably going to be 0%.
Yeah in a lot of cases you definitely could. But well written mobile apps are still better than well written mobile web sites. Sometimes much better depending on the application.
E.g. I would not like to give up the Gmail app and use the web interface.
> They’re missing that the market has moved from this kind of mindset. If you look at Dribbble, you can’t find mobile design dedicated for iOS and another set dedicated to Android.
Interesting that this idea is mainstream when HN hivemind will frequently complain about how bad it is that nothing looks native anymore.
Then the minute you want deal with any native problem, both Android and iOS (and their stores) have nothing to help you. Play Console stack traces just started supporting Kotlin. Forget trying to debug a pile of JS on top of a pile of Java for some obscure plugin that is ANR'ing.
Flutter at least tries to fix this problem by taking the Unity approach: One-click build for each platform, where the framework owns the native problem. Then push everything to native graphics as much as possible, down to DSL-specific management of threads. However Flutter has been slow to be adopted into big projects, and made the mistake of choosing Dart over Kotlin. It's stuck in a purgatory of having fans, but not the level of success to qualify as a "breakout" for Google.
The hard truth for mobile development right now, is the same hard truth that existed in 2010: Nothing beats native. You try to do too much cross-platform, you wind up chasing two rabbits with no dinner. Even if Google solves every development problem under the sun, Apple is going to Apple. They own the highest-paying customers, they do what they want with the opaqueness of obsidian, and are the very definition of "full stack" from chips to platform.
I am rooting for Flutter, I am rooting for a cross-platform utopia, but outside of game platforms it feels like we are farther than even 5 years ago.