SFSafariViewController or WKWebView


#1

When will JUCE update it’s iOS & macOS WebBrowserComponent to use the latest recommended classes?

It is very common for authentication purposes with a 3rd party API to need to display their portal in a separate web view, and for some (at least for Spotify), it is against their TOS to display this in anything other than a SFSafariViewController or WKWebView. Is it on the horizon for JUCE to switch to these newer classes? UIWebView is depreciated.

I also think it could be useful to have a common API for this style of authentication flow (aka display an authentication URL in the native web browser & register custom response URLs, such as spotify-auth://callback). Right now I need to handle these response URLs in anotherInstanceStarted, which seems like the wrong place conceptually for this kind of thing.

More info here: https://developer.spotify.com/documentation/general/guides/authorization-guide/

Though I’m sure most people are familiar with this style of authorization, given it’s the default for the giants like Facebook, Google, Spotify, etc.


#2

I can put the task on the backlog, but no promises on any delivery dates I’m afraid.


#3

No problem! I’m writing my own wrapper anyway, will post the repo here when its done if that helps. I know this low priority but it definitely should happen at some point.


#4

@cpenny did you do this?


#5

Nope! I instead just used Objective-C to do everything… works for my project but wouldn’t be useful on its own in relation to JUCE. Had to make my own custom App Delegate and everything. It would be great to see some progress from the JUCE team for this. It seems that full spotify integration could be a useful feature for a project like JUCE. Plus many other services use a similar Auth Token flow.