审核被网络原因拒到不能自理了= =

今晚这个版本终于通过了！

今天这次提交做的事情是：
1. 把超时时间重新改小
2. 去掉了 IPv6 的 tunnel （反正加上也访问不到）
3. 录了小视频发 youtube 告诉他我在本地 IPv6 下测试过没问题
4. 告诉他我的服务器在中国，如果反应慢的话请再试试

另一个不同是今天的审核时间是 10 点前，之前都是夜里两三点

看了访问日志，这次的来访 IP 也不一样了。之前被拒的时候都是 17.200.11.44 ，今天是 65.199.22.137 。

还是吐槽大法保平安啊。

不知道申请的 Apple Developer Technical Support 还会不会联系我，回头再问问。

因为已经过审了所以 dts 只回复了一堆通用的步骤，附在这做参考吧

-------------------

Before discussing IPv6-specific issues, please be aware that not all App Review rejections that mention IPv6 are actually caused by IPv6 networking. The App Review rejection you ’ ve received indicates that:

* your app failed

* it was tested on an IPv6-only network

This does /not/ mean that the failure was specifically caused by that network. There are many other reasons why an app can work in your office but fail during App Review. At the end of this response you ’ ll find the standard answer we give to developers who are having problems reproducing an issue that occurs during App Review. You should work through these steps to make sure that you ’ ve not encountered some other issue that just happens to crop up during App Review.

If you ’ re convinced that this is an IPv6 issue, please read the “ Supporting IPv6-only Networks ” pinned post on DevForums.

<https://forums.developer.apple.com/message/136166#136166>;

This covers a number of points related to App Review ’ s IPv6 requirements. Specifically, read FAQ #6, which links to another document that has specific advice on how to debug IPv6 issues.

If this advice does not enable you to resolve the issue, please follow these steps:

1. On your Mac, set up the DNS64/NAT64 test network per the instructions referenced by FAQ #1 of the above-mentioned pinned post.

2. On your iOS device, join that test network.

3. On your Mac, start a packet trace. See QA1176 “ Getting a Packet Trace ” for information about how to take a packet trace.

<https://developer.apple.com/library/mac/#qa/qa1176/_index.html>;

IMPORTANT: Whatever packet trace tool you use, make sure it saves the packet trace in PCAP or PCAPNG format. The most common tools (`tcpdump` and Wireshark) do this by default.

4. On your iOS device, run your app and exercise its basic functionality, up to and including the point that App Review indicated that they had problems.

5. Stop the packet trace.

6. Use Apple Bug Reporter to create a bug report for investigating this issue.

<https://developer.apple.com/bug-reporting/>;

Consult the following checklist when filling out your bug report:

* When asked to select a product, choose Other > Other.

* Set the title of your bug report to “ App Review rejects App ID XXX for failing to work in the IPv6 network environment ”, replacing XXX with the App ID of your app.

* Indicate that you have tested your app in the DNS64/NAT64 test network.

* Attach the packet trace (from steps 3 through 5 above) to support that claim.

* If you have any thoughts as to which server is causing problems, put the DNS name of that server in your bug report.

For example, when App Review rejects an app they typically indicate the point at which it failed; if your app talks to some specific server at that point, mention it in your bug report.

7. Respond to this email with your bug number; DTS is tracking IPv6 issues and we ’ d like to associate your bug number with this email.

Finally, if you have code-level questions about IPv6 networking APIs on any of Apple ’ s platforms, please do get back in touch.

Different builds of the same code (for example, Debug vs. Release) can behave differently. When investigating issues reported only by App Review or customers, it ’ s important to ensure the build you are testing is the same build submitted to the App Store. Please read this entire email and the linked resources prior to following up with us: you ’ ll find helpful troubleshooting advice. If you do follow up with us, we will need certain information gathered during this troubleshooting phase.

Keep in mind, App Review is a “ real world ” environment. There may be varying networking situations, device configurations, usage patterns, and so on that affect your app. It ’ s safe to assume that issues reported by App Review have been confirmed by a normal user on normal device configurations, and reflect issues your customers would encounter, and are not unique to the App Review environment.

Important: DTS provides code-level support for iOS and OS X apps built using Xcode and Apple-provided frameworks and API. If your project is built with a third-party development environment or library, please contact its authors for support.

