[DecoPerson]

I did this and never looked back.

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.

[adastra22]

I have never once experienced a WebView app that I would say had “a really good experience.”

[serial_dev]

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…

[creichenbach]

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.

In case you're interested, the app is named "QuickÖV" - not relevant to anyone outside Switzerland, but just for trying it out: https://play.google.com/store/apps/details?id=com.billhillap...

[torginus]

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.

[erlend_sh]

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.

https://github.com/aeharding/voyager

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.

[kelvinjps10]

Obsidian. In android it's the best markdown editor.

[sheepscreek]

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.

[hjort-e]

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

[gcanyon]

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.

1. https://news.ycombinator.com/item?id=45250878

[arcanemachiner]

I made a (hobby) project that utilized this strategy (Flutter + wrapped webview app), and it honestly seems like the way to go for my needs.

[mesm3]

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)

[bickeringyokel]

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.

[sebmellen]

Works until you need complex native code for things like automatic image capture assisted by a bounding model.

[littlecranky67]

There is no reason you can't do that via web. Image capture in a canvas gives you access to the raw image pixmap data.

[tiborsaas]

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?

[hjort-e]

It's mostly shipped with the web assets. But yes that would make it very difficult to get approved by Apple. Not by Google though

[DecoPerson]

Not a problem if you’re deploying using MDM.

[lenkite]

Do you use some framework for "WebView app" ? Like Tauri, etc ? Or is everything coded from scratch ?

[DecoPerson]

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.

[simjnd]

What is your app? Would love to try it out to get a feel for the experience.

[e12e]

How is a WebView app better than a webapp?

[DecoPerson]

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.

[WhyNotHugo]

A WebView satisfies everyone who insists on using a native app for something that could have just been a website.

And it’s still usable as a website for everyone else on any platform.

[fakedang]

Perhaps you mean PWAs and not WebView apps? WebView apps suck big-time.

At least now I know who the offending devs are.