苹果开发者账号类型
个人开发者账号：99美元 一年，可以在AppStore上架，并且在app后面显示个人ID；每年最多只能添加一百个苹果设备对app进行真机调试；只要付费就可以申请；一般是个人使用或者小公司偶尔使用（AppStore显示的是个人名字，不是公司名）。
公司开发者账号：99美元 一年,可以在App Store上架，可以自定义的团队名称。最重要的是公司账号可以允许多个开发者协作开发，比个人多一些帐号管理的设置，分4种管理级别权限。申请的时候同样需要公司的邓白氏编码。（一般公司的话会选择这个）
企业开发者账号：299美元一年，不可以在AppStore上架（所以也就不需要苹果的审核就能直接批量安装在苹果设备上），一般只在自己企业内部使用，对设备数量没有任何限制；申请的时候还需要公司的邓白氏编码DUNS（这个可以在苹果开发者中心免费申请）
苹果对这类证书的申请极为严格，一般的公司基本申请不成功，申请时长也从以前的一个多月延长到半年-1年不等。原因大家的能想到，因为可以避开苹果的审核，发布app的内容也不受限制，常见于博彩app，金融类app（Apple对此类app审核及其严格，设计一些国家的法律法规）等等，所以市场上的价格也比较高，据我所知一般买一个企业号大概（20-50w）左右，物以稀为贵。
- 教育账号
Certificates：有开发证书和发布证书。开发证书都是一样的，我们只说说发布证书：
- AdHoc：这个证书一般用在上线苹果商店前最后一次的调试，它所用是的证书和配置文件和正式上线商店时用的证书和配置文件是一样的，他们的不同点在于，这个证书中指定了哪些苹果设备（最多100）才能安装此app，所以一般公司就用打个AdHoc包，对设备上线前做最后一步测试
1、发布到指定设备
2、发布出来的包需要通过iTunes安装
3、100台，由于苹果的限制，在开发者网站上只能添加100台设备
AppStore：正式发布到苹果商店的证书，这个是我们上线时候用到最多的一种证书，这个证书打包出来的ipa包对安装设备数量没有限制
In House： 这个证书的创建选项现在的好像只能在企业账号中才能看到，这个打包出来的app不能再苹果商店上线，对安装的设备数量也没有限制。这个可以借助一些三方平台比如蒲公英、fire实现方便安装（扫扫二维码就能下载很方便的），当然用工具iTools安装也是可以的,发布到公司内部；In House： 是只企业内部发布，仅限企业内部人员使用。
In-House方式特点
1、不能发布到Apple Store进行销售。
2、不需要Apple评审。
3、可以使用任何已知的私有API。
4、可以安装到任何苹果的设备上，无需任何签名和认证。
5、用户安装只需要一个ipa文件，无需证书和签名文件。
6、可以将包放到一个网址，下载后就能直接安装
企业签名掉签后的用户端的情形
首先在掉签之后，新用户会无法下载，在下载之后，APP只显示名称，而不显示正常的图标，同样在"描述文件与设备管理"中，不会出现新的“企业级应用”。
这里需要注意的是，在分发平台不稳定时，也会出现下载失败，而这种情况表现为：一直处于"等待中"，或者提示下载失败，需要特别注意。
已经安装的用户会无法打开应用，提示"未受信任的企业级开发者"，并且我们打开"描述文件与设备管理"，找到对应证书后，点击"验证应用"无法通过， 这就表示该APP所签的签名已经掉签。
签名机制
非对称加密
通常我们说的签名就是数字签名，它是基于非对称加密算法实现的。对称加密是通过同一份密钥加密和解密数据，而非对称加密则有两份密钥，分别是公钥和私钥，用公钥加密的数据，要用私钥才能解密，用私钥加密的数据，要用公钥才能解密。数字签名
现在知道了有非对称加密这东西，那数字签名是怎么回事呢？
数字签名的作用是我对某一份数据打个标记，表示我认可了这份数据（签了个名），然后我发送给其他人，其他人可以知道这份数据是经过我认证的，数据没有被篡改过。
有了上述非对称加密算法，就可以实现这个需求：
1.首先用一种算法，算出原始数据的摘要。需满足 a.若原始数据有任何变化，计算出来的摘要值都会变化。 b.摘要要够短。这里最常用的算法是MD5。
2.生成一份非对称加密的公钥和私钥，私钥我自己拿着，公钥公布出去。
3.对一份数据，算出摘要后，用私钥加密这个摘要，得到一份加密后的数据，称为原始数据的签名。把它跟原始数据一起发送给用户。
4.用户收到数据和签名后，用公钥解密得到摘要。同时用户用同样的算法计算原始数据的摘要，对比这里计算出来的摘要和用公钥解密签名得到的摘要是否相等，若相等则表示这份数据中途没有被篡改过，因为如果篡改过，摘要会变化。
之所以要有第一步计算摘要，是因为非对称加密的原理限制可加密的内容不能太大（不能大于上述 n 的位数，也就是一般不能大于 1024 位/ 2048 位），于是若要对任意大的数据签名，就需要改成对它的特征值签名，效果是一样的。
好了，有了非对称加密的基础，知道了数字签名是什么，怎样可以保证一份数据是经过某个地方认证的，来看看怎样通过数字签名的机制保证每一个安装到 iOS 上的 APP 都是经过苹果认证允许的。
appStore途径的常规签名
要实现这个需求很简单，最直接的方式，苹果官方生成一对公私钥，在 iOS 里内置一个公钥，私钥由苹果后台保存，我们传 App 上 AppStore 时，苹果后台用私钥对 APP 数据进行签名，iOS 系统下载这个 APP 后，用公钥验证这个签名，若签名正确，这个 APP 肯定是由苹果后台认证的，并且没有被修改过，也就达到了苹果的需求：保证安装的每一个 APP 都是经过苹果官方允许的。
如果我们 iOS 设备安装 APP 只有从 AppStore 下载这一种方式的话，这件事就结束了，没有任何复杂的东西，只有一个数字签名，非常简单地解决问题。
但实际上因为除了从 AppStore 下载，我们还可以有三种方式安装一个 App：
1.开发 App 时可以直接把开发中的应用安装进手机进行调试。
2.In-House 企业内部分发，可以直接安装企业证书签名后的 APP。
3.AD-Hoc 相当于企业分发的限制版，限制安装设备数量，较少用。
苹果要对用这三种方式安装的 App 进行控制，就有了新的需求，无法像上面这样简单了。
新的需求
我们先来看第一个，开发时安装APP，它有两个个需求：
1.安装包不需要传到苹果服务器，可以直接安装到手机上。如果你编译一个 APP 到手机前要先传到苹果服务器签名，这显然是不能接受的。
2.苹果必须对这里的安装有控制权，包括
a.经过苹果允许才可以这样安装。
b.不能被滥用导致非开发app也能被安装。
为了实现这些需求，iOS 签名的复杂度也就开始增加了。
苹果这里给出的方案是使用了双层签名，会比较绕，流程大概是这样的：
1.在你的 Mac 开发机器生成一对公私钥，这里称为公钥L，私钥L。L:Local
2.苹果自己有固定的一对公私钥，跟上面 AppStore 例子一样，私钥在苹果后台，公钥在每个 iOS 设备上。这里称为公钥A，私钥A。A:Apple
3.把公钥 L 传到苹果后台，用苹果后台里的私钥 A 去签名公钥 L。得到一份数据包含了公钥 L 以及其签名，把这份数据称为证书。
4.在开发时，编译完一个 APP 后，用本地的私钥 L 对这个 APP 进行签名，同时把第三步得到的证书一起打包进 APP 里，安装到手机上。
5.在安装时，iOS 系统取得证书，通过系统内置的公钥 A，去验证证书的数字签名是否正确。
6.验证证书后确保了公钥 L 是苹果认证过的，再用公钥 L 去验证 APP 的签名，这里就间接验证了这个 APP 安装行为是否经过苹果官方允许。（这里只验证安装行为，不验证APP 是否被改动，因为开发阶段 APP 内容总是不断变化的，苹果不需要管。）
加点东西
上述流程只解决了上面第一个需求，也就是需要经过苹果允许才可以安装，还未解决第二个避免被滥用的问题。怎么解决呢？苹果再加了两个限制，一是限制在苹果后台注册过的设备才可以安装，二是限制签名只能针对某一个具体的 APP。
可以想到把 允许安装的设备 ID 列表 和 App对应的 AppID 等数据，都在第三步这里跟公钥L一起组成证书，再用苹果私钥 A 对这个证书签名。在最后第 5 步验证时就可以拿到设备 ID 列表，判断当前设备是否符合要求。根据数字签名的原理，只要数字签名通过验证，第 5 步这里的设备 IDs / AppID / 公钥 L 就都是经过苹果认证的，无法被修改，苹果就可以限制可安装的设备和 APP，避免滥用。
最终流程
到这里这个证书已经变得很复杂了，有很多额外信息，实际上除了 设备 ID / AppID，还有其他信息也需要在这里用苹果签名，像这个 APP 里 iCloud / push / 后台运行 等权限苹果都想控制，苹果把这些权限开关统一称为 Entitlements，它也需要通过签名去授权。
因为步骤有小变动，这里我们不辞啰嗦重新再列一遍整个流程：
1.在你的 Mac 开发机器生成一对公私钥，这里称为公钥L，私钥L。L:Local
2.苹果自己有固定的一对公私钥，跟上面 AppStore 例子一样，私钥在苹果后台，公钥在每个 iOS 设备上。这里称为公钥A，私钥A。A:Apple
3.把公钥 L 传到苹果后台，用苹果后台里的私钥 A 去签名公钥 L。得到一份数据包含了公钥 L 以及其签名，把这份数据称为证书。
4.在苹果后台申请 AppID，配置好设备 ID 列表和 APP 可使用的权限，再加上第③步的证书，组成的数据用私钥 A 签名，把数据和签名一起组成一个 Provisioning Profile 文件，下载到本地 Mac 开发机。
5.在开发时，编译完一个 APP 后，用本地的私钥 L 对这个 APP 进行签名，同时把第④步得到的 Provisioning Profile 文件打包进 APP 里，文件名为embedded.mobileprovision，把 APP 安装到手机上。
6.在安装时，iOS 系统取得证书，通过系统内置的公钥 A，去验证embedded.mobileprovision的数字签名是否正确，里面的证书签名也会再验一遍。
7.确保了embedded.mobileprovision里的数据都是苹果授权以后，就可以取出里面的数据，做各种验证，包括用公钥 L 验证APP签名，验证设备 ID 是否在 ID 列表上，AppID 是否对应得上，权限开关是否跟 APP 里的 Entitlements 对应等。
开发者证书从签名到认证最终苹果采用的流程大致是这样，还有一些细节像证书有效期/证书类型等就不细说了。
iOS超级签名的技术原理
下面详细介绍具体原理！分三个步骤！
1、苹果手机扫码打开iOS超级签名分发链接，安装一个描述文件以便获取udid！
2、超级签名系统自动获取本手机的udid，并制作相应udid的证书文件，系统后台快速重签ipa原包！
3、再次打开iOS超级签名分发链接安装，即可安装系统重签好的iOS应用！
udid安装方式的优点及缺点！
优点
相比企业证书，这种方式更加的稳定，只要自己不在后台删除证书，基本可以稳稳定定用一年（证书最多一年有效期）！缺点
最多就加100个iPhone手机udid安装，且中途不能删除udid进行替换！开发者账号年费688人民币成本安装100个苹果手机！
影响企业签名稳定性的因素
1.企业证书的装机量。一般来说，企业证书是用来给自己的企业内部员工用的，如果装机量达到百万级别的时候，肯定是会被苹果检测到的，极有可能会被认定违法苹果协议的，所以企业证书签名的应用越多，安装的数量越多，企业证书也越可能被封掉。
2.企业开发者证书生成的p12的安装数量。根据以往的经验，一般p12证书安装数量不要超过三台电脑，不然可能觉得不安全，可能会触发苹果的安全机制，导致认定企业证书被封。
3.企业证书生成的revoke的次数。企业证书反复的生成和revoke,也会导致触发苹果的安全机制，导致企业账号被封。
4.被举报。 这个可能自己的应用违反相关的法律法规，导致应用被举报，这样证书也会被封掉。
