Reading view

There are new articles available, click to refresh the page.

iPhone 上最好的相机 App,是怎么和苹果决裂的?

过去十年,苹果在 iPhone 影像上的投入有目共睹。

从「Shot on iPhone」全球广告企划,到发布会上越来越长的相机环节,再到每年的 Pro 机型都在传感器尺寸、计算摄影和视频规格上不断加码。

▲ 图|WIRED

十九年来,苹果始终都在传递着这样的信息:对绝大多数人来说,他们只需要 iPhone 这一台相机。

但作为「绝大多数人的相机」,就必须能兼顾各种类型的需求才行。而 iPhone 始终有一个缺憾:iOS 的默认相机 app 一直偏向「傻瓜模式」——

对于早期 iPhone 来说,这种「傻瓜模式」可以很好地降低普通用户的心理门槛和使用难度,即使完全不懂摄影,拿着手机也能拍到不错的照片。

▲ iPhone 5 相机广告:Photos Every Day

但是随着 iPhone Pro 系列影像规格的逐年攀升,这种「傻瓜相机」的路径就显得格格不入了:

对于想要手动调整白平衡、对焦,或者需要参考斑马纹和直方图的用户来说,iOS 自带的相机应用无法提供足够的自由度,等于是白白浪费了 Pro 系列的硬件。

iOS 老牌第三方相机 app「Halide」填补的正是这个空缺。

这款由 Lux Optics 开发的相机应用,提供了 RAW 拍摄、手动对焦、直方图、色彩波形、焦峰提示等一整套专业控制,同时保持了极其克制、直觉化的交互设计。

▲ 图|Apple Developer

根据应用分析机构 Appfigures 的数据,Halide Mark II 更是目前 App Store 中最受欢迎的付费相机应用。

况且 Halide Mark II 的定价为 59.99 美元买断,或 19.99 美元/年订阅——在免费应用占绝对主流的 App Store 中,这个价格本身就是品质的证明。

而 Halide 背后的母公司 Lux Optics Incorporated,同样有着一段不寻常的经历。

Lux 的故事始于 2016 年,起点是一条 Twitter 私信。

前 Twitter 工程师 Ben Sandofsky 与前苹果工程师 Sebastiaan de With 因为在社交媒体上聊摄影器材而结识,两个发烧友一拍即合,决定合伙做一款相机应用。

▲ Ben Sandofsky(左)和 Sebastiaan de With(右)|Apple

Sandofsky 此前是 Twitter iOS 客户端的技术负责人,还担任过 HBO《硅谷》剧集的技术顾问。

de With 则参与过苹果 MobileMe、iCloud 和 Find My 的设计工作,也为 Sony、T-Mobile 和 Mozilla 做过设计。

用 de With 自己的话说,他们做的「不是单纯的 app」,而是「一整台相机」——他们希望把传统相机上拨动光圈环和快门拨盘的那种触觉快感,带到 iPhone 的玻璃屏幕上。

这种「有审美、有技术、有想法」的组合,最终让 Halide 成为了 App Store 生态中最具代表性的独立应用之一。

▲ 图|iPhone in Canada

相应的,Apple 对 Lux 的支持力度也远超一般开发者。

Halid 数次获得「年度最佳 iPhone 应用」、App Store 设计大奖,也会常驻应用商城的编辑精选。苹果开发者网站上专门为 Halide 做过两篇深度开发者专访,将该产品作为 App Store 优质开发者的样板展示。

在苹果提供给全球监管机构的报告中,Lux 的应用成为了开发者在 App Store 获得蓬勃发展的代表案例。

▲ 图|Apple Newsroom

相对应的,Lux 也始终忠于苹果生态,从未计划过任何 Android 应用。

正是由于这种「你侬我侬」的状态,当苹果去年找到 Lux 谈收购时,大多数业内人士的第一反应是:这太合理了。

iOS 26虽然对 iPhone 原生相机交互做了较大的调整,但仍然不够。人们期待着 iPhone 相机能够得到一次彻底的升级。而 Halide 团队在近十年里积累的手动控制交互经验、RAW 处理流水线,以及对 iPhone 相机硬件的深度理解,都是现成的财富。

▲ 图|CNET

据外媒报道,年末的 iPhone 18 Pro 系列在部分高级功能上将接近专业相机的水平,苹果正在为此重新设计内置相机应用。

而收购 Lux Optics,再融合 Halide 到系统相机,就是计划的一部分。

但收购没有谈成。

从收购失败到创始人决裂

