错误缘由是这个bundle ID已经被别人提早占用了,bundle ID必须是惟一的。
解决办法固然是修改你的bundle ID 了。html
点击查看原文:阳光的味道ios
刚接触iOS开发的人不免会对苹果的各类证书、配置文件等不甚了解,可能你按照网上的教程一步一步的成功申请了真机调试,可是仍是对其中的原因只知其一;不知其二。这篇文章就对Certificate、Provisioning Profile等作个总结。安全
若是你拥有一个开发者帐户的话,在 iOS Dev Center打开Certificates, Indentifiers & Profiles,你就能够看到以下的列表:app
Profile Portal改版有一段时间了,改版以后的结构比之前更清晰明了,易于理解和管理。上面的列表就包含了开发、调试和发布iOS应用程序所需的全部内容:Certificates、Identifiers、Devices、Provisioning Profiles。下面将一一解释这几个东东。ide
证书是用来给应用程序签名的,只有通过签名的应用程序才能保证他的来源是可信任的,而且代码是完整的, 未经修改的。在Xcode Build Setting的Code Signing Identity中,你能够设置用于为代码签名的证书。测试
众所周知,咱们申请一个Certificate以前,须要先申请一个Certificate Signing Request (CSR) 文件,而这个过程当中其实是生成了一对公钥和私钥,保存在你Mac的Keychain中。代码签名正是使用这种基于非对称秘钥的加密方式,用私钥进行签名,用公钥进行验证。以下图所示,在你Mac的keychain的login中存储着相关的公钥和私钥,而证书中包含了公钥。你只能用私钥来进行签名,因此若是没有了私钥,就意味着你不能进行签名了,因此就没法使用这个证书了,此时你只能revoke以前的证书再申请一个。所以在申请完证书时,最好导出并保存好你的私钥。当你想与其余人或其余设备共享证书时,把私钥传给它就能够了。私钥保存在你的Mac中,而苹果生成的Certificate中包含了公钥。当你用本身的私钥对代码签名后,苹果就能够用证书中的公钥来进行验证,确保是你对代码进行了签名,而不是别人冒充你,同时也确保代码的完整性等。ui
证书主要分为两类:Development和Production,Development证书用来开发和调试应用程序,Production主要用来分发(生产,上架Appstore)应用程序(根据证书种类有不一样做用),下面是证书的分类信息:(括号内为证书有效期)加密
有一些类型的证书我没有使用过,因此也不了解具体的做用。spa
App ID用于标识一个或者一组App,App ID应该是和Xcode中的Bundle ID是一致的或者匹配的。App ID主要有如下两种:调试
每建立一个App ID,咱们均可以设置该App ID所使用的APP Services,也就是其所使用的额外服务。每种额外服务都有着不一样的要求,例如,若是要使用Apple Push Notification Services,则必须是一个explicit App ID,以便能惟一标识一个应用程序。下面是目前全部可选的服务和相应的配置要求。
若是你的App使用上述的任何一种service,就要按照要求去配置。
Device最简单了,就是iOS设备。Devices中包含了该帐户中全部可用于开发和测试的设备。 每台设备使用UDID来惟一标识。
每一个帐户中的设备数量限制是100个。Disable 一台设备也不会增长名额,只能在membership year 开始的时候才能经过删除设备来增长名额。
关于设备数量的问题,唐巧的技术博客:关于iOS测试机个数上限的详细规则
一个Provisioning Profile文件包含了上述的全部内容:证书、App ID、设备。
试想一下,若是咱们要打包或者在真机上运行一个应用程序,咱们首先须要证书来进行签名,用来标识这个应用程序是合法的、安全的、完整的等等;而后须要指明它的App ID,而且验证Bundle ID是否与其一致;再次,若是是真机调试,须要确认这台设备可否用来运行程序。而Provisioning Profile就把这些信息所有打包在一块儿,方便咱们在调试和发布程序打包时使用,这样咱们只要在不一样的状况下选择不一样的profile文件就能够了。并且这个Provisioning Profile文件会在打包时嵌入.ipa的包里。
例如,以下图所示,一个用于Development的Provisioning Profile中包含了该Provisioning Profile对应的App ID,可以使用的证书和设备。这意味着使用这个Provisioning Profile打包程序必须拥有相应的证书,而且是将App ID对应的程序运行到Devices中包含的设备上去。
如上所述,在一台设备上运行应用程序的过程以下:
与证书同样,Provisioning Profile也分为Development和Distribution两种:
(注:前面提到不一样帐户类型所能建立的证书种类不一样,显然Profile文件的种类是和你所能建立的证书种类相关的)
In House 与Ad Hoc的不一样之处在于:In House没有设备数量限制,而Ad Hoc是用来测试用的,Ad Hoc的包只能运行在该帐户内已登记的可用设备上,显然是有最多100个设备的数量限制。因此这两种Provisioning Profile文件的区别就在于其中的设备限制不同而已,而他们所使用的Certificate是相同的。
根据上面的介绍,能够知道进行Development主要有如下几个步骤:
事实上第三步一般是不须要的,由于咱们一般都是用Xcode生成和管理的iOS Team Provisioning Profile来进行开发,由于它很是方便,因此不须要本身手动生成Provisioning Profile。
iOS Team Provisioning Profile是第一次使用Xcode添加设备时,Xcode自动生成的,它包含了Xcode生成的一个Wildcard App ID(*,匹配全部应用程序),帐户里面全部的Devices和全部Development Certificates,以下图所示。所以,team中的全部成员均可以使用这个iOS Team Provisioning Profile在team中的全部设备上调试全部的应用程序。而且当有新设备添加进来时,Xcode会更新这个文件。
网上有不少关于发布App Store的流程,我就不缀述了,不过根据上面的概念介绍,不论是App Store、In-House仍是Ad-Hoc,打包流程都是差很少的,都包括了如下几个关键步骤:
在Xcode 7+ 中,苹果改变了本身在许可权限上的策略,此前Xcode只开放给注册开发者下载,但Xcode 7改变了这种惯有的作法,无需注册开发者帐号,仅使用普通的Apple ID就能下载和上手体验。此前开发者需每一年支付99美圆的费用成为注册开发者才能在iPhone、iPad、Apple Watch等真机上运行代码,苹果新的开发者计划则放宽要求,无需购买,只要你感兴趣一样能够在真机设备上测试app(除了测试Apple Push Notification)。若是你打算向App Store提交应用,那仍然须要付费。😅