苹果已经放出了 iTunes 10 下载，请点击这里转到下载页面。
安装 iTunes 10 后，即可登录体验苹果的 iTunes Ping 音乐社交网络服务。

下周三苹果的发布会上，除了 iPod 系列和 Apple TV 的硬件产品升级换代，软件或许也将成为亮点，有传闻称苹果可能会推出新版 iLife 软件套装和全新的基于网页的轻量级 iTunes Store 。
关于新版 iLife 的推测，主要是基于该软件的更新周期大约为 18 个月，上一次 iLife 的重要升级还是在 09 年初。此前，曾有消息称，新版 iLife 将完全剔除 iDVD 程序，并对 iWeb 进行重大升级，还将增加一款“神秘”的未知软件。但考虑到此次发布会的主题仍是音乐和娱乐产品，新版 iLife 出炉的可能性或许并不大。
然而，每年 9 月新一代 iPod 的发布都会伴随着 iTunes 软件的重大升级。今年最大的变化，可能是苹果将推出完全基于网页的 iTunes Store ，这或许是 iTunes Store 自 2003 年上线以来最重要的一次变化。
事实上，关于 iTunes Store 走出封闭的 iTunes 客户端，成为基于浏览器的互联网的一部分，已是公开的秘密。今年 2 月我们就曾介绍过这一变化：苹果悄悄推出的 iTunes Preview 以及收购网页流媒体音乐公司 Lala 都是在为 [...]

本周四，苹果放出了 iWork 9.0.4 更新，除了修复 Pages 、Keynote 和 Numbers 的细节漏洞，主要为 Pages 新增了 ePub 电子书格式导出功能。
对于那些手头有大量电子文档的 iPad 用户，或升级到 iOS 4.0 的 iPhone 用户，都可以使用该功能方便地制作标准 ePub 格式的电子书，方便自己随身阅读。
您可以通过系统的「软件更新」查找该更新，更新后 Pages 的「文件」-「导出」中已增加了 ePub 选项（下图）。

假如一台机器可以同时运行 Mac OS X 和 iOS ，会怎样？
不得不承认，这是一个激进的想法，但又非常地合乎逻辑。今年上半年苹果申请了一个专利，它的初衷或许很简单——制造一台可以用触摸屏操作的 iMac（见下图）。

一台常规的 iMac ，运行的是 Mac OS X 操作系统，通过键盘和鼠标来进行操作。如果为 iMac 添加了触摸屏，那么不可避免地 Mac OS X 操作系统的界面需要进行修改，才能适合手指的触控操作。苹果想了一个更聪明的办法：
当用户在用键盘、鼠标进行操作，iMac 就运行 Mac OS X ；
如果用户用手指进行触摸操作，iMac 就自动切换到 iOS 模式，直接使用 iOS 操作系统。
这个想法令人叫绝，但仔细一想 iOS 不也正是为触摸屏而优化的 Mac OS X 吗？上图中，当 iMac 的屏幕竖起时，仍是一台普通的 Mac ；但只要将 iMac 的屏幕放平缓，则机器自动切换到 iOS 模式，操作系统的界面会变成适合手指触摸的元素，见下图。

你或许已经等不及想要买一台这样的 iMac 了。但如果告诉你，有这样一台 MacBook 笔记本，它可能会像 MacBook Air 那样轻薄，开启屏幕后它就是一台工作用的笔记本。但只需将屏幕旋转一下，正面朝上，它立刻变身为一台 11 英寸触摸屏 iPad 。
你会怎么想呢？ [...]

浏览器能够做什么？查邮件、看视频、在线 Office 办公，这些都是线上软件目前能做的不错的，但还能否做的更多呢？这也是这两天「Web 死或不死」的讨论核心之一，即移动互联网上浏览器能不能提供不输于本地应用的体验。
目前看来，本地应用对比线上软件可能有着更多的优势，所以会有「浏览器已死，Web 只是在进化」的看法。但在 Google 看来，浏览器都不会死。浏览器仍有十分巨大的潜力，至少玩一些像植物大战僵尸这样的游戏是没问题的，而且未来 PC 和平板上 Web 仍有很大的空间。
根据 Google 的计划，今年 10 月份将正式上线 Chrome Web Store，一个基于 Chrome 浏览器的 Web 应用商店。开发者可使用 Flash、HTML 5/JaveScript 和 C++ 语言来为这个线上软件商店编写应用。

