Comment by muzani | Hacker News Reader

Comment by muzani | Hacker News Reader

Agreed with the article. Some will say just do iOS/Cordova/React Native/Flutter. But these have all the same problems eventually.

Do web? You're just pushing the problem of accessing lower levels (esp. files and camera) to the browser. Browsers are not consistent. Some devices don't even update their browsers and it would break POST on a very specific version of Android.

There's a high end Samsung gallery that has a very inefficient way of displaying thumbnails. This is the default gallery. If the user has over 10000 photos or so, it freezes. People who buy this phone will often have a lot of photos. And they're rich; usually the investor. This bug doesn't show up in typical tests because QA can't afford this phone. So the fix is to avoid built in galleries, and write a custom gallery for the app that utilizes binary search or something. Major apps like FB and WhatsApp will have implemented their own in built gallery software so these device owners end up blaming the apps that don't.

> But these have all the same problems eventually.

I've maintainted a Flutter app and it's 10% of the maintenance of a normal Android or iOS app. The only real breaking change they had in 6 years was the switch to strict typing.

So, are the Flutter library maintainers so good that they are able to abstract out all the changes that are happening to Android system libraries, Google's helper libraries, and the restrictions on the underlying platform?

Mostly yes, Flutter is insulated from the underlying platform.

Rendering everything to a canvas has disadvantages but also advantages. Flutter doesn't need to care about most framework changes.

Rendering to canvas eliminates may be 25% of the issues that I listed.

How does rendering to canvas insulate you, for example, from the underlying permissions changes in the Android platform?

90% of android apps are equally painless to maintain, all they request is the INTERNET permission.

Android went from a free for all to considering that maybe we should ask the user before granting full access to all of their files without warning. In addition, the upgrade paths are well documented, and give you multiple years to migrate.

I've experienced a lot of trouble with Flutter in the last year alone. Maybe it's because they recently laid off the Flutter team.

One related to this: https://docs.flutter.dev/release/breaking-changes/android-ja...

We had a bunch of sdk users who couldn't port over our Android sdk because of "Unsupported class file major version 65" so we ended up making a flutter plugin for them rather than downgrading the native Android versions. I would expect many sdk devs to not care enough to do this, especially the open source ones.

All the changes on these platforms have been done thanklessly by someone. Before this, someone was paid to do it, so they might not need the thanks. But I saw how fast Cordova unraveled after Apache announced they were dropping support.

There's the frameworks like GetX too which have slowed down recently. We've been removing them from the code and replacing them.

but the underlying native stuff still creates a problem. we're on an old version of Flutter without any need to upgrade but Apple has an updated Privacy Manifest requirements that forced us to update our dependencies purely only for the manifest. Workarounds are barely mentioned, although they exist.

> Agreed with the article. Some will say just do iOS/Cordova/React Native/Flutter. But these have all the same problems eventually.

I don't have enough experience with iOS. React Native, Cordova [and Flutter], however, as a different problem and that's that you need someone to deal with underlying platform changes, the libraries that you rely on adds another layer of leaky abstraction between your app and the Android platform. Now, you have to wait for someone to update the underlying libraries as well, for example, https://github.com/react-native-community/discussions-and-pr...

Reply on news.ycombinator.com