Native Apps Why?
most popular apps are a list of text, images, video, why would a user need a native app? even recorded video can be handled well for free. the answer ideally should be more substantive than “app icon”.
Changing anything in the setup might cause gears to come out wrong, and cost thousands of dollars in scrap, and the loss of a customer.
When you have a locally installed program, offline, you're pretty much immune to most of the troubles of the technical world.
For companies, ease of additional tracking.
It really isn't some _deep_ thing. Users like to be able to quickly access the content they want to consume. Companies want data. Apps fulfill both of these requirements.
Non-native apps that are web views don't get this functionality unless the developer properly hooks it or mimics it. They rarely get this right.
That said, I'm not sure of the current state of Flutter and RN. They resolve to OS native controls, so theoretically they should support these types of base functionalities, correct?
I have built an application that I originally intended to be a PWA, but I had to make it a native application because how Apple are limiting many things for me.
It sucks because I now have to pay the apple tax and get "accepted" by Apple. Ironic, considering the original release of the iPhone, where web apps where the promise to us.
If the app needs connectivity for data, and is just text/images/video, then yes, it should be a web app. e.g. news sites, social media, forums, etc. (It's a site, not an app).
If an app needs be able to work offline, on local files and data, then it should be native. e.g. office apps, image/video editors, maps, CAD, etc.
There's a grey area in between, but usually it's pretty obvious.
What about the Data? on a native app I usually can SAVE data wherever I want on my device.
I can even save it or load it from external storage like... a usb thumbdrive.
And if my connection goes down I sill can use it (unless I have a license/activation software that needs to be connected to the internet).
Some people prefer something better and are willing to pay for it.
Surely that was a rushed reply(?). How about regular system utilities? Video/audio editors? IDE's? Debuggers? Image/3D editors? Compressor/decompressors? Terminal emulators? And so much more stuff.
Sure, many of these already have "web" versions but there's still a lot of apps that benefit greatly from being native and not go through another browser/webview/node instance.
> Video/audio editors? IDE's? Debuggers? Image/3D editors? Compressor/decompressors? Terminal emulators? And so much more stuff.
Video I can understand, and anything that needs a real local terminal. On the other hand, audio, IDEs and debuggers, image editors, 3D editors, codecs, and remote terminals, nah.
My first use of most of those things was on a Performa 5200 whose CPU registers had lower bandwidth (though obviously better latency) than my phone's cellular 4G modem.
Web stuff may feels un-performant, but a lot of this is due to a mix of a thousand or so analytics libraries all competing with each other to spy on everything you do, plus some kind of reactive nonsense that isn't half as good as it wants the developers to think it is, plus zero incentive from the companies to the coders to make things fast.
Or do you currently still specifically choose to use some web based app for most of what you've "discarded"? Are your 3d editors, sound editors, (or even players), image editors or compression/backup apps webviews? IDEs? Etc?
How about password managers? That's a big (stupid) one people use on web apps for some reason..
Because most "professionals" in areas that need these things seldom use web apps. Toy apps? MVPs? Toy marketing or social stuff? Toy video editors for the TikTok generation? Sure. But that's mostly for amateurish usage, at least for now.
Even terminals.. what do you use in webviews that's better than iterm, putty, ghostty, etc?
Like it or not, and as awesome as browsers and webviews have become, there's still a lot of performance left on the table there.
That's just imho of course, just finding it weird people being pro-web apps on hn, that used to be very pro native and pro performance :shrug:
Somehow, a web browser with a canvas whose pixels are populated by JS or Wasm in response to an emulator booting pre-Unix classic MacOS, is faster and less prone to nonsense than the native UI widgets I get from Apple today.
And that, right there, is the point. Wasm is better than I think you think it is. Web apps can run e.g. fluid dynamics simulation directly on the GPU when I need them to. Calculate and rasterise a complete isochrone map of all OpenStreetMap roadways in Berlin at 25 fps even when it's one of 50 tabs in two browsers. Very little in most people's lives is even close to being actually performance limited on a modern computer, the apparent limits we experience are mostly due to all the things I said in the previous comment.
Given how bad SwiftUI is, honestly, a browser can sometimes even be a performance boost. Thinking about it, not even SwiftUI: I had some cases back in the original iPad/ObjC/UIKit days, where the UX was faster in a webview than with native components.
> Even terminals.. what do you use in webviews that's better than iterm, putty, ghostty, etc?
"Better"? Why "better"? Parity is sufficient. Though exactly what performance issues do you even have in mind here such that you even encounter a performance limit in a console?
Also, I specifically put "real local terminal" and "video" in the "sure, native" list.
I put terminals in that list not for performance reasons, but because browsers don't want to play with file systems.
This is very likely to be true, even though I do know it's pretty awesome and I'm actually often surprised by what can be done in a browser these days, I'm definitely not that much up to date with all the latest tech.
And sorry, yes I somehow missed that you had terminals on the native list, my bad.
"Non-native" code performance is naturally one factor to consider, but access to freedom of computing is another. If/When we are already decided to stack programs running in browsers/mobile OS's, we have locked the freedom to computing on those stacks - yor code is not anymore in control, because the parent programs control how your program can behave. An in the name of security, access to parent program features might be denied or are behind paywall/insider-agreements.
Access to your data and programs is also important factor to consider. If you don't have your own data on your own computer/memory, you have nothing. Only expectations of accessing. But then the discussion goes to responsibility and self-sufficiency, so you must take responsibility for backups etc.
Another point to consider is non-native remote apps are easy way to force subscription-type of payments.
most apps nowadays are some like electron react vite vue whatever slop
if ur making an app pls no web app thank u