【问题标题】:Pre-release checklist before building final version for App Store为 App Store 构建最终版本之前的预发布清单
【发布时间】:2009-09-26 00:08:35
【问题描述】:

想知道人们在进行最终构建并提交到 App Store 之前学习了哪些实践吗?除了从 Debug 切换到 Release 以及注释掉对 NSLog 的调用之外,我们还应该注意哪些其他基本和/或不太基本的事情?

【问题讨论】:

    标签: iphone cocoa-touch app-store


    【解决方案1】:

    这是一个很好的问题,我想重申一些答案并添加一些我自己的答案。我已经制作了这个答案社区 Wiki,请随时添加。

    1. 从您的设备中删除应用程序,关闭 WiFi,关闭蜂窝数据,现在安装并测试应用程序。它是否正常工作(尽可能在没有互联网的情况下工作)?它至少会告诉用户需要网络连接(如果需要)还是会崩溃?

    2. 如果您使用 CLLocationManager:删除应用程序,重新安装并运行,但不允许应用程序具有位置数据。应用程序运行良好还是崩溃?它是否至少告诉用户它不能在没有位置数据的情况下运行(如果这是必需的)?它是否适用于仅使用 WiFi 进行所有地理位置的 iPod Touch?

    3. 在模拟器中运行应用程序,并为每个视图控制器执行以下步骤:(a) 从 iPhone 模拟器菜单中选择“硬件”-->“模拟内存警告”,(b) 现在浏览您的应用到其他视图控制器,看看是否一切正常,(c) 对另一个视图控制器重复测试。

    4. 如果您支持较旧的固件(即:iOS 3.1.3),请将您的应用安装在运行 3.1.3 的设备上并在那里进行测试(如果您没有,请使用 3.2 模拟器)。

    5. 在通话或个人热点处于活动状态时启动您的应用程序。所有的屏幕布局是否正确(状态栏是 40px 高而不是 20px)?视图的底部 20px 是否被推离屏幕或是否正确调整大小?

    6. 在您的应用程序中接听电话,它会主动退出并正常恢复吗?通话时应用中的声音是否停止播放?

    7. 在播放音乐时启动您的应用程序,音乐会继续播放吗?您的声音是否正确混合或适当淡化音乐?

    8. 在速度较慢且 RAM 有限的 devices 上测试性能,例如:iPhone 3G(128MB RAM,412Mhz CPU)或 iPod Touch(第一代或第二代)。

    9. 运行 Clang 静态分析器并修复(或至少理解)每个警告。

    10. 确保环境变量中的 NSZombiesEnabled 为 NO(注意:不确定这是否仍然存在问题)

    【讨论】:

      【解决方案2】:

      一些事情:

      我实际上建议不要像 Apple 指定的那样创建名为“分发”的构建配置,因为我经常为 beta 测试人员创建临时构建。我创建了两种构建配置,一种称为 Ad Hoc,一种称为 AppStore,所以我并不感到困惑。两者之间的唯一区别是 Ad Hoc 构建的 Entitlements.plist 文件的存在。这样我就可以尽可能仔细地测试我将提交给 Apple 的内容。

      大多数开发人员都是乐观主义者。这就是为什么我们要在周末工作以创建一个我们只知道会让我们成为百万富翁的应用程序。不过,在提交之前,请保持悲观主义。想象一下所有可能出错的地方,然后仔细检查。

      不要假设任何事情。不要以为您对应用程序所做的微小更改不会影响其他任何事情。墨菲定律说,这个微小的变化会导致你的应用程序在所有 iPod Touch 或其他设备上崩溃。在最终代码编辑和 Appstore 提交之间进行彻底的测试、测试、测试。如果您必须进行微小的更改,请重复直到完美为止。

      请记住,如果 99.9% 的用户没有让应用崩溃,那么每 1,000 次下载中就有 1 次会获得 1 星的严厉评价。

      我在开发过程中使用 Clang 静态分析器、泄漏和对象分配,但在提交之前我会额外运行这些工具以防万一。

      如果您没有旧设备,请购买一台,因为 3GS 性能明显更好,您可能会错过一些重要的性能问题。

      当网络或位置适用时,使用以下配置测试您的应用:

      • iPod 触摸
      • iPhone 3G
      • iPhone 3GS
      • iPhone 处于飞行模式
      • 带 Wi-Fi 的 iPhone
      • 带有 EDGE 的 iPhone
      • 在使用您的应用时拨打电话

      【讨论】:

        【解决方案3】:

        我没有切换到发布,而是切换到“分发”。它是 Release 的副本,但这就是一些 Apple 文档和 iPhoneDeveloperTips 教我的方式。

        要点:

        在最终构建之后,但在您急忙压缩应用程序之前,请使用 Finder 的 Show Package Contents 打开捆绑包。由于 MacOS 中的一些错误,它在 Snow Leopard 之前的版本中咬住了我(它可能仍然存在),如果你拉得太快(使用 Finder 的压缩或存档菜单项),一些资源还没有被刷新到文件中。当您执行 Show Package Contents 时,内容会更新。您会注意到这个问题的方式是,您的压缩应用程序的大小将在预期大小的五分之一到十分之一之间或更少。您可能会想,“嘿,那个 zip 实用程序在压缩方面确实做得很好”,但事实并非如此。这个问题会发生在此时而不是在测试期间,主要是因为您正在执行“全部清理”构建,并且应用程序包的所有资源和内容开始都是空的,然后被 Xcode 填充。并且由于某种原因,即使在 Xcode 完成创建文件之后,如果您压缩,内容实际上仍然不存在,但如果您查看它们就会存在(有点反向海森堡)。小心。

        我花费大量时间的另一个方面是对源代码进行很好的备份,在我将所有最新更改提交到 SVN、创建新分支并标记文件之后。我还希望我的版本号与我的 SVN 构建/提交号相匹配,因此我始终知道哪个 SVN 版本与我的版本相匹配。我的 info.plist 中有这两个版本号,应用程序用户可以在他们点击 i 获取信息时提取。例如,当前的 info.pist 包括:

        <key>CFBundleShortVersionString</key>
        <string>2.0a1</string>
        <key>CFBundleVersion</key>
        <string>346</string>
        

        对于如何使用 CFBundleVersion 有不同的想法。这是我的方式。命令行实用程序 agvtool 也很有用。

        一旦构建应用程序,在压缩之后,您实际上并没有对压缩版本进行任何更改,请检查应用程序文件并确保它使用正确的分发证书而不是您的临时证书签名。学习使用命令行实用程序 codesign 有助于这种检查和调试。通过首先制作压缩副本,您可以确保您不会以任何方式更改 Xcode 交给您的最终副本,并且如果一切正常,您将上传到 itunesconnect。

        其他要记住的事情是应用程序图标、iTunes 商店所需的各种其他图标和图形、info.plist,以及当应用程序上传失败并显示神秘错误消息时,它通常具有与您正在构建的压缩文件中缺少这些部分之一(属于应用程序包中的那些部分)有关。

        【讨论】:

          【解决方案4】:

          查看这个清单文件@Github

          https://github.com/bapu/AppReleaseCheckList

          【讨论】:

            猜你喜欢
            • 2017-01-16
            • 2011-01-30
            • 2012-03-19
            • 2016-04-19
            • 2016-03-05
            • 2021-11-06
            • 1970-01-01
            • 1970-01-01
            • 2017-03-05
            相关资源
            最近更新 更多