5 ms·

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 cra

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.

arcanemachiner 10mo ago
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.
sebmellen 10mo ago
Works until you need complex native code for things like automatic image capture assisted by a bounding model.
- littlecranky67 10mo ago
  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.
  - sebmellen 10mo ago
    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. AVFoundation on iOS especially.
    - DecoPerson 10mo ago
      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.
      - sebmellen 10mo ago
        Yes not disagreeing there
adastra22 10mo ago
I have never once experienced a WebView app that I would say had “a really good experience.”
- serial_dev 10mo ago
  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…
  - smokel 10mo ago
    Is this what you mean? https://news.ycombinator.com/item?id=45250759 https://news.ycombinator.com/item?id=45250759 (In the context of "Apple has a private CSS property to add Liquid Glass effects to web content")
    - serial_dev 10mo ago
      Yes, thank you!
      - hn8726 10mo ago
        > 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_.
  - jmb99 10mo ago
    > 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?
simjnd 10mo ago
What is your app? Would love to try it out to get a feel for the experience.
lenkite 10mo ago
Do you use some framework for "WebView app" ? Like Tauri, etc ? Or is everything coded from scratch ?
- DecoPerson 10mo ago
  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.
fakedang 10mo ago
Perhaps you mean PWAs and not WebView apps? WebView apps suck big-time. At least now I know who the offending devs are.
tiborsaas 10mo ago
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 10mo ago
  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 10mo ago
  Not a problem if you’re deploying using MDM.
gcanyon 10mo ago
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 https://news.ycombinator.com/item?id=45250878
mesm3 10mo ago
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 10mo ago
  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.
e12e 10mo ago
How is a WebView app better than a webapp?
- DecoPerson 10mo ago
  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 10mo ago
  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.

arcanemachiner 10mo ago

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.

sebmellen 10mo ago

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

littlecranky67 10mo ago
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.
- sebmellen 10mo ago
  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. AVFoundation on iOS especially.
  - DecoPerson 10mo ago
    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.
    - sebmellen 10mo ago
      Yes not disagreeing there

adastra22 10mo ago

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

serial_dev 10mo ago
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…
- smokel 10mo ago
  Is this what you mean? https://news.ycombinator.com/item?id=45250759 https://news.ycombinator.com/item?id=45250759 (In the context of "Apple has a private CSS property to add Liquid Glass effects to web content")
  - serial_dev 10mo ago
    Yes, thank you!
    - hn8726 10mo ago
      > 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_.
- jmb99 10mo ago
  > 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?

simjnd 10mo ago

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

lenkite 10mo ago

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

DecoPerson 10mo ago
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.

fakedang 10mo ago

Perhaps you mean PWAs and not WebView apps? WebView apps suck big-time. At least now I know who the offending devs are.

tiborsaas 10mo ago

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 10mo ago
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 10mo ago
Not a problem if you’re deploying using MDM.

gcanyon 10mo ago

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 https://news.ycombinator.com/item?id=45250878

mesm3 10mo ago

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 10mo ago
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.

e12e 10mo ago

How is a WebView app better than a webapp?

DecoPerson 10mo ago
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 10mo ago
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.