一般技术性平台的博客你都可以去尝试在上面写，iOS是属于技术性平台里面的分支，博客的内容都是垂直性地，所以没有存在专业与否的差别，只有对平台的选择的差别。而真正显现出博客主的专业程度的，是博客主里面的内容。故介绍几个活跃度，知名度都挺高的平台，你可以去尝试着发表，成与败看自身了。
创新互联建站拥有十年成都网站建设工作经验,为各大企业提供成都网站制作、成都网站设计、外贸营销网站建设服务，对于网页设计、PC网站建设（电脑版网站建设）、成都app软件开发公司、wap网站建设（手机版网站建设）、程序开发、网站优化（SEO优化）、微网站、域名申请等，凭借多年来在互联网的打拼，我们在互联网网站建设行业积累了很多网站制作、网站设计、网络营销经验，集策划、开发、设计、营销、管理等网站化运作于一体，具备承接各种规模类型的网站建设项目的能力。
CSND： 创立于1999年，中国最大的IT社区和服务平台，主要服务于软件开发者与IT从业者，有自成一套的周全体系。
博客园：创建于2004年1月，虽然诞生于一个小城市中，却仍旧获得了不错的发展。成长过程可谓励志。后来在上海创建了自己的团队，注册用户4w+，每日访问用户15w+，有博客，小组，博问，网摘，闪存，新闻频道，知识库和期刊多种区块。
开源中国：成立于2008年8月，主攻开源技术社区，200w+会员，有开源软件库、代码分享、资讯、协作翻译、码云、众包、招聘等几大模块内容。
blogspot：被收纳于Google，是国外的网站。首身是Pyra Labs公司创建的博客网站，提供网志书写和发布服务等功能，是全球最大、最为知名的博客服务提供商。
作为一个一个iOS底层开发小白，一直以来对于底层原理，都是一知半解的状态，希望从此时记录自己学习底层知识的过程，也希望对其他开发中可以有一个好的帮助，因为自己看其他人的博客时候，大多数作者都是基于自己认知的前提下，记录自己的知识，在我看来对于入门的人来说，非常晦涩难懂，所以希望自己的文章，可以更加帮助其他人循序渐进的了解更多关于 iOS 的知识。文章也会尽量一步步的探索更多业务开发之外的东西，对于任何方面的技能，都可以友善的帮助后来的开发者。文章中有任何错误，不恰当的地方，欢迎随时指正，多多交流才可以共同进步。想要学习 OpenGL 首先需要了解 OpenGL/OpenGL ES/Metal 三者之间的联系：
通俗来讲就是， Apple 作为大厂，肯定要发展自己的底层渲染技术，所以推出了 Metal ，在推出 Metal 之前，苹果的底层渲染也是基于 OpenGL/OpenGL ES 的，在 iOS 12.0以后，苹果摒弃了 OpenGL 的相关 API ，使用 Metal 作为自己的渲染技术，但是 OpenGL 相关的 API 依然可以使用，因为在 Metal 之前，苹果提供了非常丰富的关于使用 OpenGL 相关 API ，类似于苹果推出了 swift ，但是 OC 依然是自己主流语言一样。了解了相关的背景，我们接下来要知道图形 API 究竟是用来解决什么样的问题存在的。
OpenGL/OpenGL ES/Metal 在任何项目中解决问题的本质就是利用 GPU 芯片来高效的渲染图形图像。图形 API 是 iOS 开发者唯一接近 GPU 的方式。想要了解 OpenGL 就要先学习关于 OpenGL 的专业名词，了解了这些，才可以对以后的学习，有更加深刻的认识。
状态机在 OpenGL 可以这么理解， OpenGL 可以记录自己的状态（当前所使用的颜色、是否开启了混合功能等），可以接输入（当调用 OpenGL 函数的时候，实际上可以看成 OpenGL 在接受我们的输入），如我们调用 glColor3f ，则 OpenGL 接收到这个输入后会修改自己的“当前颜色”这个状态， OpenGL 可以进入停止状态，不再接收输入。在程序退出前， OpenGL 总会先停止工作；
这里有一个 iOS 中很经常听到的概念， 离屏渲染 ，很多人知道离屏渲染会对 APP 的性能造成较大的开销，但是却不知道原理是什么，相信大家了解了上面关于 OpenGL 关于交换缓冲区的概念后，有了一个更清晰的认识，即： Off-Screen Rendering 是需要开辟新的缓冲区的，不停地切换上下文的环境则是对性能的很大的消耗，所以在 iOS 开发中，我们应当尽量的避免离屏渲染。
在学习 OpenGL 的过程中，直接非常直观的掌握并理解这些概念并不是一件容易的事，但是至少需要在入门阶段，大致的了解这些概念的意思，然后通过后续的学习，慢慢的巩固前面学到的知识，温故而知新，一步步的打开关于 iOS 底层渲染知识的大门，学习的越来越深入，慢慢的回过头看以前的知识点的时候，就会豁然开朗了。
希望能一步步的记录自己学习的过程，慢慢进步，慢慢成长，文章中有任何错误的地方，欢迎指正。希望能多多交流，共同进步。
购买一个域名和虚拟主机。
博客程序选择wordpress或者zblog，很快就能搭建一个博客。
希望可以帮到你，有不清楚的可继续追问。
首先，需要明确你使用HTTP/HTTPS的用途，因为OSX和iOS平台提供了多种API，来支持不同的用途，官方文档《Making HTTP and HTTPS Requests》有详细的说明，而文档《HTTPS Server Trust Evaluation》则详细讲解了HTTPS验证相关知识，这里就不多说了。本文主要讲解我们最常用的NSURLConnection支持HTTPS的实现（NSURLSession的实现方法类似，只是要求授权证明的回调不一样而已），以及怎么样使用AFNetworking这个非常流行的第三方库来支持HTTPS。本文假设你对HTTP以及NSURLConnection的接口有了足够的了解。
验证证书的API
相关的Api在Security Framework中，验证流程如下：
1). 第一步，先获取需要验证的信任对象(Trust Object)。这个Trust Object在不同的应用场景下获取的方式都不一样，对于NSURLConnection来说，是从delegate方法-connection:willSendRequestForAuthenticationChallenge:回调回来的参数challenge中获取([challenge.protectionSpace serverTrust])。
2). 使用系统默认验证方式验证Trust Object。SecTrustEvaluate会根据Trust Object的验证策略，一级一级往上，验证证书链上每一级数字签名的有效性（上一部分有讲解），从而评估证书的有效性。
3). 如第二步验证通过了，一般的安全要求下，就可以直接验证通过，进入到下一步：使用Trust Object生成一份凭证([NSURLCredential credentialForTrust:serverTrust])，传入challenge的sender中([challenge.sender useCredential:cred forAuthenticationChallenge:challenge])处理，建立连接。
4). 假如有更强的安全要求，可以继续对Trust Object进行更严格的验证。常用的方式是在本地导入证书，验证Trust Object与导入的证书是否匹配。更多的方法可以查看Enforcing Stricter Server Trust Evaluation，这一部分在讲解AFNetworking源码中会讲解到。
5). 假如验证失败，取消此次Challenge-Response Authentication验证流程，拒绝连接请求。
ps: 假如是自建证书的，则会跳过第二步，使用第三部进行验证，因为自建证书的根CA的数字签名未在操作系统的信任列表中。
iOS授权验证的API和流程大概了解了，下面，我们看看在NSURLConnection中的代码实现：
使用NSURLConnection支持HTTPS的实现
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// Now start the connection
NSURL * httpsURL = [NSURL URLWithString:@""];
self.connection = [NSURLConnection connectionWithRequest:[NSURLRequest requestWithURL:httpsURL] delegate:self];
//回调
- (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
//1)获取trust object
SecTrustRef trust = challenge.protectionSpace.serverTrust;
SecTrustResultType result;
//2)SecTrustEvaluate对trust进行验证
OSStatus status = SecTrustEvaluate(trust, result);
if (status == errSecSuccess
(result == kSecTrustResultProceed ||
result == kSecTrustResultUnspecified)) {
//3)验证成功，生成NSURLCredential凭证cred，告知challenge的sender使用这个凭证来继续连接
NSURLCredential *cred = [NSURLCredential credentialForTrust:trust];
[challenge.sender useCredential:cred forAuthenticationChallenge:challenge];
} else {
//5)验证失败，取消这次验证流程
[challenge.sender cancelAuthenticationChallenge:challenge];
}
}
上面是代码是通过系统默认验证流程来验证证书的。假如我们是自建证书的呢？这样Trust Object里面服务器的证书因为不是可信任的CA签发的，所以直接使用SecTrustEvaluate进行验证是不会成功。又或者，即使服务器返回的证书是信任CA签发的，又如何确定这证书就是我们想要的特定证书？这就需要先在本地导入证书，设置成需要验证的Anchor Certificate(就是根证书)，再调用SecTrustEvaluate来验证。代码如下
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
//先导入证书
NSString * cerPath = ...; //证书的路径
NSData * cerData = [NSData dataWithContentsOfFile:cerPath];
SecCertificateRef certificate = SecCertificateCreateWithData(NULL, (__bridge CFDataRef)(cerData));
self.trustedCertificates = @[CFBridgingRelease(certificate)];
//回调
- (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
//1)获取trust object
SecTrustRef trust = challenge.protectionSpace.serverTrust;
SecTrustResultType result;
//注意：这里将之前导入的证书设置成下面验证的Trust Object的anchor certificate
SecTrustSetAnchorCertificates(trust, (__bridge CFArrayRef)self.trustedCertificates);
//2)SecTrustEvaluate会查找前面SecTrustSetAnchorCertificates设置的证书或者系统默认提供的证书，对trust进行验证
OSStatus status = SecTrustEvaluate(trust, result);
if (status == errSecSuccess
(result == kSecTrustResultProceed ||
result == kSecTrustResultUnspecified)) {
//3)验证成功，生成NSURLCredential凭证cred，告知challenge的sender使用这个凭证来继续连接
NSURLCredential *cred = [NSURLCredential credentialForTrust:trust];
[challenge.sender useCredential:cred forAuthenticationChallenge:challenge];
} else {
//5)验证失败，取消这次验证流程
[challenge.sender cancelAuthenticationChallenge:challenge];
}
}
建议采用本地导入证书的方式验证证书，来保证足够的安全性。更多的验证方法，请查看官方文档《HTTPS Server Trust Evaluation》
使用AFNetworking来支持HTTPS
AFNetworking是iOS/OSX开发最流行的第三方开源库之一，其作者是非常著名的iOS/OSX开发者Mattt Thompson，其博客NSHipster也是iOS/OSX开发者学习和开阔技术视野的好地方。AFNetworking已经将上面的逻辑代码封装好，甚至更完善，在AFSecurityPolicy文件中，有兴趣可以阅读这个模块的代码；
AFNetworking上配置对HTTPS的支持非常简单：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
NSURL * url = [NSURL URLWithString:@""];
AFHTTPRequestOperationManager * requestOperationManager = [[AFHTTPRequestOperationManager alloc] initWithBaseURL:url];
dispatch_queue_t requestQueue = dispatch_create_serial_queue_for_name("kRequestCompletionQueue");
requestOperationManager.completionQueue = requestQueue;
AFSecurityPolicy * securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
//allowInvalidCertificates 是否允许无效证书（也就是自建的证书），默认为NO
//如果是需要验证自建证书，需要设置为YES
securityPolicy.allowInvalidCertificates = YES;
//validatesDomainName 是否需要验证域名，默认为YES；
//假如证书的域名与你请求的域名不一致，需把该项设置为NO
//主要用于这种情况：客户端请求的是子域名，而证书上的是另外一个域名。因为SSL证书上的域名是独立的，假如证书上注册的域名是，那么mail.google.com是无法验证通过的；当然，有钱可以注册通配符的域名*.google.com，但这个还是比较贵的。
securityPolicy.validatesDomainName = NO;
//validatesCertificateChain 是否验证整个证书链，默认为YES
//设置为YES，会将服务器返回的Trust Object上的证书链与本地导入的证书进行对比，这就意味着，假如你的证书链是这样的：
//GeoTrust Global CA
// Google Internet Authority G2
// *.google.com
//那么，除了导入*.google.com之外，还需要导入证书链上所有的CA证书（GeoTrust Global CA, Google Internet Authority G2）；
//如是自建证书的时候，可以设置为YES，增强安全性；假如是信任的CA所签发的证书，则建议关闭该验证；
securityPolicy.validatesCertificateChain = NO;
requestOperationManager.securityPolicy = securityPolicy;
这就是AFNetworking的支持HTTPS的主要配置说明，AFHTTPSessionManager与之基本一致，就不重复了。
3. 总结
虽然HTTPS相比于HTTP来说，会有一定的性能上的劣势，但对于网络飞速发展，移动设备的性能成倍增长的今天，安全才是我们更应该去考虑的。全网HTTPS并不是那么遥远。
唐巧建了个 iOS 开发的slack群组:iOS开发 Slack，里面有两个博客订阅的频道，中文一个，英文一个，都是已经挑选好的 Blog 订阅，不用自己重新甄选，省事有用！
另外唐巧也在维护一个 中文 iOS/Mac 开发博客列表：tangqiaoboy/iOSBlogCN · GitHub，外加 onevcat 喵神组织的 objc中国 翻译，基本涵盖了网络上优质的 iOS 中文文章了
国外：
Raywenderlich
NSHipster
Strings - objc.io issue #9
iOSDeveloperTips.com
Beginning iPhone App Development
Tuts+ Code Tutorials
Matt Gemmell
markj.net
mikeash.com: NSBlog
iOS App Dev Libraries, Controls, Tutorials, Examples and Tools
国内：
破船之家
代码手工艺人
唐巧的技术博客
iOS News
iWangKe.me
Lancy's Blog
不谈BUG、不谈信号，确实不能体现一部手机的实际作用，近年来苹果是踩了一些坑，因为专利问题而弃用了高通基带，导致iPhone信号严重变差，当然用户体验也变得比较的糟糕。
硬件问题显然是不能够利用iOS系统的更新去修复的，不然苹果也不会顶着“骂名”在经历几十个iOS版本的更新还是没有“修复”信号差这个通病，而高通因为和苹果的和解，最早只会2020年的6月份才开始在iPhone的新设备上进行装备。
本身的iOS系统也在iOS 13发布之后变成了BUG系统，机友现在只能够等待iOS 14新系统的到来才能弥补这许多的不足。
iOS从客观上来说是一个优秀的手机系统，就算不去仔细的分析其中的利弊，在如今各大手机厂商推出自己的系统UI之后还能保有一定的稳定市场，说明市场对iOS是认可的。从前有个笑言：“买苹果手机其实就是买iOS系统送手机”。
iPhone的可玩性很高，不单只是对其进行本身系统存在的功能上来说，从iPhone诞生后不久，BUG安全研究者、越狱工具开发者和苹果之间的相爱相杀持续了近十三年，越狱之后的iPhone能够借助插件为所欲为，实现原本没有的功能。虽然很多的插件让iPhone像安卓，但是他们会说：“像安卓的iPhone，你值得拥有”。
之前分享过iPhone安装Windows的消息，但是必须基于UTM虚拟机上安装，能够启用iPhone中70%的资源，对于大一点的系统就非常难受了，Windows 10的启动时间就超过了20分钟，这谁能忍。
不过，区别于正常使用手机，这就是叫做【玩机】，越狱也好、在iPhone上安装其他系统也好，都是属于研究作用的，稳定的工具可以让你把研究着去玩，但是也别忘记了，这是在非正常情况下使用手机，遇到众多的问题只能一步步的解决掉。
PostmarketOS手机操作系统是一款国外团队专门为旧手机准备的开源系统，现在已经支持超过139+款手机。开发出来的目的是为了应对厂商不对旧手机进行系统升级的情况。
这是基于Linux的操作系统，而安卓就是基于Linux内核创建的。
最近令人最振奋的消息就是国外的开发者将PostmarketOS移植到了iPhone 7上，而且最新的社区成果是做到了双分区！
什么意思？
就是能够在一部手机里同时存在两个系统，最终的效果是能够双启动手机系统。
这个本来是没有办法在iPhone手机安装的，由于checkm8硬件漏洞的发布，以及越狱工具checkra1n和Corellium的帮助下，真就被这群极客们在半年时间实现了。
安装方法开发者给的很全面，但是对于没有折腾心的机友来说确实是很难折腾成功，因为过程有点复杂。
千万不要用主力机做研究实验，可能会遇到不可撤销的错误。开发者博客上也说明了，虽然步骤已经过多次实验，证明可行，但是需要风险自担。
此处因为过程过于复杂和步骤太多，转述可能会有诸多错误，具体的方法和工具可以自行到开发者博客中查看，看不懂英语的可以使用浏览器的翻译功能进行查看。
开发者博客（复制全）：
双启动实验：