Xcode中 Target -> General
中的bundle identifier
;php
info.plist
中的Bundle identifier
;html
证书中心的Identifiers
中App IDs
新建App时的Explicit App ID
;ios
以及iTunes Connect
中App信息的套装ID
必须保持一致!!json
在info.plist或者Xcode里的各类设置中,有不少$(XXX)
这样的像脚本同样的东西,因此补充一点Xcode中的环境变量xcode
苹果的证书体系一直都是iOS初学者无尽的梦魇,什么开发证书、发布证书、推送证书,什么ad hoc、内测分发、真机调试……我想每个iOS初学刚开始接触Apple的证书体系的时候心里是绝壁崩溃而且被心中的草泥马践踏的体无完肤的……。服务器
其实苹果的证书其实没那么玄乎,不少朋友弄不懂或者过了一段时间又不知道怎么弄了,本质的缘由是由于对非对称加密(公开密钥加密)的不理解~~致使的~~,因此为了彻底的驾驭苹果的证书,这些基础的知识就是坑你的坎,必须跨过去的。微信
网上有各类解释证书中内心面每一种证书做用是什么、怎么建立、怎么使用的,可是这也只能授人以鱼,因此博主不会介绍每一种证书是干吗的,由于你看前年多了一个Pass Type ID Certificate
,去年又有了WatchKit Services Certificate
,今年又来一个Apple Pay Certificate
……根本就解释这些证书不完嘛~,因此理解这些证书的统一规律才是王道!所谓架构
万变不离其宗app
不少资料都把证书分红两种,分为开发证书(development)、以及发布证书(distribution)。可是博主认为这样分类不是很不科学的,博主的理解的分类是这样的socket
图1
根证书
是与开发者或者企业对应的,只要是被根证书
签名的App均可以理解为是这个证书对应的开发者开发的。因此一个根证书
能够签名多个App。
其余证书
呢是与具体的App对应的,一个App的推送证书是没法给另外一个App使用的,因此一个其余证书
只能为一个App签名,更确切的说是这个App须要使用某一项Apple的服务而去产生这个其余证书
。
因此其实苹果每一年都添加的证书属于其余证书
,这些其余证书并非非必须的,而是使用了苹果的某一项服务时才须要提供的凭证。而根证书
是必须的,它签名的APP是属于这个证书的全部者的。
图2
图中个人这个帐号默认会有两个不一样用途的根证书
,有两个App,分别为App一、APP2,以及它们对应的两种用途的推送证书(属于其余证书
)。
假如我如今须要真机调试App1的推送,那么我只要下载开发根证书
以及App1的开发推送证书
而后双击打开导入钥匙串,而后建立相应profile便可真机调试了;
假如如今我要发布APP2,那么我只要下载发布根证书
以及APP2的发布推送证书
,而后建立相应地profile便可打包上传App Strore了。(这里由于发布的特殊性,因此发布的电脑必须是建立这个发布根证书
的电脑)。
profile(描述文件)下文还有篇幅介绍。
我TM都绕晕了,确实有点麻烦有点复杂,果真iOS开发门槛就是高啊,可是哥就喜欢。
在相应地App的edit中能够添加多套APNs推送证书(其余的证书也相似的)
图3
在这里声明一下,其余证书
其余证书生成的时候,使用的certSigningRequest
文件能够和产生根证书
的certSigningRequest
的不一致,也就是说产生其余证书
时不必定须要产生根证书
的电脑,因此这里也坑了无数的人调试推送,这个在下文推送的那些事详细填坑。
图4
我想这个界面一弹出来的时候,蛋蛋忧伤迎面扑来。而后怒点 Fix issue
,而后大家团队负责管理证书的基友忽然发现证书中心多了好多好乱的证书以及描述文件,而后他爆了一句:what the huck!删掉了带有Xcode *
的证书以及描述文件,而后本身又暴力的点了一发Fix issue
,而后你忽然调试不了了,再暴击Fix issue
键,最后整个团队都只有经过Fix issue
来真机调试了……。
因此慎点Fix issue
,若是点击这个选项,聪明的(~~蠢哭的~~)Xcode就会本身管理描述文件,而后各类莫名其妙的带有Xcode *
的证书以及描述文件……
其实只要坚信一点,证书、设备ID、AppID、描述文件都弄对了就绝逼不会出问题的!
描述文件工做原理
图5
keyChain
查找有没有相应地证书(因此证书要下载好,而且导入keyChain
)额外地,若是公司新增了测试机,而且在证书中心的Devices
中添加了新测试机的ID,这样描述文件也要相应地更新,而后从新下载,下载完以后能够先删除旧的描述文件(博主直接覆盖的方式貌似描述文件没有更新啊),大家能够本身作实验咯,描述文件的路劲/Users/XXX/Library/MobileDevice/Provisioning\ Profiles
XXX
你的用户名。
不要覆盖!记得先删除,能够免除不少问题。
若是说亿万级用户的微信推送服务并非企鹅本身定制的而都是由苹果APNs推送的话,那苹果的推送就真的牛逼了,可是有时候测试推送,常常APNs要死不活的,推了半天才到,有一次在APNs沙箱环境怒推1000多条,而后这条队列持续了半个月才推完~~。因此微信、扣扣确定是定制的推送,有钱就是讨厌,那么任性。
可是苹果推送的开发是比较简单地,若是没有高级推送需求基本就不用写代码了,只要配置好证书一切OK。
如今经常使用的后台server中,通常将推送证书以及推送证书的私钥导出p12交给后台人员便可。
PHP有点调皮,还须要转换成pem
生成PHP须要的Pem证书
准备:
第三步根证书的私钥这里是一个坑!由于一个App的推送证书的建立能够和根证书建立的电脑不一样,也就是keyChain产生的certSigningRequest
不同,因此私钥也是不同的,在这里生成Pem时,注意要使用推送证书的私钥!
操做过程:
把推送证书(.cer)转换为.pem文件,执行命令:
openssl x509 -in 推送证书.cer -inform der -out 推送证书.pem
把推送证书导出的私钥(.p12)文件转化为.pem文件:
openssl pkcs12 -nocerts -out 推送证书私钥.pem -in 推送证书私钥.p12
对生成的这两个pem文件再生成一个pem文件,来把证书和私钥整合到一个文件里:
cat 推送证书.pem 推送证书私钥.pem >PHPPush.pem
而后把这个PHPPush.pem给后台基友们,就能够下班啦。
固然测试推送也比较麻烦,须要模拟真实的推送环境,通常须要后台提供帮助,可是遇到一些后台同事,他们有强烈地信仰着鄙视链的话,很鄙视iOS,内心早就称呼你“死前段”多年了,还那么多事……
因此关于调试推送,博主教你本身推本身!不麻烦别人。
只要拷贝这段代码
<?php // devicetoken $deviceToken = '你的deviceToken'; // 私钥密码,生成pem的时候输入的 $passphrase = '123456'; // 定制推送内容,有一点的格式要求,详情Apple文档 $message = array( 'body'=>'你收到一个新订单' ); $body['aps'] = array( 'alert' => $message, 'sound' => 'default', 'badge' => 100, ); $body['type']=3; $body['msg_type']=4; $body['title']='新订单提醒'; $body['msg']='你收到一个新消息'; $ctx = stream_context_create(); stream_context_set_option($ctx, 'ssl', 'local_cert', 'push.pem');//记得把生成的push.pem放在和这个php文件同一个目录 stream_context_set_option($ctx, 'ssl', 'passphrase', $passphrase); $fp = stream_socket_client( //这里须要特别注意,一个是开发推送的沙箱环境,一个是发布推送的正式环境,deviceToken是不通用的 'ssl://gateway.sandbox.push.apple.com:2195', $err, //'ssl://gateway.push.apple.com:2195', $err, $errstr, 60, STREAM_CLIENT_CONNECT|STREAM_CLIENT_PERSISTENT, $ctx); if (!$fp) exit("Failed to connect: $err $errstr" . PHP_EOL); echo 'Connected to APNS' . PHP_EOL; $payload = json_encode($body); $msg = chr(0) . pack('n', 32) . pack('H*', $deviceToken) . pack('n', strlen($payload)) . $payload; $result = fwrite($fp, $msg, strlen($msg)); if (!$result) echo 'Message not delivered' . PHP_EOL; else echo 'Message successfully delivered' . PHP_EOL; fclose($fp); ?>
将上面的代码复制,保存成push.php
而后根据上面“生成PHP须要的Pem证书”的步骤生成push.pem
两个文件放在同一目录
执行下面的命令
DavidDay$ php push.php
结果为
Connected to APNS Message successfully delivered
是否是就推送成功了呢?呵呵哒
关于打包是有不少姿式的,每一个人都有各自的喜爱,大部分规矩的作法都是使用Xcode的一条龙服务的:
选择相应地描述文件、证书
选择ARM架构机型(模拟器是Intel架构的,真机是ARM架构的,不能通用)
product -> archive
而后就能够选择导出ipa在第三方平台分发测试或者上传App Stroe审核了
这样的作法比较保险,由于archive
只会编译出真机的二进制码,因此不用担忧导出的ipa真机装不起。
另外一种姿式是使用xcodebuild
工具,纯Shell编译,比较很差处理错误,可是逼格满满啊,想详细了解这种姿式的能够看看官方文档 ,或者参考这位同窗的分享
固然嘛,博主做为拖拖派的忠实拥趸,博主打包ipa的时候是这样的:
图6
随时build随时转ipa。
分发内测通常都会使用第三方的平台,fir、蒲公英 都很好呀~
关于提交审核这里,通常archive过去了,证书正确都没问题的,固然仍是要检查项目是否调用了私有API,以前用reveal ,提交应用的时候忘了移除,千不应万不应的仍是用了Xcode的upload工具,也不报错,在iTunesConnect中构建版本也出现了,只是状态“正在处理”,通常这个状态持续10分钟~2个小时就会经过了,而后博主自信关机下班,想不到次日构建版本仍是“正在处理”,而后猜测是否是iTunes出问题了又怒传了N个包,依然是“正在处理”,后来准备发邮件,打开邮箱,尼玛!
图7
原来调用了私有接口,忘记移除reveal了~,回顾起来这里有三个大坑,
Application Loader
,速度快,错误报告也精准。打包项目证书选择必须正确 (Xcode7如下 选择项目编译target为Iphone Device 不要链接手机 不然会 ,Xcode7中不须要拔出真机,由于多了一个build only device
的选项)
编译target选错了 报错
ITMS-90530 "Invalid MinimumOSVersion. Apps that only support 64-bit devices must specify a deplyment target of 8.0 or later" IMTS-90208 "Invalid Bundle. The bundle xxx.app does not support the minimum OS version specified in the Info.plist" IMTS-90502 "Invalid Bundle. Apps that only contain the arm64 slice must also have'arm64' in the list of UIRequiredDeviceCapabilities in Info.plist ")