WebView vs WKWebView

MacOSX and iOS
1

I’m working on a client project to replace their existing macOS-only app (written in Swift) with a nice JUCE-y version that is Windows/Mac.

Here’s the difficulty that I’m running into: they are using a 3rd party authentication provider that handles all of the OAuth stuff through a RESTful API. We start the process by constructing a URL with query parameters and loading that into a WebBrowserComponent.

On Windows, my JUCE code runs through the authentication flow without incident. On Mac, the auth flow bombs out while things are at the auth provider (happening inside the browser component).

The client has helpfully created a minimal working version of their app in Swift, which starts the in-browser process and runs it to conclusion. Since the only variable here that’s under our control is that initial URL to load, I copied the URL that they create into my application as a string literal, and the system fails in the same way, so I’m confident that the problem isn’t in my code that constructs that URL.

The only visible difference that I can see at this point between the JUCE/C++ and Swift apps is that JUCE uses the older WebView component (now deprecated for apps targeting 10.10 or later) and theirs is using the current WKWebView component.

While we wait for the auth vendor to explain their error code:

  1. Am I off-base for thinking there’s any chance that the embedded browser component could have an impact here? (No, I don’t have a great hypothesis for how that might be the case. User-agent strings? Some other low-level header(s) that get added?)

  2. Are there plans to update the macOS WebBrowserComponent as 10.10 recedes further into the distance?

2

Are you doing this with Spotify?

I’ve run into the same issue with Spotify — it’s against their terms of service to use anything other than the latest system handler for authentication:

 @warning You must open this URL with the system handler to have the auth process
 happen in Safari. Displaying this inside your application is against the Spotify ToS.

Elsewhere in the code they specify that this must either be through SFSafariViewController or WKWebView, not UIWebView.

So it looks like we need to make some custom platform-specific code for this, until JUCE updates their web browser to use the correct classes.

3

This isn’t a ToS problem in my case – we ended up implementing an updated version of the browser component that uses WKWebView, and it works just fine on macOS versions after 10.10. Doesn’t work at all with the required auth system on 10.10 (blank window displays, doing a right-click to view source shows that all the HTML content is in fact present…but not operational), and we ended up just sniffing for that OS version and instead of opening the embedded browser component, launching the auth URL using the URL::launchInDefaultBrowser() method instead.

4

Makes sense — I figured this would be the approach for now. I do hope that JUCE updates their web browser to use the latest classes though, because this would also allow user-installed adblockers to work in JUCE apps!

1 Like