7 ms·

Working at a company that uses react-native I wish nothing more than for the end of app stores and differing platform languages. We're heavily considering just

• FlamingMoe 11mo ago
  Wholeheartedly agree.
• DecoPerson 11mo ago
  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 11mo 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 11mo ago
    Works until you need complex native code for things like automatic image capture assisted by a bounding model.
    • littlecranky67 11mo 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 11mo 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 11mo 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 11mo ago
            Yes not disagreeing there
  • adastra22 11mo ago
    I have never once experienced a WebView app that I would say had “a really good experience.”
    • serial_dev 11mo 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 11mo 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 11mo ago
          Yes, thank you!
          • hn8726 11mo 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 11mo 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?
  • lenkite 11mo ago
    Do you use some framework for "WebView app" ? Like Tauri, etc ? Or is everything coded from scratch ?
    • DecoPerson 11mo 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.
  • simjnd 11mo ago
    What is your app? Would love to try it out to get a feel for the experience.
  • fakedang 11mo 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 11mo 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 11mo 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 11mo ago
      Not a problem if you’re deploying using MDM.
  • gcanyon 11mo 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 11mo 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 11mo 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 11mo ago
    How is a WebView app better than a webapp?
    • DecoPerson 11mo 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 11mo 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.
• cyberax 11mo ago
  That. And specifically, fuck Apple and their prohibition on JITs. We have a React Native app that shares some code with a webapp, and that needs to do some geometry processing. So we're constantly playing the game of "will it interpret quick enough". Everything works fine in browsers, but in a RN app it often slows down to unusable speeds.
  • Torn 11mo ago
    Could your processing work in a webview? i.e. webgl or webasm or similar and you communicate with it via postMessage. Something like Polygen might help with the scaffolding, but I have not tried it personally
    • cyberax 11mo ago
      No, it's far too brittle. The latency is also terrible. In our case, we had to reimplement some parts in C++ to have reasonable performance.
• rTX5CMRXIfFG 11mo ago
  I personally have a preference for Apple's native frameworks. From a purely engineering standpoint, they're very well thought out and have very clear separations of concerns. Spending my time with their libraries helped me write good, scalable code for platforms beyond their own. That said, platform lock-in is bad for business because it makes operations dependent on a single provider, but I have no delusions that a web front-end is better. From an engineering standpoint, front-end web frameworks are less complete and require too many third-party libraries and tooling to assemble. From a UX standpoint, it's actually worse--almost every website you visit today spams you upfront with Google sign-in and invasive cookie permission requests that you can't refuse. But never mind that--from a purely business standpoint, a single platform accessible anywhere saves costs. Most importantly, however, the web is a "safe space" for deploying software anti-patterns without an intermediary entity (i.e an app store) to police your code, so you can do whatever the heck you want. I'd wish for nothing more than the end of web and app front-ends in favor of purely structured data derived from natural language prompts by users. However, the more realistic mindset seems to be that: the front-end layer is such a high level of abstraction with a very low barrier to entry, so that its tech stack will be in constant flux, in favor of whoever's currently the best-financed entity seeking the most market share, the most developer mind-share, and the most behavioral control among its users.
  • cageface 11mo ago
    Their Cocoa based frameworks were good for their time, I'll grant you that. Swift & SwiftUI, at least in their current state, are a mess with some pretty fundamental issues.
• blub 11mo ago
  It’s a bad idea to put the fox (front-end developers) to guard the henhouse (great, consistent user experiences).
  • khalic 11mo ago
    lol, yeah what do front ender devs know about UX. SMH…
    • zelphirkalt 11mo ago
      Unfortunately, all too often not enough. But then again often one has UX designers for that, but they are all too often off to build flying castles in Figma.
      • zdragnar 11mo ago
        Visual design is only one part of UX- interaction design and information architecture are equally important components. At my last two jobs, when I did v front end work I had to coach designers through UX on a regular basis, because the designers did as much for the marketing department as they did for the development team. Sadly, UX as a discipline doesn't get much love from most companies.
    • array_key_first 11mo ago
      Most of UX design for the past ~15 years has been new and innovative ways to trick users, lie without really lying, and annoy your users just enough so you can extract what ever you need to extract, but not too much such that they actually leave. If you want to create good UX, I would look at whatever the big dogs are doing (Amazon, Meta, Google, et. al.) and not do that.
    • bigstrat2003 11mo ago
      In my experience? Very, very little.