Google 表示,整个线上应用从创建、封装、上传和发布的过程都十分简单，快速。而且浏览器仍然有许多独到的优势，比如多标签页、即时安装和关闭、全屏浏览等。

最重要的是，Google 为 Chrome Web Store 创建了一套自己付费和销售体系，并且 Google 只从开发者的应用销售收入提成 5% 的象征性“手续费”。绝大多数利润都归开发者所有。这是否会让 4399 这样的游戏站紧张起来？

最后，归根到底线上应用究竟能达到怎样的效果，Google 也举了几个例子：
1、前段时间很受关注的，完全用 CSS 完成的 Twitter「Fail Whale」动画，点击这里可以看见。
2、Google 自己的尝试，当然是 PAC-Man Google doodle ，你可以访问这里继续玩这个游戏。
3、当然了，目前最多的还是 Flash 游戏。

当我按照上面图片中 Chrome 地址栏里的地址，一个个字母敲出下面这个链接：
http://www.popcap.com/prettypkg/games/pvz/flash/1033/pvz_9_15.swf
稍等了片刻之后，伴随着诡异声音的响起，我惊了！
昨天我还有些怀疑 Chrome OS [...]

这是一篇围绕 iOS 来介绍 ARM 结构的文章，用词简单，逻辑清楚，偶见幽默。非开发者也值得一读，权当增长知识。

我在写「NEON on iPhone 入门」的时候，曾以为读者已经比较了解 iOS 设备的处理器知识。然而，看过网上的一些讨论，我才发现，原来这些知识并不普及，我的错。此外，我觉得了解这些东西对 iPhone 编程有益（不仅仅针对喜欢 NEON 的人），即便你用的是 Objective－C，虽然，不了解也无碍工作，但这些知识会让你成为一个更好的 iPhone 程序员。
基础
到目前为止，所有的 iOS 设备都使用 ARM 结构处理器，它和台式机上的 x86 和 PowerPC 有些不同，然而绝对不是「特殊」或「小众」的产品。几乎所有的手机（不只是智能手机）都基于 ARM，例如几乎所有的 iPod，几乎所有的 MP3 播放器，PDA 和 Pocket PC 更不用说了。任天堂从 GBA 开始转入 ARM，它甚至还侵入图形计算器的地盘，出现在一些德仪和惠普的计算器中。如果你还想继续溯本逐源，那么牛顿用的也是 ARM（苹果是 ARM 的早期投资者）。而且上面只说了一些小玩意，还有无数的 ARM 处理器运行在嵌入式系统中。
ARM 处理器因为低功耗和小尺寸而闻名，它的性能在同等功耗的产品中也很出色。这种结构（至少在 iOS 平台）使用小端（Little-endian）排序，就像 x86。它和 MIPS、PowerPC 一样，属于 32 位 RISC 结构。请注意，模拟器并不运行 ARM 代码，软件会被编译成 x86 可以运行的指令。因此接下来的内容适用于目标设备，而非模拟器。
ARMv7，ARM11，Cortex [...]

本文特指升级到 iOS 4 的 iPhone 3G。
据一些 iPhone 3G 用户的反馈，当升级至 iOS 4 后，手机的运行速度变得非常缓慢，几乎达到无法使用的程度。RoughlyDrafted Magazine 网站提供了一个解决的办法：执行一次深度重启。
也许多数用户认为，长按电源键，当屏幕出现红色滑槽时关机，然后再按安电源键启动手机，就算我们理解中的「冷启动」。其实不然，这么做对改善系统的性能无益，因为，这个过程有一点像「休眠」操作：关机后 iPhone 把下次启动所需的系统资源写入闪存，重启后，系统仍然维持关机前的状态。
因此，为了清除系统中多于的资源，必须同时按住电源键和 Home 键，持续约 10 秒钟的时间。此时系统直接杀掉所有进程，立刻重新启动手机。
因为不从闪存中恢复状态，深度重启需要消耗比平常更多的时间，iPhone 4 大约使用 30 秒，而在 iPhone 3G 上要超过 4 分钟（有读者反馈，第一次重启需要 2 分半钟，第二次重启为 2 分钟。）。
iPhone 3G 的处理器远逊于 iPhone 3GS，内存更只有 128MB，但经过深度重启后，速度可见显著的优化。
原文末的部分回复：
1、某些 iPhone 3G 速度并未降低，但经常遇到程序崩溃的现象，使用这种办法可以修复。
2、建议深度重启后继续按住电源键和 Home 键，然后手机会关机，此时再按电源键开机（未经证实，慎用）。
3、建议如果一次深度重启不管用，再做一次。
[原文链接；作者：Daniel Eran Dilger]

