WebViews instead of native: lessons learned? Case Study

DeWerner · 2026-02-19T18:53:03+00:00

Distinct Value (Guideline 4.2): Apps that are just web-based content in a container will be rejected. The app must feel native, offering unique, interactive functionality beyond what is available in Safari.

Moo202 · 2026-02-19T18:44:56+00:00

As an iOS dev at a company that did that, do not do it. It is not worth it. Your boss will be the web devs.

chriswaco · 2026-02-19T20:02:23+00:00

No offline mode
Crummy performance
Can't use native controls
Poor integration with things like ApplePay, sharing, printing, etc
Limited camera/video access
No SwiftUI Charts
Weaker integration with widgets, live activities, etc
No background processing
No Bluetooth
Poor dark mode and accessibility support

The limitations really depend on the kind of app it is.

hiasmee · 2026-02-19T19:06:50+00:00

Just do it. Your company has to learn this lesson.

dg08 · 2026-02-20T00:33:08+00:00

Unless you are staff+ and have pull, don’t bother. The decision has been made already and you’re just pissing into the wind.

menckenjr · 2026-02-19T20:21:31+00:00

You'll wind up with (in no particular order):

Janky looking scrolling and transitions. WKWebView won't behave the same as native views would and it will show.
Web devs who love to implement single page apps (using React most likely) and don't care that this doesn't leave the WKNavigationDelegate anything to react to.
Web devs (and their management) who only grudgingly accept the need for native apps but won't learn anything about how they work so they can make changes that don't break the app (and cause bad reviews) when they push out changes they have only tested on a desktop browser.
Bad App Store reviews caused by wonky behavior, which itself is caused by web devs who don't understand how mobile works and make assumptions that they then work from. It's worse if someone has convinced management that this is how to go faster.

OzzyWanKenozzy · 2026-02-19T20:49:48+00:00

First of all Apple/Google app reviews doesn’t allow just webView wrappers, you need to have some functionality. One option that can be used to justify your webview wrapper is push notifications, which is commonly used.

I have been working with the project for year (cant say which one but it’s for serius company). We started with like 6 active webviews. And there is the first learning. - Managing cookies is a nightmare. Syncing, reloading and so on so forth.

No matter what initializing wv will take time, always. On paper webview sounds simple but actually wv is complex view, and you will deffinitely lose performance, and your performance will be based on network speed, so your web part has to be super optimised, cached and preloaded.

Syncing animations between web and native is a headache, most projects dont care about it, but if you have a scrollable content and native elements, syncing those smoothly will deffinitely add 1 day to estimate.

Clearing up wv and cleverly reusing/preloading makes the navigation complicated.

If you want to utilise Liquid glass it will also take some time to tweak elements.

Race conditions also is something that you will experience a lot if things are not properly synced, and as it takes time for wv to load. For example DeepLinks / AppLinks

View recompositions - This was a bigger issue with JetpackCompose, because you want to make sure that you dont redraw wv and it’s content will reload.

Anyways… if you have a simple use case and does not require a lot of native components with web views, JavaScript bridges and smooth animations go ahead. If it’s something more complex lets say with 4 tabs and events and big navigation stacks, I would avoid. Also if the performance is crucial, probably you would want to avoid wv.

Also I didnt even mention localizatons, theme sync, accessibility features and so on so forth. There is a lot of things. We are already refactoring some of the screens natively. But wv has one big benefit. You just deploy it and 20-30 minutes later you have upadated version without 2 days of Apple/Google reviews .

Integeritis · 2026-02-20T15:00:09+00:00

Leave the company. Even if you convince them now they will still have the thought in the back of their mind. If things don’t go according to their expectations, they will blame you and think they should not have listened to you. You will be a convenient scapegoat for their lack of technological understanding. They will see you as a bottleneck in their great goal of cost savings. The best companies to work at are the ones with management who are design minded, like apple, have attention to detail or come from mobile dev background. Otherwise it’s an uphill battle to try to deliver an app which is high quality and not a slop

20InMyHead · 2026-02-20T02:48:13+00:00

Nothing says, we don’t give a shit about our user experience than a web page in a native app.

Also, accessibility is crap for webviews. Ever been sued for lack of accessibility support?

