[TIMOB-19149] iOS9: Adopt IPv6 requirement for App Store Submissions
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | Critical |
Status | Closed |
Resolution | Won't Do |
Resolution Date | 2015-08-24T03:15:06.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | iOS |
Labels | n/a |
Reporter | Ingo Muschenetz |
Assignee | Chee Kiat Ng |
Created | 2015-07-02T20:24:28.000+0000 |
Updated | 2015-08-24T03:15:10.000+0000 |
Description
“Because IPv6 support is so critical to ensuring your applications work across the world for every customer, we are making it an AppStore submission requirement, starting with iOS 9.”
http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv6-support-for-all-ios-9-apps/
Quote from link
{quote} Three steps all developers can take to make sure their applications work over IPv6 networks: - Use the networking frameworks (for example, “NSURLSession”) - Avoid use of IPv4-specific APIs - Avoid hard-coded IP addresses Essentially, if app developers are using the higher level APIs and frameworks and aren’t hacking around at the IP layer, their apps should probably “just work” on top of either IPv4 or IPv6. This is an important point – most iOS developers probably do not need to do anything on the development side. Assuming they have followed best practices in coding and are using the iOS networking frameworks, they should be all set. Some developers, though, may be using lower level APIs that may involve direct usage of IPv4 addresses. Some developers may also be using the user’s IPv4 address as an identifier or for logging or configuration purposes. But again, most iOS developers probably don’t need to change their code to support IPv6. {quote} Apple Guide: [here](https://developer.apple.com/library/prerelease/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW1)Attachments
File | Date | Size |
---|---|---|
Screen Shot 2015-07-03 at 11.27.23 am.png | 2015-07-03T03:38:30.000+0000 | 214872 |
Screen Shot 2015-07-03 at 11.28.08 am.png | 2015-07-03T03:38:31.000+0000 | 194223 |
Screen Shot 2015-07-03 at 11.29.59 am.png | 2015-07-03T03:38:30.000+0000 | 85342 |
Screen Shot 2015-07-03 at 11.31.52 am.png | 2015-07-03T03:38:30.000+0000 | 59803 |
To test:
Set up a NAT64 + DNS64 hotspot on El Capitan as instructed on WWDC link. And using any built titanium app, call all methods that access the net to test for this IPv6 Requirement.Possible breaking points in Titanium:
- APSHTTPClient - AsyncSocket.m, AsyncUDPSocket.m - TiNetworkTCPSocketProxy.m - Platform.Module.m - Reachability.mNote
Primarily, app submitted for App Store has to address these: 1. IP address literals embedded in protocols. Many communications protocols, such as Session Initiation Protocol (SIP), File Transfer Protocol (FTP), WebSockets, and Peer-to-Peer Protocol (P2PP), include IP address literals in protocol messages. For example, the FTP parameter commands DATA PORT and PASSIVE exchange information that includes IP address literals. Similarly, IP address literals may appear in the values of SIP header fields, such as To, From, Contact, Record-Route, and Via. 2. IP address literals embedded in configuration files. Configuration files often include IP address literals. 3. Network preflighting. Many apps attempt to proactively check for an Internet connection or an active Wi-Fi connection by passing IP address literals to network reachability APIs. 4. Using raw networking APIs. Some apps work directly with sockets and other raw network APIs such as gethostbyname, gethostbyname2, and inet_aton. These APIs are prone to misuse or only support IPv4—for example, resolving hostnames for the AF_INET address family, rather than the AF_UNSPEC address family. 5. Using small address family storage containers. Some apps and networking libraries use address storage containers—such as uint32_t, in_addr, and sockaddr_in—that are 32-bit in size or smaller.How Titanium is affected
1. no IP address literals embedded in SDK. Should write in documents to inform Titanium developers to avoid using IP address literals. 2. Similarly, none embedded in SDK. 3. In this case, possible breaking spot is in Reachability.m., the method *reachabilityWithAddress*. Yet to find exposed titanium methods that access this method. Quoting Apple Reference: {quote} avoid calling the SCNetworkReachabilityCreateWithAddress method. Call the SCNetworkReachabilityCreateWithName method and pass it a hostname instead.{quote} 4. The SDK has these api exposed for titanium developers, under Ti.Network.Socket, which supports both ipv4 and ipv6. Should document here that they need to use ipv6 when calling these methods for iOS9. However, if Apple is really strict to reject app submissions because we have these in code, even if we don't call them, then we have to think of some solution. This should be unlikely. 5. Titanium SDK has ipv6 storages.Conclusion
Other than spending more time to research on (3.), we probably have nothing much to change but advice our titanium developers to avoid using ipv4 or IP address literals. But we have to be prepared for related issues to this when iOS9 is officially out and people start submitting titanium apps in the App Store and getting failed reviews because of this.Closing in favor of the doc ticket