iOS issue Ipv6

[Marcondes__Marcos]

What is wrong ?

iOS rejection explaination

As we discussed, your app has been rejected for the App Store Review Guideline detailed below.
 

Performance - 2.1

We discovered one or more bugs in your app when reviewed on iPad and iPhone running iOS 9.3.3 on Wi-Fi connected to an IPv6 network.

Specifically, the app still produces no action when we tap on any button. App launches and appears frozen

Next Steps

Please run your app on a device while connected to an IPv6 network (all apps must support IPv6) to identify the issue(s), then revise and resubmit your app for review.

If we misunderstood the intended behavior of your app, please reply to this message in Resolution Center to provide information on how these features were intended to work.

For new apps, uninstall all previous versions of your app from a device, then install and follow the steps to reproduce the issue(s). For updates, install the new version as an update to the previous version, then follow the steps to reproduce the issue(s).

Resources

For information about supporting IPv6 Networks, please refer to Supporting IPv6 DNS64/NAT64 Networks and About Networking

If you have difficulty reproducing a reported issue, please try testing the workflow described in Technical Q&A QA1764: How to reproduce bugs reported against App Store submissions.

If you have code-level questions after utilizing the above resources, you may wish to consult with Apple Developer Technical Support. When the DTS engineer follows up with you, please be ready to provide:
- complete details of your rejection issue(s)
- screenshots
- steps to reproduce the issue(s)
- symbolicated crash logs - if your issue results in a crash log

We hope you will consider making the necessary changes to be in compliance with the App Store Review Guidelines and will resubmit your revised binary.

Please feel free to contact me at +1-669-227-1522 between 6AM-4PM Pacific Daylight Time if you need further clarification.

Best regards,
Jessica
App Store Review

[PaulF_IntelCorp]

Marcos -- one of your apps appears to just be a simple wrapper around a web site, which can generate red flags for apps. Both apps have direct references to http: addresses. I suspect these direct references to http: URLs is the source of the problem (in the case of your App Designer application, you left a reference to the Intel Test tab's weinre server, which is not something you should include in a production app).

I am only speculating, as I do not know for sure what might be causing this problem, but reading this section:

Common Barriers to Supporting IPv6

Several situations can prevent an app from supporting IPv6. The sections that follow describe how to resolve these problems.

• 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. See Use High-Level Networking Frameworks and Don’t Use IP Address Literals.

• IP address literals embedded in configuration files. Configuration files often include IP address literals. See Don’t Use IP Address Literals.

• 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. See Connect Without Preflight.

• Using low-level 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 they only support IPv4—for example, resolving hostnames for the AF_INET address family, rather than the AF_UNSPEC address family. See Use High-Level Networking Frameworks.

• 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 bits or smaller. See Use Appropriately Sized Storage Containers.

I believe those direct references in your index.html file is triggering either the second or third bullet.

A simple test of my theory would be to remove the reference to the weinre test site in your second app and resubmit to see if that clears up the issue. If that is the reason for the problem, then you will probably have to figure out a different way to write the first app.

[Marcondes__Marcos]

Paul,

Can you explain or send the code you are saying about "you left a reference to the Intel Test tab's weinre server" ... what is a test tab weinre server ????

thanks in advance
Marcos

[PaulF_IntelCorp]

Marcos -- near the very end of your "CarolZerbini" app's index.html file includes this script reference:

<script src="http://debug-software.intel.com/target/target-script-min.js#8rP40g69lYBB34jpAu-DJjQQv0trDAjiFNi6qNTJ-Vk"></script>

This is a "weinre connection script" that is only something that you use to connect to the weinre server that we maintain for use with the Test tab. It should not be in your app because it will impact your app's performance and it represents a potential security risk to your app. When your app is started it will attempt to connect to that server, which will slow down the initial start of your app and also requires that the device your app is running on has a good network connection. It's also using mobile data, if your user is connected to the Internet via their mobile data connection.