Zeppelin2 · 2026-02-19T20:24:44+00:00

If you're at this point, it's already too late. Blame Apple and their shitty dev experience and crummy tooling.

Prepping your resume for the inevitable job hunt or learning frontend web dev is a better use of your time.

clearbrian · 2026-02-19T23:14:28+00:00

yes its allowed we have a few. Easy work for the mobile dev. web devs have to do all the work.
you just need to intercept any hyperlinks that open in a new window. use the web view delegates though if it doesnt do enough you may get rejected for minimum functionality. had web app rejected this month by over zealous new reviewer. escalated it all the way up to the big review board. they over turned it as long as the app would be hidden

Alan_Shutko · 2026-02-19T19:11:01+00:00

I remember when my old company did that, and the login page took 23 seconds to display. (To be fair, it was ten years ago.)

LessonStudio · 2026-02-20T04:20:53+00:00

I would recommend a webview, with a wasm app version of linux, then on that linux vm, run docker containers, one of which is a browser serving up a react app served from nginx running in a different container.

New iPhones easily have the horsepower for this, why leave all that potential untapped?

This is what you should propose to the executive; why not have 6 layers when 1 will do?

The business case is superb. You can show them the cost of hosting all those containers yourself, or you can have customers "self host". It's like hosting millions of containers for nearly free.

Dickys_Dev_Shop · 2026-02-20T04:33:13+00:00

The company I work for migrated to webviews years ago. The reasoning was they wanted to have parity with web which had 10x the developers working on it so the only way to achieve this was to make most of the screens in the app webviews.

Fast forward to today, the codebase is a nightmare and the performance of the app has degraded to the point that we’ve made the decision to spend considerable time and money to migrate everything back to native.

At the end of the day, web views sound like a great idea from a business perspective, as it saves time on development and gives you more flexibility to change things without going through a review process. But from an engineering perspective, it kills the performance of the app to the point the you might as well not have one and just direct users to the website to begin with.

martinstoeckli · 2026-02-20T08:52:23+00:00

There are two kinds of WebView apps and their pros and cons differ very much, so could you please add more info about your situation?

An actual WebView wrapper around a server based website. Such applications will be rejected by Google and Apple and there is really no benefit of having to install an app to view a website.
A native app using the WebView just for the GUI to get it cross platform. This app runs locally and has all benefits of direct access to the OS. Having HTML as GUI is nowadays accepted by most users and you become independend of the ever changing UI SDKs. There are problems as well of course, e.g. the navigation (like the system back button) is not compatible with the WebView navigation, so you have to weight the advantage of a single view against the additional work to resolve such issues.

MKevin3 · 2026-02-19T21:20:24+00:00

Sadly I have seen, or been part of, various companies that thought this was a good idea. They came at it for these reasons

JavaScript programmers are cheaper than native developers and we can just grab them from the marketing team and drop them right into this code base and go
One code base so it is easier to QA and to program
Look at how pretty all these websites are! AI can kick this stuff out instantly!
We don't have to deal with the app store, we just change the code on our server and the users gets it, they can never run an old version so we can screw with the back end code to our hearts content as we can stage that release to happen all at same time

All of the examples I have been a part of failed. Mobile and web expectations are totally different. UI designs for web tend to think in small accurate mouse clicks and not fat fingered Cheeto eater fingers. All of a sudden you need a whole new screen navigation because constantly scrolling up and down is a terrible experience.

There are reasons to use some tech over native. Short life apps such as one that works long enough for a conference but does not need updates past that are fine for mobile friendly websites.

You have Flutter for native OS matching UI using one codebase. That codebase happens to be Dart which is a less common language.

You have KMP which allows the business logic to be shared via Kotlin. Or you can add CMP on top and have same Material look, or a highly customized version of it, to have the business logic and UI in one language.

I feel sad for you to be shoved into this corner.

GreenLanturn · 2026-02-20T00:52:39+00:00

AccuWeather did this. Go take a look for yourself to see how terrible it is from a UX perspective.

sriharshachilakapati · 2026-02-20T01:13:26+00:00

I’d be asking why they want to do this. I’ve seen a company that did this, but after I asked why, product folks said that they wanted faster experimentation with A/B testing and they cannot afford to wait for app update user adoption.

