我意识到我可以为构建或类似设置编译器标志,但是如果存在可以利用的现有方法,我想利用这一点.
解决方法
有一堆数据可以在“构建信息”的通用伞下.这些事情的非详尽列表将包括：构建配置,代码签名身份,构建时间,构建日期,营销版本号,SCM版本号,SCM分支名称,配置配置文件组标识,配置配置文件过期,CI构建号.这个名单一直在继续.
假设您的问题目前狭窄地集中在获取有关构建iOS用户类型和配置配置文件的信息,那么我将不得不以非常坚定的“否”作为问题的答案：是否有在运行时检查[使用现有API方法构建信息]的方法？简而言之,这两个数据点在Xcode 4.6.x Build Settings或“CODE_SIGN_IDENTITY”中被称为“Code Signing Identity”,用于您的命令行构建设置爱好者.
在提出此问题的时候,您没有可以调用的单一的公共iOS API来获取有关当前正在运行的应用程序的代码签名类型的信息.这背后的可能原因很多,但下面是几个例子：
允许开发人员构建自己的构建方案并构建配置.这意味着我们可以有一个方案和一个构建配置,或一个方案和几十个构建配置,甚至每个配置数千个.自然地,可以为每个方案分配不同的构建配置,并且可以为每个配置分配不同的代码签名身份.您可能会猜到,开发人员或团队不需要太多的自定义来快速获得混乱.
>代码签名标识仅要求为当前应用程序标识符发出未过期的配置配置文件,其中包含用于对二进制文件进行签名的证书的公用密钥副本.对于在团队中工作的人员,您可能有一个配置配置文件,其中包含团队中开发人员的所有证书,或者您可以为仅包含其证书的团队中的每个开发人员设置单独的配置配置文件.这是开发人员如何选择构建应用程序的另一个变化点.
>开发人员可能会分享单一证书(tsk tsk),或者发行自己的证书…是的,你猜到了,更多的变化.
然后,这个假设的一站式API将需要在运行时访问所有的构建配置数据,证书和配置配置文件,以便能够解开在编译时应用的“有效”设置,并将所有数据减少到有限的字符串…只是为了开发人员诊断视图…通过任何想象力不是不可能的壮举,但是对于可忽略的开发人员利益而言,这样一个潜在的计算密集型操作肯定会在任何人的优先级列表中排名很低.鉴于其他选项(如编译时标志！)更可靠,更便宜的设置,并且从长远来看更易于维护,它将进一步降低优先级列表.
现在,关于“我可以在运行时能做到”的半潜伏问题吗？我会强调说“是的,你可以”.
如你所知,设备构建是唯一需要代码签名的构建.该过程的一部分在主包中创建一个名为“embedded.mobileprovision”的文件.这是您的应用程序的沙箱拥有的文件,因此您绝对有能力以编程方式打开：
[[NSBundle mainBundle] pathForResource:@"embedded.mobileprovision" ofType:nil]@H_301_25@.mobileprovision文件是PCKS#7编码的,并且包含二进制和文本数据.您寻求的信息是嵌入在PCKS#7数据中的基于文本的plist.首先,使用OS X,我们来看看您的一个设备构建中的这些文本数据：
>右键单击您的构建设备.app包,然后选择“显示包内容”
>将embedded.mobileprovision文件复制到一个容易访问的地方.
>使用首选文本编辑器打开该文件.您马上注意到有很多二进制数据,但您可以制作出部分文本数据.滚动到右边,你会看到plist风格的xml,只是在这个视图中看起来不是那么容易.我们可以使用OS X命令行工具以更有条理的方式查看这些数据：
>打开终端和’cd’到包含您的embedded.mobileprovision副本的文件夹.
>运行：security cms -D -i embedded.mobileprovision这将显示plist xml到终端窗口,以便您以良好的标签格式进行阅读.如果您重复此过程进行Ad-Hoc构建,Dev构建和App Store构建,那么您将开始注意到本文中的键,表示各种类型的构建.对于使用“iPhone开发人员：…”证书签名的构建(或“Dev”按原始帖子列出的方式构建),请查找：
<key>get-task-allow</key> <true/>@H_301_25@“get-task-allow”键是用来指示iOS的应用程序将允许调试器附加到它.在“iPhone开发人员”签名的二进制文件的情况下,这是有道理的 – 当将代码从Xcode推送到您的设备进行测试时,您通常需要在设备上进行调试.
“Ad-Hoc”和“App Store”之间的差异需要额外的检查.对于这两种类型的分发,这个相同的“get-task-allow”键将被设置为false：
<key>get-task-allow</key> <false/>@H_301_25@然而,“Ad-Hoc”版本的“App Store”构建中没有定义的“ProvisionedDevices”集合：
<key>ProvisionedDevices</key> <array> <string>abcdef01234567890abcdef01234567890abacde</string> <string>1abcdef01234567890abcdef01234567890abacd</string> <string>2abcdef01234567890abcdef01234567890abacd</string> </array>@H_301_25@那么运行时检查问题在实际中是什么意思呢？是的,您可以通过从主包中打开embedded.mobileprovision文件,并从中解析出数据,做出明智的决定,但这是您将完全负责实现自己的事情.您需要添加逻辑来处理该文件丢失的情况(例如模拟器构建),并解析PCKS#7数据或可靠地提取文件的ASCII内容,您的代码可以运行一系列字符串搜索.可能显而易见的是,这将需要非常简单的方法来解决一个有点脆弱的解决方案,否则可以通过构建设置和预处理器宏来容易地适应上述答案中所述的Abhi Beckert.
App Store拒绝的风险如何？这是“非法”还是“颠覆”？
假设您在阅读和解析embedded.mobileprovision文件的内容时使用所有公共API,这完全可以通过App Store的当前条款.您的应用程式沙箱中的任何内容都是公平的游戏,包括embedded.mobileprovision,如果它恰好存在.我仍然强烈警告不要走这条路,回应Abhi Beckert的意见.对于不到1％的使用案例来说,这是相当多的努力,而且有更容易的解决方案！此外,开发人员诊断视图不应该在App Store发布版本中,但是包含无关代码的决定完全在您的手中.
我希望这清除任何留下的问题,但如果没有,请抛出一个评论,我们可以看到我们能做什么.
