Apple Extends Deadline Requiring Apps to Stop Using UIWebView

[simmepi]

Long rant coming up!

Web views sometimes are crucial. For example in one of my apps, an RSS reader, a fundamental part of such an app is to show the actual content of an RSS news item. This is normally in the form of HTML, but not an HTML page you can visit on the net but an HTML string meant to show as a preview (some feeds include the whole article, some just a preview) of the actual web site article. Without *WebView this would be a hopeless task since it would mean you'd have to include the full code for a web browser in your app.

So you definitely want to have view which can be loaded with some random HTML code.

However, once a user press a link in this preview (or click to read the actual article on the web), now you want to use a standard browser, not an app-controlled *WebView. But when you do this in e.g. Facebook's app, you end up in a *WebView of FB's design -> they can check exactly what you do, your browser plugins won't work, keychain entries won't work, etc. And this sucks. The proper solution is either to immediately kick the user to Safari (in FB this takes some extra clicks), or use the SFSafariView which iOS provides which is essentially the complete Safari app running internally in the app: Plugins work, keychain works, and the developer has no way of knowing what's going on or what the user does (the only thing one can do with this view it to tell it to open with a given URL). This is what I do in my app, but I'm not the least interested in selling ads, checking what a user does, and so on.

I could allow a click to send you to the Safari app but on iOS that is actually a horrible UI since this would mean you'd have to jump back and forth between Safari & the RSS app all the time, so an internal Safari makes complete sense. I've gotten loads of requests for the app, but 0 about opening links in Safari since it's so obviously a bad idea, UI-wise.

IOW & IMHO:
- Use WKWebView when you for certain reasons have HTML which is not just a wrapper of an actual web page
- Use SFSafariView (or the actual Safari app) when you need to show an actual web page

Especially SFSafariView is missing in a lot of discussions about web views on iOS I've seen. I suspect this is because many apps think they need to know what the user is up to and track their doings, for advertising purposes or other things.

 

[Doctor Q]

Long rant coming up!

Web views sometimes are crucial. For example in one of my apps, an RSS reader, a fundamental part of such an app is to show the actual content of an RSS news item. This is normally in the form of HTML, but not an HTML page you can visit on the net but an HTML string meant to show as a preview (some feeds include the whole article, some just a preview) of the actual web site article. Without *WebView this would be a hopeless task since it would mean you'd have to include the full code for a web browser in your app.

Sometimes long rants are where you find the details that matter.

Could you clarify why you can't use WKWebView's loadHTMLString?

 

[simmepi]

Sorry if I was unclear! I do use that exact method when loading the WKWebView showcasing the preview of each RSS item, and I used the equivalent method in UIWebView before; the reason I didn't switch to WKWebView before now was due to performance issues* So I use the exact same methodology as I recommended in my own app: I use WKWebView for the RSS content, and then the SFSafariView when showing the associated web page.

*: My problem was that UIWebView is a quite stupid view when it comes to loading & rendering: If you call the loadHTMLString method, the view will do all its work immediately, no matter if the view is actually visible or not. In my case this was perfect since I needed to be able to swipe in a view which thus needed to be 100% completed (for the nerdy, I used UIWebViews in a horizontal UIPageViewController). WKWebView is smarter and does not render until it is necessary -> when swiping in this view in the app, one could now and then see the empty view. Nowadays though when the devices are so much faster, WKWebView is fast enough -> I could finally switch to it (or rather, WKWebViews in the UIPageViewController). If the HTML in the RSS is really complicated, I can still see the empty page for a frame or two, but honestly I'm way happier with WKWebView since so many other annoyances were solved when I switched to it.

 

[JosephAW]

This is just another way to purge perfectly good old 64 bit apps out of the store just as they did with 32 bit apps. With iOS 15 the api removal will render these old apps obsolete.
Just another way to force developers to re-up the $99 fee in order to update their app so they remains in the App Store.

 

[simmepi]

This is just another way to purge perfectly good old 64 bit apps out of the store just as they did with 32 bit apps. With iOS 15 the api removal will render these old apps obsolete.
Just another way to force developers to re-up the $99 fee in order to update their app so they remains in the App Store.

At least for now, any existing app using UIWebView will continue to be available in the store since this applies to new versions of old apps or new apps only. Nothing has been said about iOS 15 as of now.

Also, your logic is weird. If they disallow UIWebView in iOS 15 even for old apps, this will only lead to fewer developer paying $99: If you want an app in the store, be it old or new, you have to pay every year. So if you can’t/don’t want to update your code, there is no point in paying the annual fee. If Apple would allow old apps to remain without changes, more developers would pay the fee. So deprecation leads to fewer developers paying, not more.

 

[cmaier]

This is just another way to purge perfectly good old 64 bit apps out of the store just as they did with 32 bit apps. With iOS 15 the api removal will render these old apps obsolete.
Just another way to force developers to re-up the $99 fee in order to update their app so they remains in the App Store.

UIWebview has been deprecated for years - since around iOS 8. I went to the trouble of ripping it out of my apps two years ago for that reason. Developers have had plenty of time.

 

[chucker23n1]

UIWebview has been deprecated for years - since around iOS 8. I went to the trouble of ripping it out of my apps two years ago for that reason. Developers have had plenty of time.

That's not entirely fair. Plenty of features were missing in WKWebView compared to UIWebView.

 

[cmaier]

That's not entirely fair. Plenty of features were missing in WKWebView compared to UIWebView.

At a certain point you have to move on anyway. The writing has been on the wall for a very long time. I had to jettison one feature, and worked around several other problems by writing a lot of code that eventually I was able to ditch.