I regret using Ionic for app development
mhamri.com
mhamri.com
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.
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.
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.
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.
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.
Again, with all due respect. :pray:
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.
Dart is an easy language, but wow I wish they used anything else. It's a big mistake making people adopt a language as well as a framework.
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".
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.
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.
Jake Wharton has a few rants about the Fluter/Dart vs Android politics.
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.
The problem with flutter is lack of high quality libraries. Jank. And finally, flutter web not being good enough yet.
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.
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.
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.
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.
Next project I have to do on mobile it'll be React native all the way from the start.
(They gave some explanation of why they picked dart at the time but it wasn't at all convincing.)
Which is ironic, given the fizzling market share from Firefox, and how with exception of Safari, all other browsers are based on Chrome.
So there is a certain irony that WASM is anyway driven by Google interests.
Well, they all did eventually adopt WebAssembly, so this effort did get somewhere, eventually.
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 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.
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?
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.
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.
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.
Wow.
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.
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.
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.
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?
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
- JSX (TSX)'s XML syntax for layout creation
- Pointers, multiple returns, exhaustive enums/switches/matches
- Immutability by default
- WASM - can work cross-platform (through the DOM, a canvas, Swift, Kotlin, etc)
- Built-in niceties like state management (atoms), shared types (TRPC-esque), etc.
I'm very much tired of web technologies, originally built for websites, being retconned into building large, complex cross-platform applications.
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.
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.
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.
E.g. I would not like to give up the Gmail app and use the web interface.
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.
Interesting that this idea is mainstream when HN hivemind will frequently complain about how bad it is that nothing looks native anymore.