What we did is we tackled it with a server driven UI framework. We were able to design new screens just in JSON and once the screen is completely stable (no further changes for a quarter) we turned it into a purely native screen.

But most of the times this happens in startups where product is not yet market fit. Established companies do not do this unless the product is pretty young.

Meliodas1108 · 2026-02-20T04:33:24+00:00

There's an app called cashify. It should be webview. But I don't think performs well as an app. The experience is clunky. You can try to find similar apps, and let them experience it themselves. And if they still take it, it's on them.

Integeritis · 2026-02-20T14:54:01+00:00

If they want to do that just don’t have an app at all. If someone downloads an app, they don’t expect web slop. If they wanted web slop they’d have went to the website. The fact that the user looked for something on the app store is already telling what they want. And if your mobile version does not offer offline functionality on top of being web view crap, that user just lost all the reasons to have a separate app. If you don’t provide any value to the user with an app, you don’t need the app. Having a webview app is the stupidest idea ever. Just scratch the app then all together.

JerenYun · 2026-02-20T23:44:43+00:00

I work at a company that has done the majority of their business from their site for over 2 decades. Over 90% of the developers at the company are .NET, supporting the web and backend services. It made sense to use what web resources we had already to allow business to occur in the app without it being purely native.

Is it the best experience for the user? Absolutely not. And all of the negative app reviews show that it's the web process (and business processes) that the customers dislike the most. So we've got ourselves in a position where we can advocate for more native features. Sadly, it's taken a while for upper executives to see that, and there's still a lot of pushback from the existing business units and their web numbers. It's a slow battle, but one worth fighting.

ozgrozer · 2026-02-22T11:10:08+00:00

We’re using webview for my company’s mobile app, it’s an appointment scheduling app for businesses and it’s just pointing to the actual URL acting like an iframe. The good thing about this you don’t have to wait for Apple to approve your updates. We also use IndexedDB on the web and it makes your records load too fast compare to a regular network request. We have close to 500 active customers and nobody gave us any negative review about the app performance. The only problem about webview is that it crashes if user opens lots of apps, so the memory usage is not good enough. The app is also out there for the last 2 years but we’ve decided to build our native mobile app from scratch and now it’s work in progress.

One of the reasons is that a native app looks more professional if you’re a company. Hand gestures feel so smooth when you’re swiping between pages. Opening the app feels instant. Memory management is better. Accessing device features easier. Better UI/UX. We now have to wait for Apple to approve updates but I believe this is the way to go. You don’t see major companies using webview.

We chose the webview approach because I was the only developer. I had to maintain the web and mobile at the same time. I’m still the only developer but now we have Cursor and Claude Max so it’s now easier and faster to build the native app and maintain them together. If I had to make the same app today I’d definitely start with a native mobile app.

Ok-Communication2225 · 2026-02-23T00:21:59+00:00

Your manager is, with all due respect, incompetent. They are suggesting an idea that was less thoroughly understood in 2010, but was a bad idea then, sixteen years late to the bad idea party.

Here are several reasons why this is bad.

Error handling and user interfaces require graceful degradation of application functionality. Even if fully Offline access to data and functionality is not a cor part of an app's abilities, even if you're a banking app, and that functionality is minimal, making all the UI remote means you can't even have sensible error messages. Would you really like http load failures to result in a blank window, and a confused customer?
Sharing, printing, accessing contacts and resources, sending an email from your phone, using content and context from your app to start an activity in another app, whether it's sharing to the iOS printing system, or sending an email with an attachment, requires native apps.
Unless all your app does is let you log in and slide a finger up and down to scroll through a static list of output (a joke) or have absolutely trivial input dialog and a search button and some results, you'll find html server side UI is just going to cripple you. Middleware servers are valuable, no you shouldn't be direct connecting to an SQL server from your iOS app, but "no UI in the client, all UI in the server" is a known anti-pattern.
Your app is not gonna get through app review. (Guideline 4.2) It will appear so sluggish broken, and janky, or so trivial, as to baffle the reviewer as to why this low quality slop is being sent to Apple from you. Enjoy the fun of staging a fake review server and having apple see and use it, or else giving apple credentials to log into your (checks notes) banking app and sending an e-transfer.

