Xcode 9 iOS 11 BoringSSL SSL_ERROR_ZERO_RETURN Xcode 9 iOS 11 BoringSSL SSL_ERROR_ZERO_RETURN xcode xcode

Xcode 9 iOS 11 BoringSSL SSL_ERROR_ZERO_RETURN


Is there a way the I can debug why the message comes up?

Yes, there is, and I'm a bit surprised it hadn't been mentioned yet.

CFNetwork handles the core of Foundation’s networking classes — It also has the (often overlooked) capability of detailed logging via the CFNETWORK_DIAGNOSTICS environment variable.

Programmatically enabling CFNetwork diagnostic logging:

setenv("CFNETWORK_DIAGNOSTICS", "3", 1);

It should be set to an integer value from 0 to 3, where 0 is off and higher numbers give progressively more logging. During normal development you can set this environment variable via Xcode’s scheme editor. When the app is run from Xcode, the CFNetwork log entries will appear in the debug console area (if not visible, choose View > Debug Area > Show Debug Area).

The environment variable should be placed right at the beginning of the app’s launch sequence. Normally putting this at the start of main is sufficient, but if you have C++ static initialisers that use CFNetwork you’ll have to put it before those.

Note: In Swift this code would go in main.swift. By default Swift apps don’t have a main.swift; “The Swift Programming Language” explains how to add one.
*Also note, in Swift remove the semi-colon at the end of the setenv.

Setting the environment variable above should definitely help in determining where the issue is, or at the very least give you a starting point to begin diagnosing a somewhat vague error message.

CFNetwork Diagnostic Logging


I managed to fix the issue by adding the "App Transport Security Settings" key to the info.plist. Make sure that "Allow Arbitrary Loads" is set to "Yes".


For those of you for whom the above methods did not work, this is what the problem was in my case:

I was sending a GET request with a JSON request body using Alamofire. I changed it to a GET request that contains the parameters as query parameters in the URL instead (along the lines of GET https://your-api.com/v1/request?param=value). Then it worked flawlessly.