UnityWebRequests on iOS sometimes get stuck indefinitely even with timeout set

been a while but I'm pretty sure the invalidation callback never once fired, going to try again just to make sure.

 

Ok, just ran our test case again to make sure, like so:

Code (CSharp):

1. @implementation UnityWebRequestDelegate
2. - (void)URLSession:(NSURLSession *)session didBecomeInvalidWithError:(NSError *)error
3. {
4.     NSLog(@"NETWORK ERROR: %@", error);
5. }
6. - (void)URLSession:(NSURLSession *)session dataTask:(NSURLSessionDataTask *)dataTask didReceiveResponse:(nonnull NSURLResponse *)response completionHandler:(nonnull void (^)(NSURLSessionResponseDisposition))completionHandler
7. {
8.     NSLog(@"NETWORK OK: %@", response.URL);
9.     [self handleResponse: response task: dataTask];
10.     completionHandler(NSURLSessionResponseAllow);
11. }
12.  

I get a network ok for the first 20 or so requests, then it just stops working. I never see NETWORK ERROR in the logs, so didBecomeInvalidWithError is not called

 

Just wanted to let you know that the bug has been added to the Issue Tracker. You can view it here:
https://issuetracker.unity3d.com/is...nt-work-when-using-a-14-dot-2-plus-ios-device

 

For everyone having this issue, I've replaced all my UnityWebRequest call by HttpClient call and it works. It was a lot of work and I had to learn a lot about HttpClient, but since there is no vision on the correction of this bug, I had to do it.

And, well, HttpClient is really good. I don't know what are the pros of using UnityWebRequest since HttpClient can do the same if not better ?

 

Thanks for the information.
Is this just a temporary workaround, or is this the solution which will be integrated in a future release of Unity?

//EDIT: I've tried this and it SEEMS TO FIX the problem! Thanks! Hope to see the fix in an official release soon, so we're able to use cloud builds again.

 

We use some Unity specific functionality like assetbundle caching, switching to httpclient isnt viable.

 

I've changed all plugins code with HttpClient :-( ... this is an time expensive workaround... not a final solution :-(

 

seems to work for me as well, thank you! added it in the method UnityCreateWebRequestBackend:

Code (CSharp):

1. webOperationQueue = [[NSOperationQueue alloc] init];
2. webOperationQueue.name = @"com.unity3d.WebOperationQueue";
3. webOperationQueue.qualityOfService = NSQualityOfServiceUserInteractive;

looking forward to see this in an official bugfix update

 

Looking at the documentation for qualityOfService property, this doesn't seem to be a correct fix, rather a workaround.

I can be mistaken because I can't fully understand why the problem happens in the first place, but setting a higher priority to a queue doesn't seem like a "correct" fix to me, rather it's hiding the underlying problem. Again, I can be wrong.

 

So what is causing it? Why does a functionality unrelated to networking stop it from working?

 

We are currently testing more, however it seems like this fixed the issue for our team as well.

 

Did anyone try this with iOS 14.2.1 (exclusive to iPhone 12 and iPhone 12 Pro)? Seems like one of our customers still has the problem

//EDIT: not relevant, sorry, problem was somewhere else

 

@re-cheid We updated everything to 14.3 (XR, MX Max, iPhone 7) and it works fine. Can the customer update their OS and see if there is still an issue?

 

False alarm! it was a different issue with his environment.

 

Just FYI I used HTTPClient from ClaytonIndustry (as advised before in this thread) to fix my http request issue on iPhone (iOS 14.3), and it does the job... but I still have the issue on iPad OS 14.3 (iPad Pro) (InvalidServer error after sending the request : message "unknown" is returned ). Any clue why this fails on iPad OS ?

EDIT : I forgot to say I upgraded my project to Unity 2020.2

 

I meant our devices were all updated to 14.3 and using the webOperationQueue.qualityOfService = NSQualityOfServiceUserInteractive fix. We did not test with 14.2 or 14.2.1 because that would require us to downgrade the device OS which is more work than it is worth.