I'm currently using a WKWebView to load certain types of documents via loadRequest, but I've recently been running into an issue with .doc files doing this: static NSString *customScheme = @"customscheme"; @interface WordDocWKSchemeHandler : NSObject <WKURLSchemeHandler> @end @implementation WordDocWKSchemeHandler { NSData *_data; NSString *_mimeType; } - (instancetype)initWithData:(NSData*)data mimeType:(NSString*)mimeType{ self = [super init]; if (self) { _data = data; _mimeType = mimeType; } return self; } - (void)webView:(WKWebView *)webView startURLSchemeTask:(id<WKURLSchemeTask>)urlSchemeTask { NSURL *url = urlSchemeTask.request.URL; if (![url.scheme isEqualToString:customScheme]){ return; } NSURLResponse *response = [[NSURLResponse alloc] initWithURL:url MIMEType:_mimeType expectedContentLength:_data.length textEncodingName:@""]; [urlSchemeTask didReceiveResponse:response]; [urlSchemeTask didReceiveData:_data]; [urlSchemeTask didFinish]; } - (void)webView:(WKWebView *)webView stopURLSchemeTask:(id<WKURLSchemeTask>)urlSchemeTask{ //empty } @end - (void)_setupWebViewPropertiesAndConstraints{ _webView.navigationDelegate = self; _webView.hidden = YES; [self.view addConstrainedSubview:_webView]; [self.view addConstraints:[_webView constraintsForFillingSuperview]]; self.container.showsLoadingIndicator = YES; } - (void)viewWillAppear:(BOOL)animated { [super viewWillAppear:animated]; WKWebViewConfiguration *docConfig = [WKWebViewConfiguration new]; WordDocWKSchemeHandler *schemeHanlder = [[WordDocWKSchemeHandler alloc] initWithData:_content.data mimeType:_content.contentType]; [docConfig setURLSchemeHandler:schemeHanlder forURLScheme:customScheme]; //Setup webview with custom config handler _webView = [[WKWebView alloc] initWithFrame:self.view.frame configuration:docConfig]; [self _setupWebViewPropertiesAndConstraints]; NSURL *customURL = [NSURL URLWithString:[NSString stringWithFormat:@"\%@:/",customScheme]]; [_webView loadRequest:[NSURLRequest requestWithURL:customURL]]; } The mimeType is correctly being resolved to "application/msword" but any time we try to load this the navigation fails: -(void)webView:(WKWebView *)webView didFailNavigation:(WKNavigation *)navigation withError:(NSError *)error { The error message here is OfficeImportErrorDomain Code=912. I've tried this on both a simulator and actual device on iOS 17 and 16 and this always fails. I've also tried turning the data into a base64 string and loading it that way and this also fails. Any advice here would be appreciated. It seems like this used to work at some point but no longer works.

I have an application where I am using AVCapturePhotoOutput to capture a still image. I do the usual stuff: Creating the session (new AVCaptureSession) Creating the capture output object Check that the session can add outputs Add the output if able, abort if not Start the session Check if the session can add an input Add the input if able, abort if not Set the sessionPreset to AVCaptureSession.Preset.photo Modify the format Turn on the torch Call capturePhoto on my AVCapturePhotoOutput object. I have a delegate designated with the following signature: func photoOutput(_ output: AVCapturePhotoOutput, didFinishProcessingPhoto photo: AVCapturePhoto, error: Error?) { if let data = photo.fileDataRepresentation(), let image = UIImage(data: data) { I have tried this with an iOS 15.1 and an iOS 14.4 device and it works perfectly fine. I'm able to go into that if let block and retrieve image data and do stuff with it. I just tried this today on an iOS 13.4.1 device and the photo object contains empty information as the debugDescription below shows. I've attempted to query the other functions of the AVCapturePhoto such as cgImageRepresentation(), pixelBuffer, previewCGImageRepresentation() and all of these have ended up being nil. I know the camera device isn't broken because I can start a session and the callback below provides a valid sampleBuffer on the same device. public func captureOutput(_ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection) { Any idea what could be going on here?

Good afternoon, We have been running into a problem after upgrading our server to Microsoft Server 2022 where our mobile app is failing client authentication via client certs. What we found was this was due to Microsoft Server 2022 using TLS 1.3 by default and something in our iOS is causing this to fail. Are there any new requirements for TLS 1.3 that would make this fail now? Previously, with TLS 1.2 it would work as follows: Our app makes a request to an endpoint that requires a client cert but it does not include a client cert in the request. The web server responds by saying that a client cert is required and then the client and server establish mutual TLS. We’ve overridden the urlSession callback for the challenge delegate like this:     switch challenge.protectionSpace.authenticationMethod {     case NSURLAuthenticationMethodClientCertificate:       // Use the client certificate and identity in the app keychain to validate the client against the server.       if let identity = Certificate.certificateSingleton.retrieveIdentity(), let certificate = Certificate.certificateSingleton.retrieveCertificate(identity: identity) {         let credentials = URLCredential(identity: identity, certificates: [certificate], persistence: URLCredential.Persistence.forSession)         challenge.sender?.use(credentials, for: challenge)         completionHandler(URLSession.AuthChallengeDisposition.useCredential, credentials)       }       else {         completionHandler(URLSession.AuthChallengeDisposition.cancelAuthenticationChallenge, nil)       }     case NSURLAuthenticationMethodServerTrust: fallthrough     default:       // Always accept the server credentials. We don't need to care about the authenticity of the server       completionHandler(URLSession.AuthChallengeDisposition.performDefaultHandling, nil)     }   } What we are seeing is previously we would first get a NSURLAuthenticationMethodServerTrust authentication method and fallthrough to the default handling, subsquently we would get another callback where the authentication method is NSURLAuthenticationMethodClientCertificate and everything works fine. We are now seeing two NSURLAuthenticationMethodServerTrust authentication methods back to back. Any ideas what is going on here? Thanks, Brad