I still, will never understand the need for native "Apps". To this day, I have never seen an "App" that couldn't simply have been a website/webapp. Most of them would likely be improved by being a webapp.<p>The only benefits I can see of "Apps", are the developer get's access to private information they really don't need.<p>Yeah, they get to be on the "App Store". But the "App Store" is a totally unnecessary concept introduced by Apple/Google so they could scrape a huge percentage in sales.<p>Web browsers have good (not perfect) sandboxing, costs no fees to "submit" and are accessible to everyone on every phone.
Simple, UX.<p>The reality is, most webapps for mobile just suck. The UX is nowhere near that of a native application. I don't want any text to be selectable. I don't want pull to refresh on every page. I don't want the left-swipe to take me to the previous page.<p>You can probably find workarounds for all these issues. The new Silk library (<a href="https://silkhq.co/" rel="nofollow">https://silkhq.co/</a>) is the first case I've seen that get's very close to a native experience. But even the fact that this is a paid library comes to show how non-trivial this is.
<i>>I don't want any text to be selectable. I don't want pull to refresh on every page. I don't want the left-swipe to take me to the previous page.</i><p>Strange. This inability to select any text has always felt like one of the most hostile things developers could ever do. It feels like pure vandalism.<p>Another thing that causes massive productivity degradation is not being able to keep multiple pages open so you can come back to some state. I cannot imagine how anyone could possibly use these apps for any serious work.<p>The UX of almost all native mobile apps is absolute crap. But it's not their nativeness that makes them crap. I'm not complaining about the idea of operating systems offering non-portable but high performance UI primitives that make use of OS facilities.<p>Many native desktop apps don't have these UX issues (at least not all of them at the same time). It's the mobile UX patterns, conventions and native UI frameworks that are causing this catastrophic state of affairs.
Inability to select text is a pain in the ass when you're midway through learning the language and only wants to translate certain parts. In native apps it's understood (app makers don't really give a shit about me), but when it's in websites it's like a slap in the face :)
Yeah, the app model of one page open at a time ever is such bad UX. Huge regression from the web.
Funnily enough you get around it on an app like Reddit by opening pages in the web browser.
> Strange. This inability to select any text has always felt like one of the most hostile things developers could ever do. It feels like pure vandalism.<p>Use Circle to Search? Native capability that works on every single app, and is close to perfect (with the exception of handling text at the very bottom/top of your screen that's covered by your navbar/Google logo).
Every time I try to select a single word in a WhatsApp message I surprised for a second. It’s so strange that most apps that have text as their fundamental content don’t allow you to do this.
On modern mobile and desktop operating systems, you can always copy that portion of the screen to the clipboard and it will recognize the text so you can paste it anywhere.
Also, if my memory serves, native MacOS apps by default support selecting most text that isn’t part of a clickable element like a button.
To be fair, browser apps do have their advantages:<p>- text is selectable<p>- content is zoomable<p>- you can have an ad/nuisance blocker<p>- page source is open<p>While native apps have their own advantages:<p>- much smoother experience esp. navigation, scrolling, animations, etc.<p>- better overall performance (JavaScript will always lose to the native binary)<p>- access to hardware opens new possibilities; audio, video accelerators etc.; there's a ton of things you can't do in the browser with audio for example<p>- widgets, some of them are nice and useful too<p>- for publishers: an app icon on the home screen is a reminder, a "hook" of sorts; this is the main reason they push apps over web versions
All the features you mentioned can also be achieved by a well developed PWA. Of course, minus the widgets or some deeper system integration (like controlling phone calls etc.)
> browser apps do have their advantages:<p>These are more like byproduct of the fact that web apps are built on the stack not suited for modern UI apps. It's literally a text typesetting engine pretending to be a rendering engine for high-performance UI.<p>So, it can also be framed as:<p>- everything is selectable, even what shouldn't be - buttons, drawers, video players, etc
- content is zoomable, which most of the time just breaks UX in hilariuous ways. Developers have to do extra-work to either disable zoom or make hacks/workarounds.<p>"Everything is selectable" and "everything is zoomable" makes total sense if it's a blog post. If it's a UI for the modern app, it does not.
Disabling zoom is so hostile, why not disable screen readers and put bollards on handicapped ramps while you are at it. It’s literally a middle finger to older people and people with vision issues. If you disable zoom I will not be using your website.
> It's literally a text typesetting engine pretending to be a rendering engine for high-performance UI<p>This is an outdated view of the web. Catch up or be left behind.
This is factual view. No matter how many layers of abstraction you put on top, the foundation is always there. Luckily we have better and better support for wasm in browsers, so it's a matter of time when this outdated stack will be replaced with solutions designed from the ground up for the task.
Web just have defaults that are not suitable for apps. Disable text select is one line of css, not that hard.
+ working notifications
- adblocker is more of a minus for publishers though<p>But mainly don't expect any good web app integration on mobile, because it would hit the store 30% tax.
As a user I usually want all of those features to work. I regularly get ticked off at apps, because I cannot copy paste like in the browser or the app just closes (and loses all state) because I tried to use the back button. I also encountered apps that just reset, because I dared switch to another app for a second because I wanted to copy paste something into it...
> I don't want any text to be selectable<p>Disabling text selection is not just worse UX, it is actively user-hostile
In Photoshop panels, title (like "Layers") are not selectable. How is it worse UX or user-hostile?
It's worse <i>on desktop</i>. On mobile it just leads to accidental selection when you were trying to do something else.
I have literally never needed to select text in a UX element.<p>In the past, occasionally there would be an error message in a message box dialog that I wanted to copy and paste. And then I discovered that despite it not looking selectable, it actually was.<p>I don't want to accidentally select the text of my menu bar, or of a text box label, or a dialog tab title.
I, I, I. Empathy is a weakness.<p>Lots of limitations for you to not accidentally do something, maybe there is a way to not accidentally do those things and also help people that need them.
No, not providing concrete examples is a weakness.<p>You're awfully arrogant in making a judgement about my empathy... if you want to make this personal.<p>Or maybe you can justify why people need to be able to select menu labels in the first place? That's not standard on any OS I've ever used, so it's up to the person who wants to change things to justify why.<p>Maybe be less judgmental of people here on HN, and contribute something factual instead? I at least gave a factual account of my personal experience, which is a data point. Describing one's experience isn't egoism.
A simple and concrete example is, go to Japan, find yourself in need of using any Japanese-only app, be extremely frustrated in not even being able to select text to translate it.<p>At least in recent versions of Android there is that OCR (?) powered functionality to select text when you're in switch-app view.
Circle to Search can translate everything on your screen without you needing to go through the whole "copy text, open Translate, paste, switch back to app" workflow. You just hold the home button, then press the translate button.
Thank you for the example!<p>I would suggest that these days you'd be much better off taking a screenshot and putting that into Google Translate.<p>That way all the text remains in-place, and you can keep it as a visual reference to refer to.<p>If you were selecting text, it would wind up in a kind of jumble that would be much harder to use.
Most <i>apps</i> for mobile suck too. A lot of them are worse because they are not in a web browser, eg YouTube or Reddit or similar apps that work via urls.<p>Browsers are some of the very few apps that work well on a phone. Most of the other ones feel like a mess (except games I guess).
Mmh, the examples you've listed are actually super easy to do if you're using a framework such as angular with it's plugins for pwa and touch controls.
And prolly tailwind for css/disabling selection if you <i>really</i> want to, but I'd call that an anti feature in almost all cases.
You have to wonder about the motivations of the company making the browser that makes it impossible to disable some of these things, and therefore makes real apps so much superior (like swipe to go back on safari - I have never ever swiped back intentionally in over 100000 swipe backs).
“I have never wanted to type the letter ‘e’ in any of the 100,000 times I hit the ‘e’ key on the keyboard; it’s always felt suspicious to me why keyboards even have an ‘e’ key which can’t be disabled” said the perfectly normal hacker news commenter.
> I have never ever swiped back intentionally in over 100000 swipe backs<p>Real question here, what are you <i>trying</i> to do when you "swipe back"?
Touching something on the left side, like a link, and let my finger touch the glass a tiny bit too long while pulling the finger back. Unwanted swiping happens to me all the time in all directions - may the developers use a touch screen for everything forever!
Dating apps.<p>By instinct I swipe back like I am in Safari, and that does something else in those.
This swipe thing violates one of the most basic ux principles by making a destructive action easily triggered by accident.
Swipe UP
The "pull to refresh" is probably the most annoying one.<p>Other than that, I'd like text to be selectable! I don't like it when apps don't allow you to copy text.<p>I use Copy [1], and when that doesn't work I use the OCR text selection feature on my Pixel phone.<p>[1] <a href="https://play.google.com/store/apps/details?id=com.weberdo.apps.copy">https://play.google.com/store/apps/details?id=com.weberdo.ap...</a>
That's funny, I use Amazon on mobile web, my wife insists on the app.<p>Guess which one of us has way more problems, due to both functionality and a constantly changing layout?
UX is when you have less features - got it.
It doesn't sound like anything that a PWA (paired with some a sync mechanism like Websockets) can't solve. And with WebAssembly the convergence is even more compelling.
To go along with this UX argument: it’s always been my perception that native apps often lean towards a stateful design while web apps try for stateless. Maybe that’s too abstract (read - incorrect), but was always just where my intuition landed.
Nothing prevents fhe same UI being available in web though.<p>Iconic mirrors a lot of it, but Apple/google could have just as easily made them native components triggered in the browser
That is not an objection. Two decades of webapp progress instead of native app progress would have (and still would) addressed all of that.
webapp UIs suck because nobody cares about them. They could be a lot better.
This is a bizarre take. Are you also suggesting there’s no reason to have a native app on a laptop? Because it’s essentially the same question. There are many things which a native app can do that a browser just cannot do well, or at all. I don’t know what your needs are, but for example if you’re doing heavy video or audio editing, accessing heavy amounts of RAM or utilizing GPU compute or doing other things on the bare hardware, doing that all from a browser is definitely not there yet.
On desktop you do productive work, your apps need native capabilities. On mobile, apps are primarily consumption, displaying, browsing... no complex interactions.
> I still, will never understand the need for native "Apps". To this day, I have never seen an "App" that couldn't simply have been a website/webapp.<p>In cases where a native app and web app are both available on iOS, there’s often a huge difference in battery usage and sluggishness. Also, as a sibling poster mentioned, I like having fully “offline” apps as well, for example for maps and notes.<p>I’m not saying that I like how Apple and Google have done this in practice, but I don’t think going webapp-only is the future. For the same reason I won’t replace my real computer with a Chromebook for the foreseeable future.
When the iPhone came out, you had full offline access on PC to Gmail and google docs using Google Gears.<p>Google Gears got deprecated because something something move to standard HTMl and browser features and now we don’t really have any offline web apps.<p>The ability to have non sluggish, offline web apps has existed for decades now, but the interest from providers has been declining and the understanding that this is possible is also declining on the consumer side.
> In cases where a native app and web app are both available on iOS, there’s often a huge difference in battery usage and sluggishness.<p>Yeah, like single native instagram draining battery faster than combination of multiple websites that I visit in Safari.<p>> For the same reason I won’t replace my real computer with a Chromebook for the foreseeable future.<p>> real computer<p>Where most of the modern applications are either web wrappers or Electron apps.
I’m still bitter about Apple backing off their stance against using web tech in apps. Most apps that are really bad, are really bad because they’re just wrapping websites.
> Where most of the modern applications are either web wrappers or Electron apps.<p>Only if you're stuck on a depreciated platform like Linux. If you are on Mac, native applications – real applications – are much more powerful and usable than any web wrapper on Linux.<p>I've noticed Linux users have taken a habit of proposing their broken way of using a computer through the browser for other platforms as well. But on other platforms we are already spoiled with quality software.
Native applications are way better on Linux, too. But only where they exist. There are plenty of "apps" where there developers have taken shortcuts by getting "Linux support" by using Electron. These app perform noticeably worse and are generally disliked by their users.
Good native Mac apps are on the decline too.
PWAs can be fully offline. Are you sure you understand what you criticize?
Have you tried building PWAs for large user bases?<p>Here are some of the frustrations I had with PWA's.<p>There are massive differences between browsers and Android/iOS when it comes to storage, access to local files, and size limitations. Proper backup/sync of large files using IndexedDB, Cache API, or localStorage is not as straightforward as native storage.<p>Service workers aren’t designed for complex or long-running computations, But they’re more like lightweight assistants, and you would have a HUGE pain trying to accommodate all the different browser/OS limitations if you need predictable background sync/backup. This seems maybe to be better going forward due to frameworks like Ionic/Capacitor or Workbox.js tho.<p>PWAs are tethered to the web’s security model, which means they’re generally restricted to HTTP and HTTPS for communication. This limits direct access to protocols like SMTP (email) and FTP (file transfer). You’re stuck with web-friendly options like WebSockets or WebRTC, or you’ll need a server to act as a middleman. Building a torrent client would be really annoying due to the limited protocol access. The WebTorrent JavaScript framework, which can run in the browser, does not fully support traditional TCP/UDP torrent protocols directly but instead relies on WebRTC data channels. Therefore, your app will only connect to peers supporting WebRTC, which significantly reduces available torrents and peer counts. Also, there often is an added level of restriction to background processes on mobile.<p>There are also limits to access of the devices APIs:
- NFC (partial Web NFC support in Android Chrome)
- Bluetooth (Web Bluetooth limited to Chrome Android, absent in iOS)
- Native contacts, SMS inbox, telephony, or system-wide calendars.
- Some system-level sensors (barometer, precise accelerometer data).<p>Also: Web apps often perform slower on heavy graphics or computation than native apps due to lack of direct GPU access. I have not tested this myself, but I know this has gotten better.<p>Onwards:
- PWAs can't directly register as the default handler for specific file types or URL schemes across the OS.
- PWAs cannot reliably run background tasks (like precise location tracking, audio playback, VoIP callbacks, or continuous data monitoring) when inactive.
- WebAuthn supports biometrics, but native biometric APIs (like Face ID/Touch ID) offer deeper integration for specific app functionality. This is a HUGE need for our firm, as we rely on it for easy authentication for our app, and customers love it over other authentication methods.
- PWAs can't easily embed widgets into the OS home screen or system-level UI components like control center integration.<p>YES, PWAs are much more capable than some people think and could, in many instances, work just as well as a native app. (I use GeForce Now on iOS with not many problems.)<p>And this is not even touching on how much easier it is to use Android/iOS SDKs to put together an application, and user expectations (which might be WRONG when they think PWAs are lesser or more insecure, but these attitudes are still reality).<p>All that said, I prefer PWA over native myself due to publication freedom, but I get annoyed when you talk down to people, and you seem to be the one that doesn't understand that there are actual limitations.
The post mentioned offline usage for maps and notes. Neither are significantly limited by service workers' capabilities. Platform differences are annoying indeed, especially due to the deliberate sabotage by Apple.<p>Sure there are limitations to PWAs, but quite a vast majority of apps don't need the missing features.<p>I find native Android and especially iOS SDKs vastly more difficult and cumbersome to develop for. Doubly so of course if you have to develop for both. Maybe if you're already used to the Android/iOS development mess it is easier short term than to learn something new.
I get your point partially. All these apps that companies put out in order to collect and manage shopping tokens or to contact their customer service would have been much better as a website.<p>However I still do like to have apps on my devices that just work offline, without distributing my data across services I do not control. And I also do not want to depend on a internet connection, when I am anywhere.<p>I like my offline Osmand/Organic Maps app to show me the trails when I am somewhere in the woods or mountains. I like my apps that instead on using some third party server, connect directly to my other local devices to share data.<p>IMO all (where possible) apps should be developed offline first, and only require internet when necessary, and those apps that cannot work without internet should be web apps, they do not need to be on my devices.
It’s totally possible to distribute a webapp that works offline and stores all your data offline too.<p>Platform owners introduce a bunch of restrictions that create reliability and usability concerns, but the standards already exist to enable a website operator to create a webapp that, after the initial ‘install’, runs entirely offline on the user’s device, and has no need to communicate with the website.
Im sorry. I really just can’t understand or relate to this at all. Mobile web still feels like such a terrible experience, and apps generally don’t. When’s the last time you tried booking a flight on mobile web? And how do you deal with all of the real estate the browser steals? Having to log in every time when the app can just cache my authentication and FaceID me?
Seriously, booking hotels and flights is so much better on the web. You get multiple windows for easy flight and price comparisons, within and between providers.<p>I don’t understand people who use apps for this. It is such a pain.
You are comparing desktops to phones.<p>I do most things on my desktop for the reasons you say but on a phone multiple tabs etc is a pain.
No, I’m saying that the booking.com app, or the Skyscanner app or any of their competitors don’t support multiple tabs.<p>Their websites do (although even on new phones you are at a greater risc of a tab being purged and needing a reload, but still you can multi tab on the mobile website)
I almost always book via apps. I can compare flights by looking at Kayak (app), then actually book it in the carrier app. I think the workflow just has to adapt to the tools you’re using, and trying to follow the same methods you’d use on desktop just don’t work. I don’t think either particular method is objectively worse than the other for every use case.
Not who you replied to, but I more so do not rely on my phone for anything where I would prefer more screen real estate such as doing comparisons like buying flight tickets. I have never bought flight tickets on my phone, only on my computer. I prefer the bigger screen and keyboard for most things actually
<i>> Having to log in every time</i><p>Sounds like a broken web app.<p>You are currently using a webapp that doesn't do this. It's called Hacker News, and it never asks me to login every time on my phone.<p><i>> when the app can just cache my authentication and FaceID me</i><p>Sounds like a broken login form.<p>Hacker News also allows me to login with Face ID on my phone, thanks to my password manager.<p>Optionally webapps can also provide Passkeys.
> Sounds like a broken web app.<p>><p>> You are currently using a webapp that doesn't do this. It's called Hacker News, and it never asks me to login every time on my phone.<p>Every time I visit Hacker News on my iPad I'm logged out. Apple has decided that if you don't visit a website often enough it will expire all your cookies for the site.<p>In practice that means I can log in to HN while I'm at the cafe one weekend and be logged out by the time I visit the next weekend.
Passkeys do definitely make the mobile web experience better, but unfortunately they’re still not widely supported. I’m not saying mobile web apps can’t be good, but a native app allows for a lot of UX optimization.
Not so sure. There are a ton of bad apps. They also do not work properly often.<p>Besides companies focus on apps, not on web pages. Less money, less focus, therefore worse experience
> When’s the last time you tried booking a flight on mobile web?<p>A week ago, via TravelPerk which is literally a web wrapper.<p>> And how do you deal with all of the real estate the browser steals?<p>What?<p>> Having to log in every time when the app can just cache my authentication and FaceID me?<p>I literally use the same FaceID for my passwords/proton pass. Also, this depends on a website.
There are also an increasing number of services which are ONLY available as apps now, including, but not limited to, many financial apps such as Revolut.<p>A big issue with this trend is that unlike the web, the whole Android ecosystem is a walled garden which is strictly controlled by Google. In principle you can run your own custom Android ROM, but in practice this will lock you out from any app which uses Play Integrity API to enforce Google's totalitarian regime which dictates what software YOU are allowed to run on "your" hardware.
The worst one is the UK's NHS app, which is <i>only</i> available as an app, despite being just a webview wrapper! I have no idea what they were thinking.
Sometimes it’s a compliance thing, e.g we can only show health data if your device passes some security controls first.
What happens when you visit whatever URL is being wrapped?
You go to the nhs webpage and it works in the same way.<p>Login is better on the iOS app as you can use touch id/faceId and not userid/password also the webpage asks for cookies as it can't seem to remember the choice
IME those apps often have the HTML/JS embedded, so you would have to extract the contents, host them somewhere and proxy the API calls.
I dunno, I haven't reverse engineered it to find the URL. But I would imagine it gets confused about authentication.
Not only that, but these companies are effectively letting Google decide who they can do business with. It's insane.
Its funny to read negative replies to your comment on the shortcoming's of web apps.<p>The browsers are controlled and manipulated by the likes of Apple and Google. These companies have a significant influence on the direction of browser features and limitations, often shaping them to suit their business interests. For example, Apple’s Safari and Google’s Chrome have been criticized for implementing features that reinforce their own ecosystems, such as limiting web push notifications or restricting certain web API functionalities to encourage users toward their native apps. This ultimately means that even in the browser world, the same forces that drive the app store monopolies can still control and restrict what’s possible, even if the web is inherently more open. So while web apps offer more flexibility than native apps in theory, the reality is that Apple and Google’s control over the browsers still limits the true potential of a completely open web.
> The browsers are controlled and manipulated by the likes of Apple and Google.<p>Who do you think controls Android and iOS native APIs?<p>Web standards at least have public forums and specs, with multiple parties involved. And all the major browser engines are open source and apps built for them are relatively cross-compatible.
<i>> the "App Store" is a totally unnecessary concept introduced by Apple/Google so they could scrape a huge percentage in sales.</i><p>Actually, when the iPhone was introduced, Apple <i>wanted</i> it to have only a few select native apps (like Maps or Mail) and all the rest to be web apps.<p>They were <i>browbeaten</i> into opening an app store by the developers, who wanted to do native apps, not the other way around like you say.
During earthquake in Bangkok in Friday Grab (local superior version of Uber) helped me to order taxi and get my kids home. Needless to say that cell phones network collapsed for most of the day. All people want to know what happens and is their family and friends are safe. They definitely have very optimized network layer for poor connections. I bet they can switch to udp or something. I'm glad that it wasn't web app.<p>In many other cases I agree with you.
99% likely they're using a REST API, which is... HTTP.<p>Even if it's gRPC or something more exotic, it'll be over TLS (you best hope it is).<p>You can have a webapp cached locally on your device. PWAs allow developers to create an SPA you can open from your homescreen, and to do that API interaction the same way as a native app.<p>I hope you and your family are well, and it's great that tech helped. But please, don't think that because this tech worked in this instance it can't be made safer and securer.
Switching to UDP won't magically improve your network connectivity. The overhead of WebRTC over UDP isn't too high as well.
It’s clearly for data collection. Take the yelp web app for example. It used to be much nicer than the native one. Then, they intentionally defeatured it until it was useless.<p>Also, this situation benefits the google-apple duopoly, since it means superior products (remember Windows Phone 8?) or privacy focused devices (FirefoxOS) have no chance of getting a foothold in the marketplace.<p>The objections I see in sibling comments are nonsense. Modern web supports high frame rates, developer control over the UI, etc, etc.
While many native apps could be web apps, you’re ignoring a very large reasons for native apps:<p>1. Better UX and responsiveness for users, including better offline use.<p>2. Using native hardware APIs. How are you going to do things that require on device video compression, or realtime graphics that are more advanced than GL ES, etc<p>3. Battery life and performance. A native app can use less power than a web view for doing its work, and it can also make use of better async/concurrency/threading than a web view allows for.
> The only benefits I can see of "Apps", are the developer get's access to private information they really don't need.<p>That's exactly the point. More developer control, less user control. Can't change cookie settings in an app, can't (easily) block ads, can't use developer tools to remove annoying UI elements, can't disable phone home mechanics, can't prevent the developer from profiling you.
In the case of termux, by far my favorite app, I have more than 2GB of locally installed packages. How would that work with a browser?
How would you make a video app in a browser? ie taking videos and then editing them afterwards
GP used hyperbole but was not all wrong. The issue is that <i>most</i> native apps could very well have been web apps. I appreciate that on iOS adding a web app to homescreen is possible, albeit obscure and not many use that feature. I hate that Firefox never really supported PWA for some unfathomable reason.
Do you mean something like <a href="https://commons.m.wikimedia.org/wiki/Commons:VideoCutTool" rel="nofollow">https://commons.m.wikimedia.org/wiki/Commons:VideoCutTool</a> ?
The commenter says about most apps. The use case you mentioned requires computing resources.
You can do the whole thing on browser too but it is not efficient way .
But in the case of delivery apps, finance apps, you don't need much compute as can work exclusively with APIs .
Performance is likely not a reason anymore - and if it is, then it is the platform that imposes it (rust was runs fairly fast in a browser).
No GPs says there are no apps, which is not most.
There is nothing inherently evil about an app, or inherently good about a website - it's only because historically we have allowed crappy app permissions structures and allowing apps to ask for things they don't need.<p>Apps are faster, are more predictable (no auto-reloading or rendering issues) and generally perform better IMO.<p>On the other hand, in reality, you're correct. I think the NYTimes app will collect more data from me than the NYTimes website.
For me, there are a lot of applications that I want to be able to load regardless of whether I have a connection to the Internet or not: calendar, notes, mail etc. They can sync/send/whatever whenever I am next online.
<a href="https://en.m.wikipedia.org/wiki/Platform_economy" rel="nofollow">https://en.m.wikipedia.org/wiki/Platform_economy</a><p>Becoming the middle man is the default model that supports scale. No one has come up with anything else to support a world where avg disposable income is close to 0
Zuck: Betting on HTML5 was a mistake (2012) <a href="https://www.infoq.com/news/2012/09/Facebook-HTML5-Native/" rel="nofollow">https://www.infoq.com/news/2012/09/Facebook-HTML5-Native/</a><p><a href="https://www.sencha.com/" rel="nofollow">https://www.sencha.com/</a>, the vendor of the ExtJS framework tried to argue that Facebook was wrong (2012): <a href="https://www.infoq.com/news/2012/12/Fastbook/" rel="nofollow">https://www.infoq.com/news/2012/12/Fastbook/</a><p>I worked for a company that used Sencha back in the day and wrote the first React integration over their form/datagrid components in 2013. React ate their lunch
It has the potential to be faster, more private and more efficient.<p>Absolute absence of lag, glitches, rendering issues, memory use in the kilobytes etc. is possible with native applications.
Pokemon Go. You couldn't really do that as a webapp with the VR and stuff.<p>Also with the bank apps I think there's extra security over a webapp - on the iphone they often scan my face.
Maps and navigation apps? Desktop integration and sync apps?<p>That said most of the time you are right.<p>I am fairly convinced that some apps are just wrappers around web apps. The Virgin Money (Uk bank brand) app used to ask for cookie permissions on launch and felt very like their website used to (until it was removed and they went app only).
> The only benefits I can see of "Apps", are the developer get's access to private information they really don't need.<p>this is the actual reason why companies push people to install and use their apps instead of their website.
For one, you couldn't access those webapps without a browser, so that's the need for one app. It would also be a bit annoying if you had to load a webpage when trying to dial a number<p>Or am I not understanding what you mean when you use the quoted name "Apps"?
Access to Bluetooth devices is a good reason to have an app. I definitely do not want a Bluetooth API in my browser (although Chrome does have something in that direction, I think it's a bad idea)
So you never use native apps on your desktop? Why should a computing device not be able to run programs?<p>I feel like an actual security-driven design is a lot better than just relegating everything to the browser.
Push notifications. Apps have them on by default, websites have them off by default. 100% of Temu's valuation is because they pester users all the time with nudges to buy stuff, which works.<p>Normies don't turn off notifications. Over the last few years all my relatives have picked up smart watches, (thanks to cell carriers upselling them hard during phone replacements) and in any given conversation at family events they'll be glancing at their wrist every 100 seconds.
Many things needs to be an app, but so so many do not require.<p>Many apps are apps just because they can collect your data, and create walled gardens. It is harder to create extensions for existing apps, for web pages it is easier.
Any kind of offline cryptography. Imagine Apple Pay being an app. So all sort of digital signatures, documents, checks, payment codes and vouchers, tickets etc.<p>IMO this is in the range of „why we use machines to transport if we all have legs”. Technically true, but applications do more than only UI.<p>I've heard this argument for the past 30 years (we won’t be using apps, everything will be remote console/terminal/webpage/web). Chromebooks were meant for web-first access, and yet native apps are still alive and kicking.
To me a mobile app is usually just a shorter web app that you can’t zoom on<p>Edit: and I’ll venture a guess that since mobile apps can’t use things like ad blockers, companies probably prefer them. More control over what you look at.
I agree, mostly, but there are definitely some programs I want running on my phone and outside of the default browser.<p>- Timer / alarm clock
- Camera
- File browser
- Offline maps
- Another web browser<p>But not 250MB banking app.
Push notification is the big one. Yes, there is web push, but that's hardly scratching the surface of feature completeness. And incentives to change that aren't really there.
Yeah, good luck writing a screen reader, a demanding mobile game, a (local) music player, or a warehouse parts lookup app, supporting fully offline use and barcode reading functionality.<p>In 2025? Sure, you can do some (but not all) of that in a browser? In 2010, when those systems were becoming popular? Absolutely not a chance.<p>People forget that Apple initially tried this exact approach. On the first iPhone, that's how you were supposed to do apps. People wanted native so much that they were willing to go the extra mile, jailbreak their device, document the undocumented iPhone SDK and write their own toolchain. The user demand for native was clearly so overwhelming that Apple finally relented and gave in.<p>Even a few years later, Facebook tried hard to have a single, cross-platform HTML5 website instead of bothering with apps. Even then, browsers just weren't there yet, and they probably had the best engineers and resources on that project one could have had for any money.
So many apps are glorified wrappers around web content anyway, and in those cases, native just adds bloat (and tracking)
Speed, and from that follows battery life.
In other words, you believe all computers should be Chromebooks, which can only run Chrome and nothing else?
The most basic app, a notepad, I often prefer native. When I go between google keep or notion to apple notes I can tell the difference. If the text is long enough, the web apps just can not load the content.<p>Just to confirm:<p>I dumped all of my notes from my insanely large apple notes (about 16000 lines of text) and pasted them into Google Keep, Notion, Google Docs. With the exception of Google Docs the rest of them flat out froze and I had to kill my browser. Stop trying to tell us that the browser is the answer to everything when most web apps cant do the job of Notepad.exe or vi
> With the exception of Google Docs<p>So, one out of three webapps that you tested could handle this much text. It suggests that the problem for the other two is their implementation, rather than any limitation of the browser.<p>Of the two that failed, did you also try the app versions to see if they failed too? I really doubt the Notion app could handle 16000 lines of text.
Sorry, I couldn't recreate this. I just built a tiny texteditor app:
<a href="https://65cd02a1-8f00-47cb-b1d1-231493de5fc2.paged.net/" rel="nofollow">https://65cd02a1-8f00-47cb-b1d1-231493de5fc2.paged.net/</a><p>Tried putting 20k lines into it. Loaded instantly, allowed me to scroll and edit flawlessly.<p>But I get your point. I'm on a pretty decent 2022 iPhone, and I'm sure at some stage I would run into a performance hit. But not at 20k lines.
Now try VSCode in chrome and compare it with apple notes. I use both and VSCode wins hands down in long lines and files.
It's an advertisement that you see each time you use your phone.
Working offline?
Very narrow take, it so far fetched i would consider this a bad faith comment.<p>How could you possibly consider intensive games to be "simply" web apps? How about network apps like vpns, wifi analyzers? Have you really not come across such apps or are we meant to think every app is a TODO application?<p>Both web and native has been driven by the same corporate forces, the argument here should be technical only - what can you do on native that you can't on the web. Mixing this technical matter with corporate policies muddies the waters.
Honestly I wonder the same. App stores have big % cuts for the provider, I believe Apple has a 30% cut? Surely this number is big enough to justify spending the resources for a mobile first site?
Imagine a world in which your smartphone's battery lasted more than a day...<p>... and ram requirements for good performance went down by 66% ...
...not every app is a worse reddit website?<p>there are games, there are offline programs<p>---<p>website-as-an-app do needs to be squashed, that's something I do agree with you