Steps to reproduce: If you are attempting to resolve an issue identified during app review and need additional information about how to reproduce the issue, use the Resolution Center or the Contact the App Review Team web form to follow up with App Review directly. DTS is unable to provide you steps to reproduce issues seen in App Review.

<https://developer.apple.com/appstore/contact/?topic=clarification>;

Test on the same version of iOS as the issue being reported: You will need to test your app on the same version of iOS that the issue was reported on; some issues only happen on specific versions of iOS.

Test the build you submit: If you are unable to reproduce an issue reported by App Review or customers, first verify you are testing the same build you submitted. Do this by building and testing your app using the process described in Technical Q&A QA1764 “ How to reproduce a crash or bug that only App Review or users are seeing ”.

You may also want to use TestFlight “ Internal Testers ” to test the version of the app being submitted.

<https://developer.apple.com/library/ios/qa/qa1764/_index.html>;

<https://developer.apple.com/testflight/>;

Debug deployed iOS apps: If you can reproduce the issue yourself after following the process in QA1764, you can diagnose the cause by using the techniques described in Technical Q&A QA1747 “ Debugging Deployed iOS Apps ” and others, like those described below.

<https://developer.apple.com/library/ios/qa/qa1747/_index.html>;

If you are unable to reproduce the reported issue after following QA1764, additional debugging will be needed. We ’ ve included a few helpful debugging techniques below; these should be considered starting points. During your debugging, you will need to consider all assumptions being made by your app and how those assumptions may be different in your customers ’ or App Review ’ s environment.

Test on multiple devices: Apps must be tested on actual devices, and on as many devices as possible, including Retina and non-Retina versions of iPad, iPhone, and iPod touch. Do not test only on the Simulator.
• Apps configured as “ Universal ” (in Deployment Info > Devices) must include complete iPad xibs or Storyboards with the proper and expected user interface.
• Apps that are iPhone only must still work on iPad devices in “ compatibility mode ” (also known as “ 2X mode ”).
• Issues reported on 64-bit devices (for example, iPhone 5s) need to be tested on 64-bit devices.

Symbolicate crash logs: Any crash logs you have will need to be symbolicated. Symbolicated crash logs replace memory addresses with human-readable function names and line numbers and can often point directly to the line of code that caused a crash. To learn how to symbolicate crash logs, see Technical Note TN2151 “ Understanding and Analyzing iOS Application Crash Reports ”.

<https://developer.apple.com/library/ios/technotes/tn2151/_index.html>;

Check differences in network connectivity: Use the “ Network Link Conditioner ” on your devices to test how your app behaves on a slow or unreliable internet connection. The behavior of the network that App Review or your customers use may be significantly different from the network you used during development. The Network Link Conditioner can be activated by navigating to Settings > Developer > Network Link Conditioner on your development device.

Test every language setting your app supports: Differences in localizations can cause different resources to be loaded, and for numbers and dates to be parsed or displayed differently. Remember to test each language setting on each device also.

Test data “ edge cases ”: Make sure you ’ ve tested app behavior when there are no Contacts, no photos in the Camera Roll, no Facebook friends, no Twitter followers and so on. Conversely, also check for a large number of contacts, photos and so on.

Use the Developer Forum: If you are unable to narrow the issue to a specific area of code or cannot reproduce the issue, you may want to consider posting your question to the Apple Developer Forums first, which is free and peer supported. Other developers may have seen similar issues, or have suggestions that can help you narrow the issue further.

<https://forums.developer.apple.com>;

Still unable to reproduce the reported issue? If you remain unable to reproduce the issue after following all of the previous suggestions, respond to this message and include the following:

1. The build UUID of the app you are testing. To find the build UUID of an IPA file, see Step 2 in Technical Q&A QA1765 “ How to Match a Crash Report to a Build ” (you do not need a crash log to follow this process).

<https://developer.apple.com/library/ios/qa/qa1765/_index.html#//apple_ref/doc/uid/DTS40012196-CH1-2__FIND_THE_BUILD_UUID_OF_AN_APP_BINARY>;

2. Fully symbolicated crash logs (if it ’ s a crashing issue). To learn how to symbolicate crash logs, see Technical Note TN2151 “ Understanding and Analyzing iOS Application Crash Reports ”.

<https://developer.apple.com/library/ios/technotes/tn2151/_index.html>;

3. Full details about the issue.

4. The troubleshooting and debugging steps you ’ ve taken to identify and resolve the issue.

Without these, we may not be able to provide further assistance.