Is it true for Firefox as well? I remember Firefox wasn't available for iOS long time ago because of this issue but these days it is.

Yep, roughly speaking you can't compete on speed with your own rendering engine because you cannot do Just In Time style memory optimizations in the iOS sandbox.

Only Apple can ship that type of code, so any browser from the App Store competes on features with Safari, not on memory/speed etc.

All browsers on iOS have to use Safari, so Firefox for iOS is just Safari with Firefox's UI and Sync.

It is still true for Firefox. Apple does not permit or approve applications that can execute their own code. Such a thing permits you to have "webapps" that are not under the purview of Apple and the walled garden. As a result, all browsers are just reskinning Apple's browser.

They had to make a small exception for educational programming apps, but that isn't Firefox.

Nitpick: They don't "use WebKit" but Safari itself. They can only offer "web views" (which are always just Safari)

Edit: maybe this isn't entirely correct, Apple calls them WebKit APIs in their docs. Only the latest view is actually called `SFSafariViewController`

Most standalone browsers use WKWebView, which is a WebKit-based UI component that applications can interact with. SFSafariViewController is more appropriate for in-app browsers, because it provides UI and has very few customization points.

Most small apps have ditched the web view for safari due to speed, maintenance, and integration with things like password management and content blocker support - but the big guys like Google and FB which don't want to support an ad blocking vector or native share extensions still tend to use the WK framework.

WkWebView is used a lot in apps to present content that isn't immediately obviously web content, rather it is just using HTML/CSS as a presentation layer. One example is the activity feed in Instagram - I only know this because once upon a time the page lost CSS on a reload and I got to see it in all its link-blue-bordered glory.

The Safari controller is for when you're linking out to an external web site and want the user to behave the way they would in a normal browsing session.

A notable reason to use UIWebView is that it allows for changing network requests (for example, to add special headers). WKWebView does not because it runs out-of-process. So some of the web views you're seeing might actually be UIWebViews, depending on the context you're seeing them in.

WKWebView now does allow that, in a roundabout way, through WKURLSchemeHandler.

It seems like this can only be used to support URL schemes "that WebKit doesn't know how to handle"?

Yes, you create your own. In my example of the Instagram activity feed you'd point the view at instagram://activity-view or something like that in order to intercept the request and send a custom response. You could use the same method to "proxy" through to HTTP.

Like I mentioned, SFSafariViewController and WKWebView serve fundamentally different purposes; the former is for when you are trying to open a link and don't particularly care how it would be shown, and this would replace your own custom in-app browser implementation or opening links in Safari. The latter is used when you want to display a webpage and have full control over the content and the surrounding chrome, which makes it useful as both a general-purpose embedding view as well as the centerpiece of your browser app.