近期由于ios企业签名的动荡出现的频繁掉签，超级签名的价格也一直居高不下。TF签名再度出现到大家的视野，它独有的稳定性和超级大容量的安装设备，价格似乎也比较合适，因此广受APP运营商的追捧。今天跟大家聊一下TF签名TestFlight上架的优势以及教你如何把App上架到苹果官方认可的内测分发渠道testflight详细教程。
TF签名是什么？
TF签名其实只是行业内的叫法，它的全称是TestFlight，是苹果官方认可的一种应用测试渠道，所有要上架到TestFlight应用商店的APP都需要经过苹果官方的审核。成功上架到TestFlight应用商店后，用户可以通过公开的链接进入TestFlight应用商店并加入到该APP版本的内测中。
TF签名有什么优势？
1、TF签名更稳定
前面提到过，凡是要上架到TestFlight应用商店的APP都是需要通过苹果官方的审核的，一旦成功上架到TestFlight应用商店，一般不会轻易掉签，除非你在后期的运营中出现违规内容被用户举报或者恶意刷量。值得一提的是，TestFlight的使用期限是3个月，它可以安装1万台手机，即使过期或者超过1万台安装设备了只要你的应用服务还在，对已安装该应用的设备是不会受到影响的，这时你只需要重新上架生成新的TestFlight下载链接提供到新用户下载安装即可。
2、TF签名价格适中
如果你是一名IOS开发者，可以独立操作上架到TestFlight是不需要一毛钱的。这里主要针对普通的APP运营商，他们对TestFlight上架的流程和政策并不熟悉，所以需要寻求专业平台的帮助。按了解，TestFlight代上架的计费方式有按月、按季度，按月的话一般只需要2000元上下，按季度在5000元左右。其价格和独立版企业签名差不多，不同的是，TF签名即使掉签也不会影响到已安装的应用的用户。
是否存在永久不掉签的TF签名？
在网上看到有不少打着永不掉签的噱头的商家很多，往往也有不少APP运营商被这所谓的“永不掉签”所迷惑。在这里，ios开发子可以负责任的告诉你，遇到打着这种噱头的商家，一定要提高警惕。即使是超级签名，也没有绝对的稳定可言，因为你知道这些平台会给你用的那种号做签名，如果是一些境外号或者调查号说不定几天就掉签了。TF签名掉签的可能性一般出现在运营商，如果在运营的过程中出现违规的内容被用户或同行举报触发了苹果的审核，掉签是肯定的。
最后值得注意的是，由于TestFlight上架需要通过苹果官方的审核，一些涉及违规内容的应用基本是上架无望。如果通过特殊的技术规避比如采用加壳/换壳等手段，能够成功上架到TestFlgith的可能还是有的，只是比较渺小。
下面就给大家详细讲解如何上架苹果TestFlight
环境: IDE xcode 11.3.1 (11C504)
1、确认您的xcode能顺利编译通过
2、Project-Archive
xcode会自动编译并且打包，并且完成后会弹出Archive对话框
3、点击右侧的Validate App
会自动连接App Store Connect来进行初步的验证。
勾选Strip Swift symbols来 减少 app size
4、选择发布的证书来完成发布（这个要在developer.apple.com的account中设置）
好了，下面就会自动检测了，如果不通过会给你一些提示。按提示来修改再次打包就可以了。
下面讲一下，我碰到的问题：
A valid provisioning profile for this executable was not found
字面意思就是app没有一个有效的配制文件
这里要说到一些概念：
Certificates, Identifiers & Profiles
Certificates:证书
Identifies:app的bundle identifier(图1)
Devices:测试设备（比如说你的iphone,ipad等等）
Profiles: 对证书、bundle identifier,devcies的一个总结吧，也就是包括了这些信息，这样你的xcode，还有苹果app store connect才会通过您的认证，
这样你才可以安装到你的测试设备上，或者发布到testflight（公测)，最好上架到app store去供用户购买。
证书可以通过xcode来生成：Xcode - Preferences
开发、发布，根据情况来建立。
图1
在苹果开发者网站上，可以建一个app id ( Application Id)
注册一个App IDs:
加入一个测试手机：
这点，点击download, 下载您的设置到本地，然后双击，这样xcode就可以认到了。
这样的话，基本上就完成了设置工作。
下面我们来看一下xcode中，是如何设置的。
Debug与Release设置是一样的，配制文件不一样，一个选择dev，一个选择release。
还有一个地方也是报错，也是我碰到的
最后还得搞一张图，打包的时候一直报错，大体是这样的错，但都跟 libPods-工程名.framework有关系：
1、Invalid Swift Support : The file 工程.app/Frameworks/libPods-工程.framework doesn't have the corrent file type for this location.
2、Invalid Bundle Structure: The binary file '工程.app/Frameworks/libPods-工程.framework' is not permitted. Your app can't contain standalone
executables or libraries, other than a valid CFBundle Executable of Supprted bundles.
以上是我记忆中的解决方法及打包发布到testflight应该处理的。
时间一长就会忘记，还是记录下，当然如果您碰到了相关的问题，希望能帮到您。
不当之处，可以相互学习，共同提高。
下面讲一下打包成功后，上传到Apple Store Connect
打包成功后，可以导出来
然后选择发布证书，然后就可以导出来了。
导出来以后，会有一个ipa文件，这个文件就是我们需要上传的文件，可以安装一个Transporter
第一次打开用您的app id登录，然后将导出的ipa文件，直接拖进去，然后一般通过了Validate App的话，
直接拖进去就可以了，然后再点提交。
提交完后，apple会在很短的时候里，给你回邮件email，还给我发了几个需要调整的地方：
ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSBluetoothPeripheralUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string
这个意思其实很简单：就是你用的权限中没有明确的指出干嘛用的，也就是在value里面加入一个说明即可
比如，蓝牙是用来连接打印机的
到此上传到App Store Connect就成功了，到此，还需要登录到developer.apple.com -- Account
打开会员中心，然后点击App Store Connect，去构建您的项目，这样就可以提交到TestFlight
让专业人员去帮你审核了，审核通过，都会给你发Email。
只要在App Store Connect后台加入测试人员的email
如果没有收到email的话，可以再点击发送邀请，这样就会收到一封邀请，
1）打开邮件，您会看到一个TestFlight前往的按钮，点一下，就会弹出来一个对话框，里面有一个邀请码，拷贝。
2）然后在手机上的TestFlight “兑换”，帖上您的邀请码，确认。
3）然后就可以看到待安装的App了，安装，打开，输入账号密码，开启测试。
下面我们再来看看mac, xcode, 手机，开发者服务（apple)，这些家伙究竟是咱根据证书还有配制文件，
来处理一些下载到手机安装，打包发布等等工作的。
Code Signing Identity 是咱个工作原理，这里帖个图：
Xcode 中配置的 Code Signing Identity（entitlements、certificate）必须与 Provisioning Profile 匹配，
并且配置的 Certificate 必须在本机 Keychain Access 中存在对应 Public／Private Key Pair，否则编译会报错。
Xcode 所在的 Mac 设备（系统）使用 CA 证书（WWDRCA.cer）来判断 Code Signing Identity 中 Certificate 的合法性：
若用 WWDRCA 公钥能成功解密出证书并得到公钥（Public Key）和内容摘要（Signature），证明此证书确乃 AppleWWDRCA 颁布，即证书来源可信； 再对证书本身使用哈希算法计算摘要，若与上一步得到的摘要一致，则证明此证书未被篡改过，即证书完整。
Verify Code Signature with Certificate
iOS/Mac 设备（系统）使用 App Provisioning Profile（Code Signing Identity）中的开发证书来判断App的合法性：
若用证书公钥能成功解密出 App（executable bundle）的内容摘要（_CodeSignature），证明此 App 确乃认证开发者发布，即来源可信； 再对 App（executable bundle）本身使用哈希算法计算摘要，若与上一步得到的摘要一致，则证明此 App 未被篡改过，即内容完整。
总结
- 基于 Provisioning Profile 校验了 CodeSign 的一致性；
- 基于 Certificate 校验 App 的可靠性和完整性；
- 启动时，真机的 device ID（UDID）必须在 Provisioning - Profile 的 ProvisionedDevices 授权之列。
- 无论是 Xcode 对 APP 进行签名打包还是真机运行 APP 进行校验，都使用了基于证书体系的非对称加密机制。
我的理解：
1、我们在xcode中进行了配制，这样xcode就可以通过我们提供的Provisioning Profile证书来安装APP到手机上，
手机上也会有一份这样的配制，不然，启动APP的时候也不会成功。
还记得以前用免费的APP ID进行开发的时候，有时候第二天就过期，有时候过个3，5天过期，一点就一闪，其实是证书过期了，
每次安装APP的时候，都会连网去验证合法性。
2、一般情况下，只要配制到位了，那肯定不会有Validate App不通过的情况，也就是说不通过一般是配制不到位，不是这里少了，就是这里多了。
或者比如说我们手工设置了，就不要让xcode自动生成了。
这样懂得了原理，我们工作就可以事半功倍了。
