未知且不可重现的崩溃导致 App Store 拒绝
多次提交申请后，我们不断收到以下回复：
感谢您将我的应用程序提交给 应用商店。我们已审核您的 申请并确定我们 无法发布您的 iPad 的此版本 向 App Store 申请，因为 我的应用程序在 iPad 上运行时崩溃 iPhone OS 3.2 和 Mac OS X 10.6.2。我的 应用程序在启动时崩溃。 不幸的是，崩溃日志没有 已生成。
但是，使用 AdHoc 权利放弃相同的构建并将该构建加载到设备上不会产生此类崩溃。经过多次尝试后，应用程序根本没有像审阅者所报告的那样崩溃。此外，审阅者不会提供 SpringBoard 可能生成的任何有用的日志记录，例如退出状态或事件（如果它在任何其他设备上正常工作的话）。代码行中没有调用显式退出或退出应用程序，但应用程序在启动时终止。
什么可能导致应用程序以这种方式终止？ 在什么条件下测试了在开发环境下可能找不到的应用程序？ 这是否是由于提交验证系统根本无法捕获的签名问题造成的？
提前致谢。
After submitting our application several times, we continue to receive the following response:
Thank you for submitting My App to the
App Store. We've reviewed your
application and determined that we
cannot post this version of your iPad
application to the App Store because
My App is crashing on iPad running
iPhone OS 3.2 and Mac OS X 10.6.2. My
App crashes upon launch.
Unfortunately, crash logs have not
been generated.
However, resigning the same build with the AdHoc entitlements and loading the build onto the device yields no such crash. After a number of attempts, the application simply does not crash as reported by the reviewer. Furthermore, the reviewer does not provide any useful logging that may have been generated by SpringBoard such as an exit status or event if it had worked properly for any other device. There are no calls to explicitly exit or quit the application in the code line and yet the application terminates on startup.
What might cause an application to terminate in such a manner?
Under what conditions is an application tested that might not be found under a development environment?
Could it be a result of a signing issue that the submission validation system is simply unable to catch?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
经过数周的斗争，该申请终于获得批准。关键：签署腐败。因此，为什么应用程序会启动（或者至少看起来是通过显示启动屏幕来启动）然后突然消失而没有崩溃日志。它未能通过 Springboard 的飞行前叹息检查。
一个值得记住的检查签名问题的好工具。它告诉我们应用程序是否具有有效的签名：
当我构建应用程序时，我会将其
cp到网络存储设备，我们的产品经理会将其下载并提交给 Apple。如果在 NAS 上解压，则代码签名有效。但如果您将压缩的应用程序从 NAS 上复制下来并进行验证，它就会失败。课程：使用新的 XCode 实用程序提交应用程序。
After fighting with this for weeks, the application has finally been approved. The key: signing corruption. Hence why the application would start (or at least appear to start by showing the splash screen) and then suddenly vanish without a crash log. It failed Springboard's preflight sighing check.
A good tool to keep in mind to check for signing issues. It tells if the application has a valid signing:
When I built the application, I would
cpit to a network storage device where our product manager would pull it down and submit it to Apple. If decompressed on the NAS, the code signing was valid. But if you coped the compressed application back off the NAS and validate it, it would fail.The lesson: make use of the new XCode utility to submit applications.
一些建议：
尝试使用静态分析器的泄漏工具来查看是否存在任何内存泄漏或您没有看到的问题。
您的应用程序使用网络服务吗？我曾经遇到过这种情况，因为苹果审查该应用程序的那天，网络服务出现了故障。这会导致崩溃。如果是这种情况，您可能需要添加一些内容来捕获这一点。
最后，在 Apple 发送给您的日志中，他们是否向您发送了 dsym 文件？如果他们这样做了，您可以从命令行运行atos，它会将地址转换为符号。这将向您显示崩溃的线程和符号。
A few suggestions:
Try to use the leaks tool of the static analyzer to see if there are any memory leaks or problems your not seeing.
Does your app use a web service? This happened to me one time because the day Apple was reviewing the app the web service went down. That cause a crash. If thats the case you would want to add something to catch that.
Finally, In the logs Apple sent you did they send you the dsym file? If they did you can run atos from the command line and it will convert the address to symbols. That will show you what thread and symbol it's crashing on.
我的方法是确保静态分析器中的编译绝对干净（这不是可选的，它将节省您的时间！）和构建本身。然后按照 CocoaDev 的 NSZombie 页面 中所述设置所有内容。然后确保您有一个运行 3.2 的 iPod（实际硬件，而不是模拟器）并测试、测试、测试。在网络可用和不可用的情况下执行此操作，在设备几乎已满且刚刚恢复的情况下执行此操作，以及您能想到的所有其他变体。在调试器处于活动状态并作为发布版本断开连接的情况下运行它。使用 Leaks、Instruments 和所有其他工具来查看并更好地了解正在发生的情况。如果你用尽了所有的可能性，你将不得不向苹果乞求更多细节，但我敢打赌你会发现一个问题——调试这样的问题时最重要的事情之一就是尝试忘记你认为你肯定知道的一切，并且从头开始。
My approach would be to make sure that the compilation is absolutely clean both in the static analyzer (this is NOT optional, it will save you time!) and for the build itself. Then set everything as described on CocoaDev' NSZombie page. Then make sure you have an iPod running 3.2 (actual hardware, not simulator) and test, test, test. Do it with network available and not available, with the device nearly full and freshly restored, every other variation you can think of. Run it with the debugger active and as a release build disconnected. Use Leaks, Instruments and all the other tools to peek in there and get a better feel for what is happening. If you exhaust every possibility you are going to have to beg for more detail from Apple but I bet you find a problem - one of the most important things in debugging an issue like this is to try to forget everything you think you know for sure and start at the beginning.
确保使用各种设置进行测试：禁用/启用 Wifi、禁用 3G、打开/关闭飞行模式、禁用位置服务等。
作为最后的手段，假设启动时执行的代码存在问题。删除一半的启动代码，将发布日期设置在遥远的将来（以防万一获得批准），然后重新提交并查看他们是否有相同的问题。如果不是，问题出在你删除的一半......这是一个二分搜索。
Be sure you test with a variety of settings: with Wifi disabled/enabled, with 3G disabled, Airplane mode on/off, location services disabled, etc.
As a last resort, assume there is a problem in your code that executes at startup. Remove half your startup code, set your release date in the far future (just in case it gets approved), then resubmit and see if they have the same problem. If not the problem is in the half you removed... it's a binary search.
我认为您有两个选择：更加努力地使用其他人提到的工具来重现缺陷，或者在现场捕获这些崩溃。
PLCrashReporter 将捕获未捕获的异常并存储所有相关信息。下次运行您的应用程序时，它可以发送崩溃报告，然后您可以将其符号化并查看堆栈跟踪。
I think you have two options: try harder to reproduce the defect using the tools other people are mentioning or to catch those crashes in the field.
PLCrashReporter will trap on an uncaught exception and store all relevant information. Next time your app is run, it can send the crash report that you can then symbolificate and view a stack trace of.
哎哟!这是一项艰难的任务。我以前也遇到过这种情况，但当我切换到不同的设备（iPhone 3G 与 3G 等）时，它似乎可以重现。但就你的情况而言，听起来你只使用 iPad，所以这可能没有帮助。我想，3G 和 Wifi 之间是有区别的，但如果这导致其中一个而不是另一个崩溃，我会感到非常惊讶。
如果您认为 Apple 没有尽自己的职责，您可以尝试的一件事是更改二进制名称并在另一个应用程序名称/记录下重新提交。看看你是否得到同样的回应。如果您遇到相同的审阅者，您可能会遇到这种情况，但我认为您很有可能会在新应用程序中遇到不同的审阅者。只需将您的应用程序发布日期设置为遥远的将来的某个时间，如果他们批准它，它就永远不会真正出现在应用程序商店中。如果新的应用程序因同样的原因被拒绝，你就需要做一些工作，但如果他们确实批准了它，那么我会与他们通电话并指出差异。
Ouch! That's a tough one. I've had this kind of thing happen before, but it seemed it was reproduce-able when I switched to a different device (iPhone 3G vs 3Gs, etc.). In your case though, it sounds like you're iPad only, so that might not help. There's a difference between 3G and Wifi, I suppose, but I would be really surprised if that was causing a crash on one and not the other.
One thing you could try if you think Apple's not doing their part is to change the binary name and re-submit it under another app name/record. See if you get the same response. If you get the same reviewer, you might, but I think there's a good chance you would get a different reviewer with a new app. Just set your app release date to some time in the distant future and it will never actually show up in the app store if they approve it. If the new app comes back rejected for the same reason, you've got work to do, but if they do in fact approve it, then I would get on the phone with them and point out the discrepancy.