Post

Replies

Boosts

Views

Activity

Different WebRTC ICE behavior between Xcode Release build and TestFlight on the same device
Hi everyone, I'm experiencing a very unusual difference in WebRTC ICE behavior between an application installed directly from Xcode and the exact same application distributed through TestFlight. Environment iOS application using Google's official WebRTC framework Same iPhone/iPad Same iOS version Same cellular network Same TURN server Xcode Run configuration: Release Archive configuration: Release Configuration The following configuration works perfectly when the application is installed directly from Xcode: config.iceTransportPolicy = .all config.iceServers = [ RTCIceServer( urlStrings: [ "turn:turn.example.com:3478?transport=udp" ], username: "username", credential: "<hidden>" ), RTCIceServer( urlStrings: [ "turn:turn.example.com:443?transport=tcp" ], username: "username", credential: "<hidden>" ), RTCIceServer( urlStrings: [ "turns:turn.example.com:5349?transport=tcp" ], username: "username", credential: "<hidden>" ), RTCIceServer( urlStrings: [ "stun:stun.l.google.com:19302" ] ) ] Calls connect quickly on both Wi-Fi and cellular networks. Problem After uploading exactly the same application to TestFlight, behavior changes significantly on cellular networks. ICE gathering appears to spend a long time generating host/server-reflexive candidates before a usable relay candidate becomes available. As a result, connection establishment becomes much slower than the same Release build installed directly from Xcode. Temporary workaround The only configuration that currently behaves reliably in TestFlight is forcing relay-only with a single TURN UDP server: config.iceTransportPolicy = .relay config.continualGatheringPolicy = .gatherContinually config.iceCandidatePoolSize = 2 config.iceServers = [ RTCIceServer( urlStrings: [ "turn:turn.example.com:3478?transport=udp" ], username: "username", credential: "" ) ] This connects quickly and reliably on both Wi-Fi and cellular networks. My question Has anyone experienced different ICE gathering or candidate selection behavior between: a Release build installed directly from Xcode the same Release build distributed through TestFlight on the same device and network? Are there any known differences in networking, ICE gathering, or runtime behavior that could explain this? I'd appreciate any suggestions or similar experiences. Thanks!
1
0
213
2w
Different WebRTC ICE behavior between Xcode Release build and TestFlight on the same device
Hi everyone, I'm experiencing a very unusual difference in WebRTC ICE behavior between an application installed directly from Xcode and the exact same application distributed through TestFlight. Environment iOS application using Google's official WebRTC framework Same iPhone/iPad Same iOS version Same cellular network Same TURN server Xcode Run configuration: Release Archive configuration: Release Configuration The following configuration works perfectly when the application is installed directly from Xcode: config.iceTransportPolicy = .all config.iceServers = [ RTCIceServer( urlStrings: [ "turn:turn.example.com:3478?transport=udp" ], username: "username", credential: "<hidden>" ), RTCIceServer( urlStrings: [ "turn:turn.example.com:443?transport=tcp" ], username: "username", credential: "<hidden>" ), RTCIceServer( urlStrings: [ "turns:turn.example.com:5349?transport=tcp" ], username: "username", credential: "<hidden>" ), RTCIceServer( urlStrings: [ "stun:stun.l.google.com:19302" ] ) ] Calls connect quickly on both Wi-Fi and cellular networks. Problem After uploading exactly the same application to TestFlight, behavior changes significantly on cellular networks. ICE gathering appears to spend a long time generating host/server-reflexive candidates before a usable relay candidate becomes available. As a result, connection establishment becomes much slower than the same Release build installed directly from Xcode. Temporary workaround The only configuration that currently behaves reliably in TestFlight is forcing relay-only with a single TURN UDP server: config.iceTransportPolicy = .relay config.continualGatheringPolicy = .gatherContinually config.iceCandidatePoolSize = 2 config.iceServers = [ RTCIceServer( urlStrings: [ "turn:turn.example.com:3478?transport=udp" ], username: "username", credential: "" ) ] This connects quickly and reliably on both Wi-Fi and cellular networks. My question Has anyone experienced different ICE gathering or candidate selection behavior between: a Release build installed directly from Xcode the same Release build distributed through TestFlight on the same device and network? Are there any known differences in networking, ICE gathering, or runtime behavior that could explain this? I'd appreciate any suggestions or similar experiences. Thanks!
Replies
1
Boosts
0
Views
213
Activity
2w