上周,3 月 20 日,Sandofsky 将一纸诉状提交至加州高等法院——被告,是他的联合创始人。

根据诉讼文件,苹果与 Lux 的收购谈判在去年 9 月终止。没谈成是因为公司正在开发的新产品推高了价格,让苹果无法忍受。

然而根据诉状,实际情况并非如此:苹果发现,根本不用花大价钱买走 Lux,只需要把 de With 招回苹果就够了。

▲ 图|Medienstürmer

收购谈判结束后不久,Sandofsky 在调查 de With 的财务行为时发现:苹果已经开始尝试招募自己的联合创始人,而面试对接人刚好是之前苹果参与收购谈判的人员。

除了指控 de With「自愿被挖墙脚」之外,Sandofsky 还提出了严肃的财务指控:诉讼状闲时,de With 从 2022 年底开始,使用公司信用卡支付个人消费,累计超过 15 万美元。

其中包括用公司账户购买了一张近 7560 美元的机票(法兰克福-巴黎-圣保罗),de With 声称是为之后的商务旅行准备,但无法提供确认邮件。

▲ 图|Peter Peerdeman

de With 还涉嫌用公司资金购买了自己和女友前往法属波利尼西亚的「产前假」机票,以及其他涉及住宿、服装和酒水等与 Lux 公司业务无关的消费。

自从和苹果的收购谈崩之后,Sandofsky 就开始感觉不对劲了,于是去年 10 月雇佣了调查人员进行财务审查。

11 月,他将 de With 带薪停职——然而就是在停职调查期间,de With 开始与苹果沟通入职事宜。

12 月,Sandofsky 主持的内部调查结束,Lux 解雇了 de With,并要求他立即归还所有公司财产,包括存有敏感数据的电脑,并提醒他有义务不得泄露内部信息。

而 Sebastiaan de With 似乎并没有接受这个结果。

今年 1 月 28 日,Sebastiaan de With 在 X 上官宣加入苹果设计团队。

然而诉状中提到,de With 加入苹果时带走了 Lux 的源代码和机密材料,包括前面提到的「未来产品开发」相关的信息。

Lux 于 2022 年获得的 Apple Design Award 奖杯,也被这位苹果老员工带走了。

▲ 图|iMore

面对诉状,被告方律师在声明中全面否认了上述指控。

关于财务问题,备稿律师称这些费用「已记录在册、清晰可见,且在当时从未被质疑」,是对「在一家共同管理、缺少正式管控的小公司里的正常、已披露的业务活动的事后重新定性」。

更关键的是,律师称这场诉讼是 Sandofsky 对 de With 要求查阅公司财务记录的报复——

de With 曾就公司的「财务违规行为」向 Sandofsky 提出质疑并正式要求查账,但相关要求一直未被满足。

▲ 图|Getty Images

关于 Halide 等等一系列 app 的知识产权,律师否认 de With「使用、转移或披露了任何 Lux 知识产权」,并称 de With 已将公司材料归还给 Lux。

一位律师直接表示:

(Sandofsky)试图将苹果(收购 Lux 这件事)拉入这场纠纷,目的是制造杠杆和吸引关注,而不是解决任何实际的不当行为。

被告律师在声明中强调:「此案不是一起欺诈案件,而是长期合作关系破裂,所导致的联合创始人纠纷」

至少在纸面上,Sandofsky 的诉讼的确没有将苹果列为被告,也从未指控苹果在其中有任何不当行为。

开发者社区的复杂情绪

Sebastiaan de With 加入苹果的消息公布时,开发者社区的反应就已经相当复杂,而 Lux 内部诉讼的曝光让这些讨论多了一层新的含义。

de With 去年 6 月发表过一篇设计文章——「Physicality: The New Age of UI」,探讨 Apple 可能的设计语言走向。

当时的语境中,这是一位独立设计师对 iOS 与 Liquid Glass 平台未来的畅想;现在回头看,这篇文章多了一层耐人寻味的含义。

▲ 图|Wallpaper 网站专访苹果设计团队时收到的 visionOS 设计稿细节

有人对 de With 的加入表示祝贺,认为他的设计才华可以给苹果注入新血液——尤其在人机界面主管 Alan Dye 去年底离职前往 Meta 之后。

但也有人感觉事情不对劲。比如,开发者 CM Harrington 就表示,他对 de With 加入苹果的忧虑在于,他只是一个人,而「公司其余的人也得在乎设计,才能让有品味和能力的人真正发挥作用」。

另一位评论者更直接:

我会因为一个人在(苹果)目前这种领导层状态依然选择去苹果工作而判断他。(de With)加入这个系统,是因为认同它,而不是因为感觉自己能改变它。

