SSL issues when using test flight

Question

Created Jul ’22

Replies 6

Boosts 0

Views 1.5k

Participants 4

I'm having an issue where the network connection my app creates is behaving differently between debug and when installed via test flight. In debug everything behaves perfectly, but when uploading to App Store connect and installing via test flight I get the following in the console output of my test server app:

[boringssl] boringssl_session_set_peer_verification_state_from_session(324) [C68:1][0x7fa5e9737920] Unable to extract cached certificates from the SSL_SESSION object

The data sent in appears to have arrived correctly, but the client then enters an error state.

How is the App Store version installed through test flight behaving differently to the exact same code run on a device by plugging into xcode and hitting run? This is making it impossible to properly debug the issue as I can't replicate it on a device when debugging.

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’22

How is the App Store version installed through test flight behaving differently to the exact same code run on a device by plugging into xcode and hitting run?

Are you sure it’s “the exact same code”? Most probably like this are caused by differences between Debug and Release builds, so the same source code but different machine code. Try this:

In Xcode, do a Build > Archive.
Upload that archive to TestFlight and confirm that the problem happens there.
Now select the same archive in the Xcode organiser, click Distribute App, and follow the Development workflow.

This exports a Release build with Development signing. When you install that on a device, does it fail in the same way as the TestFlight build?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

OliverT OP

Jul ’22

Thanks for the input. I actually managed to resolve the issue by archiving a debug build and uploading that. Obviously not the ideal solution though.

This means that somehow the app behaves differently between release and debug builds despite the code being the same. The project doesn't contain any code at all specific to either build so it is either build settings related in some way or the compiler is performing some optimisation which is making a mess of things.

The source code involved isn't complicated at all, all it does is use CFStreamCreatePairWithSocketToHost to open a tcp connection then enable ssl by calling setProperty(StreamSocketSecurityLevel.negotiatedSSL, forKey: Stream.PropertyKey.socketSecurityLevelKey) on the streams. I also tried an experiment using the newer NWConnection and got identical behaviour.

0

Answer 3

DTS Engineer OP

Apple

Aug ’22

So, did you manage to create a Release build with Development signing, per my previous post? Did that shows the problem or not?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

rad_val OP

Mar ’23

@OliverT I'm facing the exact same issue, except in my case everything continues to work fine after the error is logged. Did you manage to find the underlying cause?

0

Answer 5

DTS Engineer OP

Apple

Mar ’23

I recently posted Isolating Code Signing Problems from Build Problems, which expands on the suggestion I raised above. I recommend that you run through this process to determine whether this is a code signing problem or a build configuration problem.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 6

Asleepace OP

May ’24

I'm noticing a similar issue with simulator vs. physical device, the TCP connection works fine on the simulator, but runs into issues with a physical device.

What's strange is that on the computer running the simulator, I seem to be able access the local TCP server from outside the simulator.

Maybe something to do with bounjour or dns name collision?

0