Voicebots can lift the load off human operators for any business. In these six sectors, they are a must if you want to trump your competition.
Since the IPv6 adoption in the world is already over 20% (according to the Google IPv6 monitor), Voximplant has implemented the support of IPv6 for p2p calls. The implementation affects all our SDKs (Web / Android / iOS / React Native / Unity). Although it’s a great improvement of functionality, it has some nuances. Further, we cover known issues related to the IPv6 usage in iOS applications.
IPv6-only NAT64 environment
Currently, we support only a peer-to-peer communication mode, that is why this configuration doesn’t allow to establish a call through our servers. We are working on complete IPv6 support, i.e., server-based calls.
Another issue is about rejecting iOS applications on Apple Store reviews because of “Connection error” referred to the App Completeness item on App Store Review Guidelines. There is an official guide on how to set up the environment using Apple’s hardware, but it doesn’t always help with the review; see this case for details. Please remember that according to the guide, you shouldn't use IPv4 Address Literals. Sometimes a simple resubmit can solve the problem, and sometimes it doesn’t – you see, due to many points of failure (software configuration, network/hardware settings, etc.) developers, unfortunately, don’t have unambiguous, clear way to address issues.
Last, but not least nuance: the enabled connectivity check option for establishing a connection to the Voximplant cloud (i.e., in the connectWithConnectivityCheck:gateways: method) doesn’t work correctly in IPv6-only networks; keep in mind that fact.
How come Apple tests failure whereas developers’ tests are successful?
Despite Apple published recommendations on supporting IPv6 DNS64/NAT64 networks, nobody knows, what is the exact inner configuration they use. There are only assumptions, check this one, for example: https://packetpushers.net/nat64-setup-using-tayga/. Our team built and tested configuration based on the guide, but still, there is no certainty that Apple uses the same setup.
We don’t recommend to make UI in your iOS Apps dependent on the iOS SDK as it could lead to undesirable user experience and even rejection on the App Store review.
For example, if UI can start to render only after our SDK is connected to the cloud, it can cause an infinite loading screen in case of SDK’s connectivity issues. The App Store review procedure is sensitive for such cases, that is why an app with SDK-dependent UI can possibly be rejected. You can implement a cloud connection as a background execution which doesn’t affect the UI; it’s a decent, safe practice.
Forewarned is forearmed
Hope the article has benefited in terms of dev hints&tips. We understand that you can find the current situation about IPv6 quite confusing (as we are). However, instead of moaning and swearing it’s rather better to find solutions as real pros usually do :) Stay tuned and feel free to share your experience if you know other IPv6 details related to the iOS development.