上面我貌似有点记错了，对 Swift 是如上面的，对 Objective-C 我就不清楚了

http://www.v2ex.com/i/2ds26pM9.png

这个其实是为 Swift 做的功能，此外除了 NSArray 、 NSDictionary 、 NSSet 这三个，其它类型没啥特殊处理，你可以当作没范型这个东西。

所以这次 iOS 9 苹果加了个 openURL 的白名单机制啊 XD

“不仅能够在受感染的 iPhone 中完成打开网页、发短信、打电话等常规手机行为，甚至还可以操作具备伪协议能力的大量第三方 APP ”，分析一下：
1. 打开网页：是可以的，不过打开网页要能造成危害的话，还得依赖其它漏洞
2. 发短信：只能打开短信界面，不能在无用户交互的情况下发送短信
3. 打电话：同上
4. 操作具备伪协议能力的大量第三方 APP ：基本上，设计合理的第三方 app ，也应该是只弹出一个界面，然后需要用户交互才能做真正的操作的（当然不排除一些 app 为了“方便用户”而省略了这个交互的需求）。 iOS 9 开始这个也会收到白名单的限制。

还有一点，正如上面有人说了，这些事情，每个 app 都可以做的。对我来说，即使是“大厂的 app ”，它如果做了一次这种事情，那么我也会立即保留证据然后删除掉它。

----
Apple 这次最大的问题其实是：
1. 系统喜欢毫无规律地弹出登录框。不只是 iOS ，桌面上的 iTunes ，也时常会在无用户操作时忽然登录状态丢失，然后弹一个登录的窗口让用户去输 Apple ID 和密码。这种无规律地弹出登录框的行为，其实是在培养用户无辨别地输 Apple ID 和密码的习惯，非常不安全。
2. 系统的登录框毫无辨别性， app 可以伪造一个几乎一样的弹窗诱骗用户输入密码。当然细节上， app 无法获得 Apple ID ，但是真心想伪造的话，可以试图从 app 自己的用户信息里面读取 email 来显示为一个可编辑的 Apple ID 输入框，还是有很多人会中招的；甚至就用一个空的 Apple ID 输入框，都会有人中招，毕竟，系统在有些地方（比如 App Store ），是会出现这样的登录框的（而且也是没有太明显的规则的）。

问题 1 的解决可能需要改好多流程，不过解决问题 2 其实有现成的方案的。

比如暴雪公司的游戏《魔兽世界》，它在游戏里面提供了直接战网余额（对应现实中的钱）来买虚拟物品的功能，购买的时候会需要用户输入密码来授权。它面临了一个类似的问题，游戏是允许加载第三方的 UI 插件的，如果这个授权界面很简单，那么可能会出现恶意插件伪造授权界面来钓鱼的情况发生。于是暴雪就使用了第三方插件无法获得的信息做了一个非常易辨识且原则上无法伪造的授权界面（感兴趣的人可以自己去游戏里面体验一下）。

苹果可以不做得那么丑，但是要做到易辨识且无法伪造，并不是不可能的。

重新申请一个账号。

@est 其实是可以的。公司 Developer ID 下面可以添加各种角色的各种账号（ Apple ID ），有相关权限的账号就可以去 https://developer.apple.com/downloads/index.action 上面直接下载 dmg 。

然而，架不住还是有人觉得慢……

图灵不是一个人吗？怎么还有 API ……

这次的 Swift 2.0 是稳定版，之前的还不是。

以前 Objective-C 又不是没出过因为类似的大更新导致要改很多的事情……

@Daddy 反了吧。所谓“ Windows 不安全”不就是因为用户喜欢从各种奇怪的地方下载安装程序而不验证么……

iOS 需要有丰富 Swift 经验但是 Objective-C 的语法已经忘光的人吗？

讲不清楚说明你自己没有完全理解

@JackBlack2006 MAS 是 https ，不过这并不重要，重要的是 iOS app 的安装和开始运行的时候都会去检查应用包的签名，确认包完整且没有被修改过才会安装和运行。

即使是越狱了，这个机制仍然在。不过，如果用户越狱是为了装盗版应用，那么多半他会再装一个补丁把上面的签名检查机制禁用掉。那就只能听天由命了。

其实只是微信下版本（ for iOS 9 ）早就已经提交并通过审核，就在等 iOS 9 发布而已吧

你要相信，很多来应聘程序员的人其实并不会编程，然后你就会释然了

strace.co 是什么鬼……

可以 关键字 bare repo

另外，最好改掉这个习惯

技术上能
但是不应该

这个 license 用 GPL 能起到什么作用……

最大的麻烦是每年续一次的时候，上面这些麻烦事都得再做一遍吧