aswebauthenticationsession

New in iOS 17.4 is the ability to set headers on an instance of ASWebAuthenticationSession. Like NSURLSession, simply add to the new additionalHeaderFields property. However, this is not the only change. There is now a new initializer, initWithURL:callback:completionHandler:, which leverages the new ASWebAuthenticationSessionCallback class. This allows developers to more strictly control callback behavior by differentiating custom schemes and HTTP URL schemes....

ASWebAuthenticationSession uses a technology limited for Apple use called remote view controllers: <SFAuthenticationViewController 0x7f9d21082200>, state: appeared, view: <SFSafariView 0x7f9d21a04da0>, presented with: <_UIFullscreenPresentationController 0x7f9d21a04b10> | <SFBrowserRemoteViewController 0x7f9d21075c00>, state: appeared, view: <_UISizeTrackingView 0x7f9d1f5658e0> Additionally, you do not get access to the view controller created when you start an authentication session, rather, you only get the opaque session object to retain until authentication is complete. This leads to an interesting problem where the controller is being managed exclusively by Apple and it attempts to adapt its presentation to the application’s content and it chooses something that does not fit your needs....

UI testing provides additional opportunities to validate the correctness of your application. One challenge though is that sometimes, certain workflows interrupt the test execution, for example, requesting camera permission. To solve this, Apple provides the interruption handling API. However, there is a small problem when ASWebAuthenticationSession is in play. For some reason, when the ASWebAuthenticationSession prompt occurs, the interruption handler needs some help realizing that the prompt is blocking the application....

As I have written before, the API provided by Apple to implement SSO via Safari leaves a lot to be desired. One of the main concerns is that starting a session automatically prompts for permission and if the user cancels, it can leave the user in a weird state. On top of that, the permission allowance is not remembered, so alert fatigue becomes real. Therefore, I decided to look at other Apple APIs to see how permission onboarding occurs to find better implementations....

If you have an iOS application that contains sensitive information, you should be obscuring it somehow when the user leaves the application so that the system does not save a screenshot of the content and so that it is not viewable in the app switcher. Typically, you would do this by replacing the view hierarchy of the application’s window with a view controller with some static content and then restore it when the user returns....