It’s called a “WebView app” and you can get a really good experience on all platforms using them. Just:
- don’t make any crazy decisions on your fundamental UI components, like breadcrumbs, select dropdowns, etc
- add a few platform-specific specialisations to those same components, to make them feel a bit more familiar, such as button styling, or using a self-simplifying back-stack on Android
- test to make sure your webview matches the native browser’s behaviour where it matters. For example, sliding up the view when the keyboard is opened on mobile, navigating back & forth with edge-swipes on iOS, etc
I also went the extra step and got service workers working, for a basic offline experience, and added a native auto network diagnostic tool that runs on app startup and checks “Can reach local network” “Can reach internet (1.1.1.1)” “Can resolve our app’s domain” etc etc, so users can share where it failed to get quicker support. But this is an app for small-to-medium businesses, not consumer-facing, and the HTML5 part is served from the server and cached. I haven’t thought much about what you might need to do additionally for a consumer app, or a local-first app.
It’s because if a webview app experience is good, you don’t notice it, you only notice if it’s bad.
A while ago saw a blog link on HN that explained how Apple uses it everywhere and we never notice it because they are done well. Of course I can’t find that link now, I summon the HN gods…
On mobile the webview app experience is crap and it's immediately obvious that an app is not native. Simply nobody asks customers how they like it. The management assumes that as long as nobody complains and the users don't leave in droves, the experience must be impeccable.
It's often easy to tell, but my concern has shifted from "Why isn't this native? It's ugly/slow" to "Why isn't this a goddamn webpage? It can't justify neither its permissions nor its space".
> It’s because if a webview app experience is good, you don’t notice it, you only notice if it’s bad.
Aside from Apple’s apps (which imo are noticeably worse than the old ones, but that’s beside the point), what are some good WebView apps on iOS right now?
Somebody scraped the play store and checked the framework, so a list for Android WebView apps, built with capacitor, is here: https://capgo.app/top_capacitor_app/ Maybe an equivalent is there on iOS for the same app...
lichess is really good. Thanks for the info, I'm not surprised to learn it's a webview app, but it is really good.
It doesn't look native but who even cares. I think when a UI sucks or is unintuitive or buggy then "it's not native" is a sort of catchall easy complaint. Native is a crutch. Sometimes it's a good crutch (accessibility etc). But that's more about developer efficiency and bare minimums of polish.
Sadly i couldn’t find a reliable way to do it on Apple Store, it’s pretty hard to download from the store outside of apple device. If anyone know how i can do it too
Yes, Apple's apps are really really bad - including the app store. I am not even sure whether that app store can be considered a stand alone app or we should call it part of the OS.
A webview app is by design bad. Webviews were made for one thing - web views.
The app store is the only application that I am aware of that you can't find through spotlight search. You can search the app store directly from spotlight search, but it will never list the App Store as an app. Very annoying.
Thanks for this comment. I was able to fix this issue, finally. Had to toggle the switch in setting> apps> App Store > search and restart my devices. :)
I thought it was some legal thing about App Store competition.
> It stands to reason that Apple wouldn't have developed this feature [liquid glass css property] if they weren't using it. Where? We have no idea. But they must be using it somewhere. The fact that none of us have noticed exactly where suggests that we're interacting with webviews in our daily use of iOS without ever even realising it.
There's some jump from _a property exists_ to _it must be used_, but a massive one from _a property exists_ to _Apple uses it everywhere and we never notice it because they are done well_.
It is immediately obvious when you are using a web view app, as it uses browser layout and non-native controls. And I have never found one to be as intuitive or nice an experience as native controls.
If Apple are using it for the AppStore - then I defo Italy do notice it. The AppStore runs so badly.
I would be interested in any links to Webview apps that run really well, I’ve never seen one that I’m aware of but so many that I am aware of and are bad!
I've done it before on a personal project and I was pretty obsessed with user experience. For example, I changed the way buttons work (because they were natively links with Cordova, which trigger upon tap, not "finger lift", like native buttons). Also, implemented some gestures to e.g. switch between pages (tab-style navigation). While not really in line with system UI (wasn't my goal), I think usability is quite decent.
I have experienced the opposite with Zed, which has its own bespoke UI framework - it behaved somewhat unexpectedly and didn't work exactly how I'm used to an UI to behave giving me this uncanny feeling.
This kinda shows you how much effort and experience goes into getting an UI framework right, and the long tail quirks (of which there are a zillion) matter for UX, and while I appreciate they took on the task of breaking away from the browser, it's understandable why someone wants to ship an app on time and budget goes with a web based solution.
Sorry if that wasn't clear, that was the point I was trying to make - Zed's UI worked oddly for me in subtle ways that I can't really give an example of right now, but created a sense of discomfort that made me give up on it after a short while.
I use Voyager, a client for Lemmy, on a daily basis and it’s my favorite mobile (iPad) app. Voyager is the spiritual successor to the Apollo client for Reddit.
The app uses Ionic’s Capacitor, which to my rudimentary understanding is the webview-based upgrade of Cordova. I’ve had far fewer issues with this app than the likes of Bluesky (react native) and Discord (I think also react native but not sure).
The webview approach seems to be the only way for a one-person team to feasible provide a cross-platform app with an app-store presence. Another promising alternative to Capacitor is Tauri Mobile which does essentially the same thing, but mobile doesn’t seem to be a high priority for them.
I installed this on Android, and unless iOS experience is massively different, this is not a good example:
- there's no touch feedback (ripple) on many of clickable components. Some that do have it look non-native, inconsistent and sometimes gets stuck
- the search bar on top app bar in `search` tab looks very non-native and non-standard (it's elevated on top of elevated app bar already)
- the lists look iOS-y, especially settings
- the settings list item has weird glitch where it loses background after touching (but not clicking)
- collapsing comments is pretty choppy (on a Samsung S25 so a pretty powerful phone)
- can't swipe down a bottom sheet (with post options/actions)
- it's just not android-y — the navigation is weird, the design is all over the place,
It's not unusable and it's a good tradeoff for a small team I guess. But this is nowhere near the experience a native app can provide, and has lots of small papercuts that would make for at least a slightly frustrating experience. It is a decent app don't get me wrong, but it's clearly not native
Like GP I haven't experienced many WebView based apps that are great so I had to give this a spin and I have to say it's actually pretty good! I would not have identified this as a WebView app if I didn't already know about it from this comment.
You are comparing web view apps to web view apps. “React Native” has muddied the waters here with intentional misuse of terminology. With React Native you still write a web view app - it just ahead of time compiles to run without the browser view on device. But it doesn’t use any native UI components, which is what “native app” used to mean.
I may have read your comment backwards but it seems rather wrong: react native DOES use native UI components, thats why it has “native” in its name. It’s also not compiled ahead of time per se, you still execute JS in the app (not in webview, yes) , but its mapped to native components
Thank you, it appears I was misinformed and/or conflating my knowledge of how flutter works. Mae culpa.
It does seem that many RN apps do React (not native) components when they need to do something custom, which may explain my sub-par, non-native experience with the RN apps I have used.
Even something “custom” is still a native component. The JSX you write eventually creates native views. Whether or not those views and components match the style and behavior of stock iOS or Android is a different story, and whether or not there are performance bottlenecks due to React Native’s bridge (now in theory no longer an issue because of a big architecture rewrite called Fabric) is another.
Well you haven't used the cutting-edge latest breed. Try using Uber in a browser. There's many high-quality apps today where you honestly cannot tell that it's a website running in a browser. There are many many more but I can only think of Uber off the top of my head.
Do you use iOS by any chance? On android I've very noticed performance problems. Even in apps like Discord and Instagram. But Google maps and Duolingo are pretty bad at times for example. So it's not webviews that are the common denominator here
Gathering all the metaphors (I know) here for reference:
- "All toupées look fake. I've never seen one that I couldn't tell was fake." [1]
- All CGI in movies looks fake. It jumps out at me every time I see it."
- All WebView apps suck. Every one I've seen has a bad obviously-web-derived UI.
re: that last one though -- I'd at least acknowledge that WebView apps are roughly at the end of the early-2000's era of CGI: not exactly "The Rock in The Scorpion King" bad, but generally not at the level of Avatar or Les Misérables.
Using webviews on native platforms can look very appealing from a management perspective: a single codebase, simpler coordination, reduced UX overhead, and faster iteration cycles.
However, from the user's side, this approach often results in a buggy, inconsistent experience that lacks the responsiveness and smoothness of a true native app that elusive "snappy" feeling (i know, I hate that word too)
Companies usually choose this route because it's cheaper, but that same "cheap mentality" often seeps into the overall product quality. Corners get cut, bugs get ignored, and long-term maintenance becomes a mess.
From a developer's perspective, it's a nightmare
You're essentially expected to deliver on three platforms doing the work of three people for the same $
In theory, any web developer could handle it. In practice, you need to understand all the native platforms just to maintain some basic, stable integrations even with frameworks like React Native.
The result?
Maybe 20% of your time goes into actual feature development, 30% into testing, and the remaining 70% into fixing obscure, platform-specific bugs while working overtime under pressure from cost-driven management.
In my experience, developers will do almost anything to avoid dealing with the native parts of this kind of setup those tasks usually get dumped on whoever is most "familiar" with native, because it's such a pain to handle.
And let's not forget QA testing across these hybrid layers is an absolute nightmare as well.
In the end, my view is simple:
If a company can't afford dedicated native teams, they probably shouldn't build a native app.
(Of course, smaller apps with limited complexity should be fine)
This comments spot on. Coming from a guy that used to do mobile professionally as a one man show where the company had multiple apps and multiple stacks. I had the least pain from the ionic stack which I guess is a happy middle ground, but even then there's always some new app store requirement changes to adhere that's almost a full-time job in itself.
Trust me, native camera access is extremely important if you need to directly control focus (for example). We have web and mobile apps that scan ID images and our ability to capture high quality images on mobile native devices is 5x better.
You can still have native views that appear over the WebView for certain tasks. I think you can also provide your own rendering context for <canvas> elements, so you could roll your own <video> element for showing the current camera view. Either way, you can still have full native camera control without having a 100% native app.
Isn't there a high chance your app is going to be rejected from app stores because you use a web view? You can change your whole app completely upon approval.
Or you ship your HTML/JS and not just embed a URL?
I just rolled my own. I always find frameworks bring too many “weird errors” that waste my time trying to figure them out. Also, they’re just another thing that needs upgrading eventually, and they love to COMPLETELY change their APIs between each major version. (“FrungisFactory is deprecated! Try the new async-fibre-layout BloopisGrid now before we completely delete that thing that worked perfectly for you!”)
The platforms provide more than enough capability to build basic WebView apps with minimal effort, and usually the DX is good.
Native escape hatch, for when you need native capability. For example, my app uses the Zebra DataWedge API on Zebra Android devices.
Native experience for users, where the app appears in their app drawer/library. The app doesn’t disappear randomly like shortcuts do on iOS (maybe this is fixed now?).
Better DX for certain features, like notifications, storage, control of caching, local network device access, etc.
It’s called a “WebView app” and you can get a really good experience on all platforms using them. Just:
- don’t make any crazy decisions on your fundamental UI components, like breadcrumbs, select dropdowns, etc
- add a few platform-specific specialisations to those same components, to make them feel a bit more familiar, such as button styling, or using a self-simplifying back-stack on Android
- test to make sure your webview matches the native browser’s behaviour where it matters. For example, sliding up the view when the keyboard is opened on mobile, navigating back & forth with edge-swipes on iOS, etc
I also went the extra step and got service workers working, for a basic offline experience, and added a native auto network diagnostic tool that runs on app startup and checks “Can reach local network” “Can reach internet (1.1.1.1)” “Can resolve our app’s domain” etc etc, so users can share where it failed to get quicker support. But this is an app for small-to-medium businesses, not consumer-facing, and the HTML5 part is served from the server and cached. I haven’t thought much about what you might need to do additionally for a consumer app, or a local-first app.