• DeathArrow 11mo ago
  Then why bother making an app? The user can access the web app using the browser.
  • johnisgood 11mo ago
    We (they) wanted "easy accessibility" and "constantly seeing this app's icon" bs.
    • szundi 11mo ago
      [dead]
  • yetanotherjosh 11mo ago
    So you can get native behaviors when it’s critical. Like share sheets, push and many other critical features that only apps get even if the bulk of the experience can be done in a webview. This is because mobile OS platforms choose not to make these available to web apps, because app store profits are better for them than an open ecosystem where sites can do the same things as apps.
    • hjort-e 11mo ago
      Both the things you mention have been possible on web and widely supported for a while. https://developer.mozilla.org/en-US/docs/Web/API/Web_Share_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Share_A... https://developer.mozilla.org/en-US/docs/Web/API/Push_API https://developer.mozilla.org/en-US/docs/Web/API/Push_API And not having to wait a week between bug fixes being deployed is a major selling point that native just can't compete with.
• logicprog 11mo ago
  CapacitorJS makes for a REALLY awesome app dev experience compared with React Native. It's basically just a really well integrated system for building exactly what you describe. The company I work at made the switch from an RN app to a CJS one and it was might and day in so many ways, performance included!
  • mexicocitinluez 11mo ago
    How is this different than Expo?
  • isaachinman 11mo ago
    This is laughably wrong. Expo exported to a web target is the same or better than Capacitor.
• _kidlike 11mo ago
  we shipped this last year. Best decision ever. I saw another comment calling it "webview app", which is also valid, but we call it "hybrid app".
• saubeidl 11mo ago
  You could just use Kotlin Multiplatform and Multiplatform Compose instead.
• maxloh 11mo ago
  I recently downloaded the Moodle app and was surprised to find it's powered by Ionic and a webview, which I only realized due to CSS misconfigurations that caused the app to fall back to Serif font for CJK glyphs. Recent mid-tier phones are powerful enough that webview has a negligible impact on performance.
• sandGorgon 11mo ago
  https://developer.android.com/develop/ui/views/layout/webapps/trusted-web-activities https://developer.android.com/develop/ui/views/layout/webapp...
• Razengan 11mo ago
  Using apps made with Electron or those so-called "universal" UI frameworks I wish nothing more than for everything to be native. They always have to give up some basic or hidden conveniences that native controls get for free, so they always feel slightly different and "off" in a weird way which induces a constant vague annoyance while using them, like walking with a little pebble in your shoe, or a sitting in an chair that isn't balanced right. It's funny how even after 50 years UI still isn't "solved" ..before writing a universal API, we don't even have universal consensus, or at least some kind of standards authority, on how controls should behave. Hell not even users can’t agree, as would be seen on any comments about this topic, on stuff like whether lists should scroll up when swiping down, or scroll down when swiping up :')
  • szundi 11mo ago
    [dead]
• scosman 11mo ago
  I try this every decade. Love the first few months for speed. Then I end up paying the price later when I want to integrate "new OS feature X" or make a system gesture/style/animation feel native. Lack of swipe for back on iOS is usually the easiest way to tell I'm looking at a web view. But it's been about a decade so I'm due...
  • qw 11mo ago
    Swipe to go back can be implemented in frontend. It's been a couple of years since I used it, but I think the Ionic framework has this feature. https://ionicframework.com/ https://ionicframework.com/
  • hjort-e 11mo ago
    Lack of swipe back actually isn't an indicator. Apple doesn't even follow that pattern everywhere
    • port11 11mo ago
      I see some downvotes but you're correct. For example, in the App Store feature cards swipe left only bounces the card, you have to keep swiping to close. Swipe down closes it at once. It's not that far from the usual but has always felt strange to me. This same gesture won't close Home's new accessory card.
      • myko 11mo ago
        Isn't the App Store heavily webview based? Apple doesn't follow it but one of the complaints in this thread is that Apple has been overusing WebViews
• Alifatisk 11mo ago
  Isn't this how Hotwire works with Rails?
• geokon 11mo ago
  that only works if you have a simple app that displays some stuff from a server. if you want to do something actually requires some compute, then suddenly this doesnt work so great ex: youre prolly not going to want to edit images in JS
  • officialchicken 11mo ago
    The <canvas> tag using webgl offers a lot lower access to buffers than you might imagine and is very accessible using JS/DOM. I've gotten surgical AR devices approved from FDA - if it works good enough for life or death situations - it can certainly work for a toy app.