▲ 图|AppleInsider

而在 Reddit 上,Sandofsky 也在 1 月 25 号当天出面,反复强调 Halide 不会受影响,说自己从 2019 年就全职投入 Lux。

当然,1 月 Sebastiaan de With 表示加入苹果时,还没有人知道两位联合创始人已经撕破脸了。当时大家都以为,一个创始人离开、另一个创始人坚守,直到诉状揭开了故事的背面,是一个长久以来存在,且在苹果生态里经常被提起的问题:

作为一个苹果开发者,如果某一天你的产品/功能,被苹果公司直接做成系统产品/功能,你又该何去何从?

2002 年,苹果在 Mac 内置工具 Sherlock 3(聚焦搜索的前身)中复制了第三方付费应用 Watson 的几乎所有核心功能,Watson 的市场空间被迅速蚕食,最终无奈离场。

这个产品名 Sherlock,也因此直接演化成了这种行为的代名词。

▲ WWDC 2002 乔布斯介绍 Sherlock 3|YouTube @AppleVideoArchive

「被苹果 sherlock」的焦虑,一直在加深。最近的例子,是苹果在 macOS 26 中将剪贴板历史集成到聚焦搜索里,对 Raycast、Alfred、Paste 等第三方应用带来了不小的冲击。

▲ WWDC 2025|Apple

更不用说 iPhone 上的通话录音、夜览、密码 app、Sidecar 等等……一个又一个曾经属于第三方应用的核心功能,陆陆续续被苹果吸纳进了系统,变成了免费功能。

但这一次 Lux 的遭遇,激进程度完全上了一个台阶:不折腾,直接把人招走。

无独有偶,苹果与医疗设备公司 Masimo 之间也曾有过一段类似的摩擦。

2015 年初代 Apple Watch 发布前夕,苹果曾与 Masimo 讨论在血氧传感技术领域进行合作。谈判破裂后,苹果大规模挖走了 Masimo 的员工,这些人随后参与了苹果健康监测技术的开发。

▲ 图|AppleInsider

Masimo 就此提起了两项诉讼。2025 年 11 月,陪审团在其中一项专利侵权案中判决苹果需要赔偿 Masimo 6.34 亿美元,苹果正在就此事提起上诉。

NPR 在报道苹果的「Sherlock 行为」时,援引了 App Store 前高管 Philip Shoemaker 的说法:许多开发者不敢公开批评苹果,因为害怕被从 App Store 里下架。

没有现成的答案

尽管诸事不顺,Lux 并没有放弃自己的产品。正相反,公司还在继续优化 Halide 等产品——甚至其中部分设定,颇有对苹果的挑衅意味。

今年 1 月,Lux 发布了 Halide 第三代公开预览版,Sandofsky 表示他将继续全职运营 Lux,并与知名设计工作室 The Iconfactory 和调色师 Cullen Kelly 合作开发新版本。

▲ 图|Lux

今年 2 月,在接受《Inc.》杂志采访时,Sandofsky 还阐述了一个颇具哲学意味的观点:

现在的 iPhone 照片过于「完美」,以至于变得平庸。

而新版 Halide 将会自带一个「Process Zero」功能,旨在绕过所有 iPhone 预设的相机算法(比如令人深恶痛绝的 Deep Fusion),让用户拍出「不那么完美但更有个性」的照片。

从今往后,Halide 这个产品,不想再给苹果的应用生态唱「样板戏」了。

正相反,它要举起反抗苹果的大旗了。

▲ 图|Halide.cam

而在苹果那边,Sebastiaan de With 和苹果设计部门都在经历一轮深刻变革。人机交互设计副总裁 Alan Dye 离职,资深设计师 Stephen Lemay 接任。

同一时间,苹果还在继续推进从 Liquid Glass 到整个 UI 系统的视觉翻新。de With 的理念能在多大程度上影响这个进程,仍然是未知数。

▲ 图|Wccftech

我们无法预判这场 Lux 创始人之间的纠纷,最终会以何种方式收场。毕竟双方各执一词,诉讼尚未进入审理阶段。但无论结果如何,它都触及到了 App Store 生态中最敏感的神经。

过去二十多年,苹果开发者社区会反复追问自己:「当苹果做了你的功能时,你该怎么办?」

现在,这个问题变成了:「当苹果直接来挖你的好友兼联合创始人时,你又该怎么办?」

没人有现成的答案。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

Can you still run old App Store apps?

