关闭

遵循以下几条原则,不再纠结Xcode代码签名问题

标签: iosXcode代码签名
236人阅读 评论(0) 收藏 举报
分类:

本文由sandy翻译自JARED SINCLAIR的博客
原文:Follow These Guidelines and Never Struggle with Xcode Code Signing Again


多亏了下面的这些习惯,这一年里我再也没有为Xcode的Code Signing问题纠结过。这些习惯有的看起来很大材小用,而且它们大都比用Xcode里的内置支持功能更“复杂”。但那又怎样!去他妈的胡说八道!做自己的事情,回去该干嘛干嘛!


1.千万不要使用Xcode内置的Code Signing助手工具。尤其不要点击那个所谓的Fix Issuue按钮。那不仅会让你触及很多没用的文件(iOS Team Provisioning Profile…),而且还会导致你陷入配置文件的怪圈。

2.千万不要使用通配符App ID(wildcard app identifiers)。尤其当你在多个团队,而且每个团队又有多个通配符App ID的时候就会很麻烦。花一点时间登录到开发者中心,为你的每个app生成一个特有的bundle ID。不使用通配符App ID,会大大减少Code Signing道路上的陷阱。如果你有使用通配符的项目,马上删除它。新版Xcode使这些变的比之前更难。Let me Google that for you.

3.使用build code sign 和shared schemes。在“Manage Schemes…”面板勾选Shared让这一切变的轻松。一个是开发环境,一个用于App Store的releases版本。如果需要,也可以考虑增加一个用于beta版本。在编辑窗口为每一个scheme选择合适的编译配置。如果你选择Xcode提供的默认的编译配置,那么的你的开发方案会是debug模式,你的发布方案会是release模式。

4. 使用明确的code-signing identities和自动配置选择。因为你现在使用了share schemes连接到指定的构建配置,所以你可以把你的Xcode项目设置的更具帮助性。对于你工程的Code Signing Identity 和Provisioning Profile设置需要distribution证书(Ad Hoc, Enterprise, or App Store distributions)。如果你懒的话,你也可以使用自动的iOS Distribution。可能我有太多的teams,让我不信任xcode能做的那么准确。我建议使用iOS开发自动设置您的调试版本,这样有益于其他的开发者合作。我发现使用以上的signing identities设置,我能为所有的构建设置使用自动provisioning  profile。

5.在target级设置上重复项目级的设置。另一个常见问题就是代码签名和配置文件选择的项目级别设定与target级别设定不匹配。除非你认为你不会犯这个错误(我之前也认为我不会,但现在我知道怎样才更好)。手动将代码签名和Provisioning profile设置为project和 target级别的,并定期检查以确保它们保持一致。

6.删除Keychain Access中过期的证书。Keychain Access让它变的非常简单。大多数证书(Ad Hoc, APN, and App Store)的有效期是365天,一些企业证书可能会延长至三年。在你创建新的分发证书和 APN证书的时候,设置日期闹钟来提醒你去及时更新,以防止证书过期之后你的APN 服务突然发怒,警告你代码错误。

7.确保Keychain Access里有所有需要的证书。在每个团队里你至少需要两个证书:1)一个允许你在设备上安装app的开发者证书。2)  一个分发证书允许你提交程序到 App Store。你也许会需要两个额外的证书用于推送通知(一个用于开发、一个用于生产)。开发和分发证书适用于你团队里的所有程序。APN证书是特定于每个应用的。确保你有这些证书的私钥,存储你的证书并导到安全便捷的地方,以防万一你的高级工程师们因为一些要命的蠢蛋都瘫痪掉的时候,你团队里的每个人都可以传送到APP Store。

8.安装新的文件或证书后无论如何都要重启你的Xcode。缓存过期的证书特别容易出现缓存错误。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:48641次
    • 积分:57
    • 等级:
    • 排名:千里之外
    • 原创:17篇
    • 转载:27篇
    • 译文:0篇
    • 评论:6条
    最新评论