• seanwilson 11mo ago
  > its nearly better to write your business UI 3 times one for each platform. Anyone have any experience of doing this for a complex and long-life app? Sounds like a nightmare that would increase friction and decrease development fun by x10 because of the huge overhead and tedium of having to keep your features and tests in sync across platform for every change you want to iterate on, and requiring developers be proficient at multiple stacks. I get the usual complaints about bad webview implementations, but separate native codebases sounds like a prohibitively enormous tradeoff if most users only perceive the UX as being a little better than a good webview implementation. I feel like I'm missing something that native codebases is suggested as if it's a simple alternative, or this is coming from people that aren't actually involved in this?
  • skydhash 11mo ago
    You don’t do that though. You write your logic in a common languages and then the UI is an external layer you switch with build settings. The thing is, yiur choice is usually c|c++. Or an embedded language like lua. RN has gone the latter route and then extend it further by using React as a DSL for the UI.
    • seanwilson 11mo ago
      > You write your logic in a common languages and then the UI is an external layer Isn't reimplementing all your UI widgets, views, layouts and interactions for multiple platforms still a ton of work though? I'm not meaning people using things like React frameworks, but the suggestion of sticking to native only.
      • skydhash 11mo ago
        If you do that, then you intent to take advantage of the native framework (or a mature one like qt for some platform). They are really expansive and you can create an interface very quickly. You usually get animations, themability, navigation,… for free and you’re mostly arranging the layout and writing glue code. Also, you usually get better tooling in regards to instrumentation and the like.
• j45 11mo ago
  It's rarely better to write the business UI 3 times for each platform. At the time such decisions are made, maybe the platforms couldn't do what was needed, but those platforms do tend to evolve, but not remain tracked. Flutter to me has been one of the platforms that can quietly ship to multiple platforms as long as the parameters of what you're after can be accomplished in Dart, and if needed a bit of custom code for any particular platform.
• flanbiscuit 11mo ago
  Is Cordova still actively developed? Or are people just rolling their own per OS these days?
• bob1029 11mo ago
  If you still need to wrap a cross-platform web experience in a native container, I really begin to lose the plot. Once you are engaged with the iOS code signing monster, you might as well go all the way into the ecosystem. To me, the web is the way around the app stores and codesign. I know how to visit HN on my iPhone despite there not being an official native app for it. It can work. The challenge is making it work in your particular case. Fear that the user wont know how to access the product seems to be a primary factor driving hyperbolic takes on how consumer apps must be built. Perhaps a bit of marketing budget (scan this QR code / visit this link) could eliminate a very expensive tech problem. Why fight visibility in the crowded App Store when there are countless other advertising channels you could pour your resources into? > native code for the native notifications, GPS and healthkit / health connect. Modern web can address everything here but the HealthKit item. You could consider handling this with a simple companion application that is exclusively about the collection and transfer of the data while respecting user privacy & consent procedures.
  • exhaze 11mo ago
    Push notifications and mental real estate by being “an app” are the primary business reason (based on both statsig experiments I’ve seen across my career as well as some intuition about behavioral psychology regarding the app mental real estate bit).
• ojr 11mo ago
  AI doesn't change the Apple Guidelines, I write my business UI once and translate it between React Native and React using an LLM 4.2 Minimum Functionality Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value or adequate utility, it may not be accepted. Apps that are simply a song or movie should be submitted to the iTunes Store. Apps that are simply a book or game guide should be submitted to the Apple Books Store.
• rock_artist 11mo ago
  With the first iPhone Steve Jobs wanted a web based future. Then jailbreaking got us native apps and AppStores and the rest is history. I still remember my Nexus One running flash! Anyway, I wonder if the web path would’ve been the chosen one, how Apple would’ve played the web standards that are crippled today especially on Safari.
• culi 11mo ago
  Would love to see it. Even Apple's support for PWAs has come a long way. Still can't list them on the app store though
• spease 11mo ago
  I started with desktop applications, so my go-to for GUI has been Qt, especially QML. It works on Windows / MacOS / Linux as well as iOS and Android. I think there’s now a way to compile QML to webassembly as well. It also has a ton of support classes that are loosely analogous to the various *Kit things supplied on iOS and Android. The downside is that the core of Qt is in C++, so it’s mostly seen (or used for?) embedded contexts. I recently used Slint as well, which isn’t anywhere near as mature, but is at least written in Rust and has some type-safety benefits. SwiftUI is pretty good too, and I wish I got to work on Apple platforms more. To me, the simplicity of creating a “Button” when you want a button makes more sense, instead of a React component that’s a div styled by layers of CSS and brought to life by JavaScript. But I’m kind of bummed that I started with that route (well, and writing partial UI systems for game / media engines a few times) because most people learned web apps and the DOM, and it’s made it harder to get the kind of work I identify with. So it’s hard for me to recommend Qt due to the career implications…but at the same for the projects I’ve worked on, it’s made a smaller amount of work go a longer way with a more native feel than electron apps seem to have.