In my review of apps and the validity of certificates used to sign them, I dodged the thorny issue of those apps delivered from the App Store, writing that “their signatures will remain valid as long as the developer remains a member of its Developer Program.” If you care to take a look at some of those apps using Apparency, you’ll discover that many of them have certificates that expired on 7 February 2023 at 00:00:00 GMT. This article explains why, how they should still run, but may not in the future.

As I explained, the general rule for certificates is that, once they have expired by date, they’re no longer valid. However, to ensure that third-party apps and installers can still be used after their expiry, Apple usually includes a trusted timestamp in their signature. Provided the certificate was valid at the time the app or installer was signed, then macOS should accept it as still being valid, as long as it hasn’t been revoked. But App Store apps are different again.

For reasons unknown, Apple doesn’t sign App Store apps with trusted timestamps. As a result, when its certificate expires, that app’s signature should no longer be valid, and macOS should refuse to run it on that basis. What happens in practice is that it turns a blind eye to the certificate expiry, and runs the app regardless.

What you see in the log demonstrates that. At the start of its security checks by Apple Mobile File Integrity (AMFI), securityd discovers that its certificates no longer have “temporal validity”, and fail trust evaluation:
00.701706 com.apple.securityd cert[0]: TemporalValidity =(leaf)[]> 0
00.701753 com.apple.securityd cert[1]: TemporalValidity =(leaf)[]> 0
00.703344 com.apple.securityd Trust evaluate failure: [leaf TemporalValidity] [ca1 TemporalValidity]

Those entries are repeated multiply every time that app’s trust is evaluated, including by TCC. Despite that, the app passes its Gatekeeper evaluation “due to migration”:
00.718197 com.apple.syspolicy.exec GK evaluateScanResult: 2, PST: (path: c97bd5e74b98ed79), (team: 4GXF3JAMM4), (id: (null)), (bundle_id: (null)), 0, 0, 1, 0, 9, 0, 0
00.718213 com.apple.syspolicy.exec Allowing evaluation due to migration: PST: (path: c97bd5e74b98ed79), (team: 4GXF3JAMM4), (id: (null)), (bundle_id: (null))
00.718218 com.apple.syspolicy.exec Updating flags: [private], 513

As with all other apps, a ‘ticket check’ is performed on its CDHashes, first against the local ticket cache, then against records in the CKTicketStore via CloudKit. As App Store apps aren’t normally notarised as well, looking up their ticket in the CKTicketStore should be unsuccessful. In macOS Tahoe at least, there should be no XProtect scan or further checks, and the app should proceed to launch normally.

App Store apps are signed using an Apple Mac OS Application Signing certificate, relying on the intermediate Apple Worldwide Developer Relations Certification Authority, and back to the Apple Root CA. While the latter should expire on 9 February 2035, both the signing certificate and its intermediate have shorter lifetimes:

  • Older App Store apps should have an intermediate expiry of 7 February 2023, as explained here by Apple, and more recent apps that is likely to be 10 December 2030.
  • Older App Store apps are likely to have been signed with a certificate that expired on 7 February 2023, while more recent apps are likely to expire on 12 August 2026.

None of this should affect Intel Macs, although we’re likely to see increasing numbers of App Store apps that are Arm-only and won’t run on Intel systems. However, this will become more complicated with the retirement of Rosetta 2 next year.

Apple has stated its intention that full Rosetta translation support will end with macOS 27, although it intends to retain “a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles” beyond that. In practice, that means most x86 apps and command tools will stop working in macOS 28, in the autumn/fall of 2027. Apple silicon Macs will therefore continue to run Intel-only App Store apps until they are upgraded to macOS 28.

Their fallback then is to run Intel-only code in a VM running macOS 27 or earlier, as that will still be able to provide full Rosetta 2 support. Given the performance of code translated by Rosetta, and that of VMs, that’s far better than might appear. There’s one remaining problem with that, though: some App Store apps can’t run in virtualisation, as it doesn’t support connections to the App Store. Some can, and as a matter of interest the five that I used in these tests all do, although not always reliably, but others can’t. I don’t know of any reliable way of testing this other than trying it out.

Summary

  • macOS security checks ignore the expiry of certificates (including intermediates) used to sign App Store apps, and allow the app to run regardless.
  • Many App Store apps have expired certificates.
  • This shouldn’t affect Intel Macs in the future.
  • Running Intel-only App Store apps is unlikely to be supported from macOS 28 onwards, except for a limited range of unmaintained gaming titles.
  • Some Intel-only App Store apps might not run in a VM with Rosetta 2 support either.

❌