这篇文章有趣的是，上做阐述，下为分解。原本因为时间所限，无法一天内译完，没想到，拆开后反而更符合作者的心境。
我也完全没有料到上篇所引起的争议，但我相信，看过上文的读者在读完下文之后，可以理解席拉库萨的苦心。
这是一篇能够打动人心的作品，至少对我来说是这样。我极少见到如此感人的科技文章，苹果能有这样的粉丝，足矣。不妨摘录一些片段：「我的诸多担忧是一种过激反应…」；「尽管苦闷挥之不去…」；「我曾经千思万想，希望苹果早日动手。」
须再次说，原文有许多参考链接，有助理解内容。另外，原文的近 300 条评论值得一看，质量很高。我觉得，就正反方数量之比，Apple4us 的读者与 Ars Technica 的读者相差不大。
比以往更紧迫
哦，我知道你在想什么。你们这些 Cocoa 开发者定会认为我失去了理智。你们说：Cocoa 和 Objective-C 是苹果最叼的东西，才不是定时炸弹！而且，尽管源于 C 语言，但 Objective-C 提供了 Java 都还不支持的动态性能和语言特性，因此，说它「低级」是不公平的。还有啊，不要忘了垃圾回收机制，iOS 总有一天会支持。
无论如何，你认为，这一切都不重要。何况空谈不如实践：谁的程序更好？谁的用户体验最棒？谁赚的钱更多？而且苹果的桌面或移动平台的种种缺陷没有影响到什么嘛，看起来一切正常！
开发界有句老生常谈，在程序员中奉作经典，不妨援引：你习惯何种抽象层级的编程语言，那么这种语言就是最合适你的语言。视低级语言过于原始，高级语言臃肿耗能。在全行业抽象度愈加高耸的今日，仍是如此。
首先，如今写 C 的同学大概没人会用汇编了，但 C++ 虚表调度的速度还是太慢，难于采纳。接着，C++ 党也许会懊恼的追忆起当年是如何将他们半残的对象系统嵌入 C 中的，但他们却很鄙视 Java。再后来，Java 党开始嘲笑指针和手动内存管理，但 JavaScript 却被讽刺为玩具级的脚本语言，干一些验证网页表单的粗活。诸如此类…
在短期内，在当下，他们大多是正确的。但，这是条不归之路，而且，正指向愈加抽象的层次。下一次跨越何时到来，不妨观察业界的前缘。苹果通过 iPhone 的成功为自己争取到了一些时间，但以目前竞争之惨烈，这也许仅仅是一厢情愿。
转换之难
尽管「2010」危机没有到来，苹果最终仍需面对该问题。我关注这个问题的原因，无论在 5 年前，还是现在，都是一样的，即：开发平台很难改变。首先，选择或开发一门新语言，并为其打造一套新的 API 存在技术难题。优秀的 API 需要多年的发展和累积。Cocoa 就是个好例子。
不幸的是，寄望将现有的 API 导入新的高级语言和运行环境，并能正常工作，几无可能。转用高级语言能减少原 API 复杂度。例如：
NSInteger myCount = [[myDict objectForKey:@"count"] integerValue];
NSArray *myArray = [myString componentsSeparatedByString:@","];
myItem = [myArray [...]

重磅级科技文章大多出自有软件开发背景的作者，须渗入底层才知道事情的始末——电脑世界绝对是这样的。平台技术横向比较的文章我所见不多，也许开发者都清楚，但少有人写出来吧。
2005 年，约翰·席拉库萨（John Siracusa）连发三文，预测苹果将会遭遇平台危机。未想 iPhone 的兴起延迟了危机的发生，五年后，他发文检讨，但仍认为，不跨越内存管理的障碍，危机仍将隐现。
这是上篇，下篇将于明日发出。原文链接甚多，译文不便一一列出，见谅。

预测科技业的未来是件棘手的事情 — 不妨看看比尔·盖茨十五年前的预测结果 — 虽如此，预言的诱惑总是强烈的。我亦因此闻名。有时候我猜的挺准，2008 年时我说「苹果和 Adobe 之间只有战争。」含糊、幽默式夸张、不明确的时间表是成功预测的基本要素。
其他时候，我就没有这么幸运了。五年前，我写了题为《别在 2010 年重蹈 Copland 的覆辙》的系列文章，分三篇发出。但这一次，预测的内容既严肃又具体，而且标题中还有年份。换言之，想不失败都难了。好吧，2010 年已经来到——曾经的那个未来！——所以，是时候挨批了……或者，这可以算乌鸦嘴的胜利么？但重要的是，「Copland 2010」究竟说的是什么呢？
背景
苹果曾数次尝试开发新一代操作系统，Copland 是几个项目中最声名狼藉的一个。Copland 始于上世纪 90 年代，「新一代」是指支持内存保护和抢先式多任务，当时的 Mac OS 不支持这两项功能。从那时起，Copland 见证了苹果从近乎崩溃，到承认并及时解决其软件平台重大的技术差距。通过这次不可思议的收购 — 一款独立发展的现代操作系统、一个被驱逐的公司创始人 — 苹果得以留存下来。
在《别…》的第一部分，我提出了我的论点：Objective-C 语言和 Cocoa API 是Mac OS X 中最危险的部分，因为它们落后于竞争，而到 2010 年，苹果会发现自己面临着另一个 Copland 式的危机，因为它缺少内存托管语言和 API 。在第二部分，我详述了我的假设。分别是：

桌面操作系统的开发环境终将提供全自动内存管理功能。
到 2010 年，其他对手将会采用支持全自动内存管理的语言和 API。
而现有的技术（2005）与可能的演进，无法充分满足苹果对内存托管语言和 API 的需要。

这些假设受到了强烈的质疑。
在第三部分，我评述了那些有可能超越 Objective-C 和 Cocoa 的语言及 API。我也试着鼓励质疑「2010 年」的人们，观其大局。
毕竟，人人同意 Cocoa [...]

美国时间 21 日苹果即将正式发布更名之后的 iOS 4 系统，所有 iPhone 和 iPod touch 用户均可以免费获得该更新。
iOS 4 提供了应用程序文件夹管理、多任务处理和 iBooks 支持等诸多新功能，其中一个细节功能可能会影响到开发者对于其应用程序图标文件的处理。
跟 iPad 一样，iOS 4 开始允许用户自定义 iPhone 和 iPod touch 的「主屏幕背景图片」（并非锁定屏幕的图片），而在此之前 iPhone 和 iPod touch 的主屏幕背景一律是黑色的，无法更改——这也造成一些问题：许多开发者在设计自己的应用程序图标时，往往以黑色作为底色，且图标的形状并非标准的圆角正方形。
在 iOS 4 之前，这是一个很棒的办法，能够让自己的应用图标在黑色背景的 iPhone 主屏上看上去很特殊，「看上去」可以是自己想要的任何形状，「实际上」是自己想要的任何图形周围包裹着一个标准的黑色圆角正方框。
当用户自定义一张照片作为主屏幕背景，原本与黑色背景融为一体的黑色边框就凸显出来了，比如下图：

当然，这并不是最糟糕的情况，如果你的图标设计的够精致，在 iOS 4 上显示出来也顶多是一个有黑色边框的图标，就像上面的那样，也不错。
但还有不少开发者用的图标，与圆角正方形已经非常相近了，只不过仍有一些细微的差异，所以有开发者采取了「用黑色线条来压边」的办法。在 iOS 4 之前这些细节都不易被用户发现，但当用户用了自定义主屏幕图片，这些应用的图标边缘就会显现出一条明显的黑色线条，看上去不太舒服，比如下图是来自 iPad 的截图：

举例并无冒犯之意，供 iOS 开发者们参考 :)