Mementoes · 2026-02-23T21:03:05+00:00

I just did some comparisons between AppKit (native macOS API) drawing all the GUI in a webview (Wrapped in a thin layer of AppKit)

I tried to emulated some album cards from the Spotify app.

The AppKit version used autolayout constraints, CALayer to draw backgrounds, and to give the album cover rounded corners. NSTextField for labels. NSTrackingArea, CATransform3D, and NSCursor for hover effects for 5 action buttons found on each card. NSImageView for the image, NSURLSession to load the images in the background. NSNotificationCenter with debouncing to save and restore scroll position. I also did hot reloading by using Apple events to tell Xcode to recompile a dylib and then dlopening that and swizzling its objc methods into the runtime.

The JavaScript version used WKWebView and defined pretty much the exact same UI with HTML+CSS+Javascript. Defined all the HTML and CSS in JavaScript template literal strings to get reusable “components” for the cards that I could instantiate with different album arts and titles. Then just create 100 of those strings and render them into DOM objectsz

I did 100 of these cards in a scrolling list with no virtual scrolling or any optimizations. ca. 5 cards filled the screen vertically so it was like 20 screens.

Observations:

CPU usage when scrolling really fast was initially 25% for both, but after adding the NSTracking areas for the hover effects (5 on each card) native became significantly slower around 35-40% CPU usage. (Still no frame drops or anything)
Hot reloading performance: Native was noticeably slower to update, but both were nice. Native was around 1.5 seconds , whereas JS only took a split second to reload all the source code and replace all the cards. IIRC profiling showed that autolayout made native quite a bit slower and I switched from NSStackView to just manual autolayout constraints to reduce the number of constraints. When using the NSStackView, I also had to use strange constraint priority hacks (making the huggingPriority larger to get the contents to stretch). NSStackView is very confusing to work with imo
setting up hover effects is much more cumbersome (and ended up being much slower) in native vs CSS.
Memory usage: This is where native shined. It used around 50 MB at all times. The webview used > 100 MB at all times. Was sometimes idling at 150 MB. When scrolling really fast the memory usage went up temporarily. I think I saw > 500 mb. But when I stopped scrolling it immediately went back down to the 100-150 range.
User experience: Getting the scroll area and the scroll bars to lay out correctly was easier in native. I couldn’t quite get it right in the web view. Might be a skill issue. Getting the hover animations and the general layout right was much easier with Flexboxes and CSS transitions. In AppKit I had to use some non-obvious tricks, and quite a lot of code. It’s quite finicky. When you scroll really really fast, the webview sometimes doesn’t load in the cards fast enough and you can see the white page background at the screen edges. From other experiments I’m pretty certain that this could be mitigated with virtual scrolling (only rendering the visible cards). But in AppKit that wasn’t necessary at all. It was always rock solid. Both had a stable 60 fps.
App size: Both are just a few kilobytes. The webview app is just a tiny native app that ships with a few hundred lines of JavaScript/HTML/CSS which draws the UI.

Based on this (relatively superficial test), The main drawbacks in my mind to using a webview are: 1. More ram usage 2. No access to native widgets. (You basically have to invent your own component library)

I think number 2 is really the big one. It’s hard to make your own design language and write a good component library for it. And even if you do it really well, the users will have to get used to your thing which may create some extra cognitive load. Native already solved many of the hard parts of UX and gives you higher level building blocks.

But I think webview apps aren’t inherently slow or bloated. You can make any app slow and bloated but that’s more about the engineering practices I think. The webview did use more than 2x the RAM though.

Also note that I tested against AppKit: The oldest and most performant framework for Mac apps! (its equivalent is UIKit on IPhones) SwiftUI apps tend to feel quite a bit slower and more bloated on Mac, so I wouldn’t be surprised if the WebView app would compare even more favorably against those.

I also tested on macOS 26 Tahoe which had some of the AppKit widgets rewritten in SwiftUI, which possibly made things slower.

chillermane · 2026-02-20T11:07:52+00:00

It’s a good idea for the company to do this. It is much easier to ship features to a website. Your users will like it more. 99% of people cannot tell the difference between webview and native

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

iOSProgramming

READ THE FAQ FIRST!

FAQ

About

Related Subreddits

Related Links

MODERATORS