为 App Store 构建最终版本之前的预发布清单
好奇人们在进行最终构建并提交到 App Store 之前学到了哪些实践？除了从调试切换到发布&注释掉对 NSLog 的调用，我们还应该注意哪些其他基本和/或不那么基本的事情？
Curious what practices people have learned before making their final build and submitting to the App Store? Aside from switching from Debug to Release & commenting out calls to NSLog what other basic and/or not so basic things should we be watching out for?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是一个很好的问题，我想重申一些答案并添加一些我自己的答案。我已经在社区维基上做出了这个答案，请随意添加。
从您的设备中删除该应用，关闭 WiFi，关闭蜂窝数据，然后安装并测试应用。它是否可以正常工作（在没有互联网的情况下也能正常工作）？它是否至少告诉用户需要网络连接（如果需要）或者是否会崩溃？
如果您使用 CLLocationManager：删除应用程序，全新安装并运行，但不允许应用程序具有位置数据。应用程序运行良好还是崩溃？它是否至少告诉用户如果没有位置数据它就无法运行（如果这是一个要求）？它可以在仅使用 WiFi 进行所有地理位置定位的 iPod Touch 上运行吗？
在模拟器中运行应用程序，并对每个视图控制器执行以下步骤： (a) 从 iPhone Simulator 菜单中选择“硬件”--> “模拟内存警告”，(b) 现在在您的应用程序中导航到其他视图控制器并查看是否一切正常，(c) 对另一个视图控制器重复测试。
如果您支持较旧的固件（即：iOS 3.1.3），请在运行 3.1.3 的设备上安装您的应用并在那里进行测试（如果您没有，请使用 3.2 模拟器）。
在通话时或个人热点处于活动状态时启动您的应用。所有屏幕布局是否正确（状态栏高为 40 像素，而不是 20）？视图的底部 20 像素是否被推离屏幕，或者是否正确调整了大小？
在您的应用中接听电话时，它是否会退出活动并正常恢复？在通话过程中，您的应用程序中的声音是否会停止播放？
在播放音乐时启动您的应用，音乐会继续播放吗？您的声音是否正确混合或适当淡化音乐？
在内存有限的较慢设备上测试性能，例如：iPhone 3G（128MB RAM， 412Mhz CPU）或 iPod Touch（第一代或第二代）。
运行 Clang 静态分析器并修复（或至少理解）每个警告。
确保环境变量中的 NSZombiesEnabled 为 NO（警告：不确定这是否仍然是问题）
This is a good question and I'd like to restate some of the answers and add a few of my own. I've made this answer Community Wiki, feel free to add to it.
Delete the app from your device, turn off WiFi, off cellular data, now install and test app. Does it work properly (as much as it can without Internet)? Does it at least tell the user that a network connection is required (if it is) or does it crash?
If you use CLLocationManager: Delete the app, fresh install and run, but do not allow app to have Location Data. Does the app behave well or does it crash? Does it at least tell the user that it can't run without location data (if that is a requirement)? Does it work on an iPod Touch that does all geo location using WiFi only?
Run the app in the simulator and for each view controller do the following steps: (a) From the iPhone Simulator menu select "Hardware" --> "Simulate Memory Warning", (b) now navigate around your app to other view controllers and see if everything is working, (c) repeat test for another view controller.
If you support older firmware (ie: iOS 3.1.3), install your app on a device running 3.1.3 and test it there (if you don't have one, use the 3.2 simulator).
Start your app while on a phone call or when Personal Hotspot is active. Are all the screen layouts correct (the status bar is 40px high instead of 20)? Did the bottom 20px of the view get pushed off the screen or did it resize correctly?
Accept a phone call while in your app, does it resign active and resume properly? Do sounds from your app stop playing while in the phone call?
Start your app while playing music, does the music continue to play? Do your sounds mix properly or fade the music appropriately?
Test performance on a slower devices with limited RAM such as: iPhone 3G (128MB RAM, 412Mhz CPU) or iPod Touch (1st or 2nd gen).
Run the Clang static analyzer and fix (or at least understand) every warning.
Make sure NSZombiesEnabled is NO in the environment variables (caution: not sure if this is still a problem)
有几点：
我实际上建议不要创建 Apple 指定的名为“Distribution”的构建配置，因为我经常为 Beta 测试人员创建临时构建。我创建了两种构建配置，一种称为 Ad Hoc，一种称为 AppStore，所以我不会感到困惑。两者之间的唯一区别是 Ad Hoc 构建的 Entitlements.plist 文件的存在。这样我就可以尽可能仔细地测试我将提交给 Apple 的内容。
大多数开发人员都是乐观主义者。这就是为什么我们周末工作来创建一个我们知道会让我们成为百万富翁的应用程序。不过，在提交之前，请保持悲观态度。想象一下所有可能出错的地方，并仔细检查。
不要假设任何事情。不要以为您对应用程序所做的微小更改不会影响其他任何内容。墨菲定律指出，这个微小的变化就会导致你的应用程序在所有 iPod Touch 或其他设备上崩溃。在最终代码编辑和应用商店提交之间进行彻底的测试、测试、测试。如果您必须做出微小的改变，请重复直到完美为止。
请记住，如果 99.9% 的用户不会崩溃，那么每 1,000 次下载中就有 1 次会导致 1 星严厉评价。
我在开发过程中使用 Clang 静态分析器、泄漏和对象分配，但在提交之前我会额外运行这些工具以防万一。
如果您没有旧设备，请购买一台，因为 3GS 性能明显更好，并且您可能会错过一些重要的性能问题。
当网络或位置适用时，使用以下配置测试您的应用程序：
A few things:
I actually recommend not creating a build configuration called "Distribution" as Apple specifies, because I often am creating ad hoc builds for beta testers. I create two build configurations, one called Ad Hoc and one called AppStore, so I'm not confused. The only difference between the two is the presence of the Entitlements.plist file for the Ad Hoc build. This way I can test as closely as possible what I will be submitting to Apple.
Most developers are optimists. That's why we are working weekends to create an app that we just know is going to make us a millionaire. Before submitting though, be a pessimist. Imagine everything that can possibly go wrong, and double check it.
Don't assume anything. Don't assume that that tiny little change you made to the app won't affect anything else. Murphy's Law says that that tiny change will cause your app to crash on all iPod Touches or something. Test, test, test thoroughly between the final code edit and Appstore submission. If you have to make a tiny change, then repeat until it's perfect.
Remember that if the app doesn't crash for 99.9% of your users, then 1 out of every 1,000 downloads will result in a 1-star scathing review.
I use Clang static analyzer, Leaks and Object Allocations during development, but I do an extra run of these tools before submission just in case.
If you don't have an older device, get one, because the 3GS performance is significantly better and you may miss some important performance issues.
Test your app with the following configurations when network or location are applicable:
我没有切换到“发布”，而是切换到“分发”。这是 Release 的副本，但这就是一些 Apple 文档和 教我的方式iPhone开发者提示。
要点：
在最终构建之后，但在您急于压缩应用程序之前，请使用 Finder 的“显示包内容”打开捆绑包。由于 MacOS 中的一些错误，在 Snow Leopard 之前的版本中困扰着我（它可能仍然存在），如果你压缩得太快（使用 Finder 的压缩或存档菜单项），一些资源还没有被压缩。被刷新到文件中。当您执行“显示包内容”时，内容会更新。您会注意到此问题的方式是，压缩应用程序的大小将在预期大小的五分之一到十分之一或更小之间。您可能会想，“嘿，zip 实用程序确实在压缩方面做得很好”，但事实并非如此。此问题会在此时发生，而不是在测试期间发生，主要是因为您正在进行“全部清理”构建，并且应用程序包的所有资源和内容一开始都是空的，然后由 Xcode 填充。由于某种原因，即使 Xcode 完成创建文件后，如果您压缩，内容实际上仍然不存在，但如果您查看它们，内容就会存在（有点相反的海森堡）。提防。
我花费大量时间的另一个领域是在我将所有最新更改提交到 SVN、创建新分支并标记文件之后，对源文件进行良好的备份。我还喜欢让我的版本号与我的 SVN 构建/提交号相匹配，这样我总是知道哪个 SVN 版本与我的版本相匹配。我的 info.plist 中有这两个版本号，应用程序用户在点击 i 获取信息时可以调出这两个版本号。例如，当前的 info.pist 包括：
对于如何使用 CFBundleVersion 有不同的想法。这是我的方式。同样有用的是命令行实用程序，agvtool。
一旦构建了应用程序，在压缩之后，您实际上并没有对压缩版本进行任何更改，请检查应用程序文件并确保它是使用正确的分发证书而不是您的临时证书进行签名的。学习使用命令行实用程序，codesign，对于这种检查和调试很有帮助。通过首先制作压缩副本，您可以确保您不会以任何方式更改 Xcode 提供给您的最终副本，并且如果一切正常，您将上传到 itunesconnect。
其他需要记住的事情是应用程序图标、iTunes 商店所需的各种其他图标和图形、info.plist，以及当应用程序上传失败并出现神秘错误消息时，通常与您正在构建的压缩文件中缺少其中之一（属于应用程序包中的那些部分）。
Instead of switching to Release, I switch to "Distribution". It's a copy of Release, but that's is how I got taught by some Apple doc and iPhoneDeveloperTips.
Important points:
After the final build, but before you rush off to zip up your app, open the bundle using the Finder's Show Package Contents. Due to some bug in the MacOS, which bit me in versions prior to Snow Leopard (and it might still be there), if you zip up too fast (using the Finder's Compress or Archive menu item), some of the resources have yet to be flushed out into the file. When you do a Show Package Contents, the contents get updated. The way you would notice this problem is that the size of your compressed app would be between a fifth to a tenth or less of the expected size. You might think to yourself, "hey, that zip utility really does a great job of compressing", but that's not the case. This problem would occur at this point instead of during testing mainly because you are doing a "clean all" build and all the resources and contents of the app bundle are starting out empty and then being filled by Xcode. And for some reason, even after Xcode is done creating the file, the contents are still not actually there, if you compress, but would be there if you looked at them (sort of a reverse Heisenberg). Beware.
Another area I spend a lot of time on is to make a nice backup of the sources, after I have committed all the latest changes to SVN, made a new branch, and tagged the file. I also like to have my version number match my SVN build/commit number so I always know which SVN version matches my release. I have those two version numbers in my info.plist and can be pulled up by the app user when they hit i for info. For example, a current info.pist includes:
There are different thoughts on how to use the CFBundleVersion. This is my way. Also useful is the command line utility, agvtool.
Once the app is built, after compressing so you're not actually making any changes to the compressed version, go check the app file and make sure it is signed with the right distribution cert and not your adhoc one. Learning to use the command line utility, codesign, is helpful for this kind of checking and debugging. By making the compressed copy first, you ensure that you're not in any way going to change the final copy that Xcode has handed you and that you will upload to itunesconnect, if all looks well.
Other things to remember are the app icon, the various other icons and graphics you need for the iTunes store, the info.plist, and the fact that when the uploading of the app fails with a cryptic error message, it usually has to do with one of these pieces being missing from the compressed file you are building (those pieces that belong in the app bundle).
查看此检查列表文档 @ Github
https://github.com/bapu/AppReleaseCheckList
Look into this check list document @ Github
https://github.com/bapu/AppReleaseCheckList