历时 5 年的「苹果税」诉讼，迎来了第一个大结局。

负责该案的美国法官 Yvonne Gonzalez Rogers 裁定，即日起，苹果不得再对 App 外的购买行为收取费用，并禁止该公司限制 App 开发人员引导用户进行 App 外购买。

这个在五一前夕作出的裁决，不仅只是起诉方 Epic Games 的胜利，也是更多 App 开发劳动者的胜利。

苹果税，不存在了？

具体来说，Rogers 在裁决中对苹果的禁令包括：

• 对消费者在 App 之外的购买行为征收「任何佣金或费用」
• 限制开发者对 App 外购买链接的设置，以及链接的样式、格式
• 阻止或限制 App 外购的按钮，以及对外购的鼓励
• 除了向用户发送一条中性消息，告知他们即将前往第三方网站之外，不能干扰消费者离开 App 的选择

也就是说，以后的 App 开发者，可以正大光明在 App 内购的页面，为消费者提供一个不是 App Store 的支付渠道，并且苹果无权从这个渠道中进行抽成。

这个裁决将意味着苹果失去大部分应用内购的控制权，会有越来越多开发者和用户选择不走 App Store 的渠道进行交易。

众所周知，在 iPhone/iPad 上下载的应用，如果想要充值内购，就必须走 App Store 的支付方式，苹果还会从中抽成 30% 的佣金，这就是「苹果税」，也是为什么 iPhone 用户会发现自己氪金或买会员比 Android 小伙伴更贵的原因。

因此，App 开发者会在不被苹果察觉的情况下，想办法提供一些其他的氪金渠道。一些做直播的主播也会提醒用户，不要直接在平台上充值打赏，并提供一些能够直接走微信支付购买道具的公众号。有不少游戏也能在微信官方公众号处氪金，购买的道具再发放回游戏中。

Epic 争取的，不是废除这个「苹果税」，而是能够在自家的 App，放上一个直接给自己打钱的渠道，没有苹果从中大额抽成，不管是开发者还是用户的利益都能最大化。

2021 年，也就是 Epic 揭竿而起起诉苹果一年后，法官 Rogers 驳回了 Epic 九条请求，但同意了要求苹果允许 App 开发者在应用内设置链接，引导用户到第三方渠道进行支付这一条。

虽然法官总体站在苹果这边，但苹果并没有见好就收，不仅提出上诉，还对此提出了全新的「苹果税」政策：如果应用内购要走 App Store 之外的支付渠道，那也要收取 27% 的佣金。

而应用开发者本身也要向第三方渠道支付一定的交易费用，这使得他们的总成本超过了原本 30% 的「苹果税」，实际上让第三方支付的方式并不可用。

这种做法不仅激怒了 Epic 和 Spotify 这些「反苹果税」斗士，也让法官 Rogers 感到不满，促成了这次最新裁决：

（苹果）认为法院会容忍这种不服从行为，这是一个严重的错误估计。

Rogers 也将这个案件提交给了美国检察官审查，以确定是否可能对苹果提起刑事藐视法庭诉讼，她还表示苹果财务副总裁对这个事件作了假证，苹果公司没有纠正这一点，因此也将被视为向法庭提供了谎言和虚假陈述。

值得一提的是，Rogers 指出苹果 App Store 高管 Phil Schiller 曾主张公司遵守法院禁令，但 CEO 蒂姆·库克却一意孤行，选择站在法院的对立面。

天下苦苹果税久矣

2020 年，Epic 游戏《堡垒之夜》上线了一个促销活动，提供了两个支付方式：

• Apple App Store：9.99 美元
• Epic 直接支付：7.99 美元

这种挑衅行为明显是向苹果的直接宣战，苹果动作也很快，当天就从 App Store 上下架了《堡垒之夜》。Epic 就一纸诉状将苹果告上法庭，理由是苹果的垄断行为。

将近 5 年的诉讼由此展开，Epic 控告苹果非法垄断 iOS 应用分发行为，拒绝第三方商店，垄断付费方式创收，等等等等。

而 2021 年法官 Yvonne Gonzalez Rogers 作出了上文提到的判决，要求苹果在应用内开放第三方支付方式，直到本周，Rogers 给出了进一步的裁决，明确禁止了苹果的小动作。

这个判决结果象征着 Epic 的胜利，Epic 表示将在下周重新上架《堡垒之夜》。

Epic 也提出了自己的和解条件：如果苹果在全球范围内都执行法院的免苹果税框架，那么《堡垒之夜》将重返全球 App Store，Epic 也将放弃当前和未来关于这个主题的诉讼。

不止有 Epic 一家看不惯苹果税，音乐流媒体巨头 Spotify 也通过欧盟委员会持续向苹果施压，要求苹果允许他们在 App 内展示定价信息，以及第三方支付链接。苹果对此也是采取「拖字诀」，因而不断被欧盟罚款。

除了抽成比例高，苹果还「锱铢必较」，不放过任何一个能征收苹果税的可能性。

去年，媒体报道微信与苹果在小程序游戏的分成上出现分歧，后者希望微信能强硬要求这些迷你游戏的开发商只能走 App Store 支付，甚至还因此催生出「iPhone 16 不支持微信」的离谱谣言。

虽然 Epic 和 Spotify 也是主要为了自己的利益才敢跳出来叫板苹果，但对于规则的质疑和挑战，无疑也有利于那些规模更小的开发者，让他们能从辛辛苦苦推出的 App 中获得更高的收入。

苹果选择和法院以及欧盟死磕到底，无非就是因为苹果税带来的巨额收入。根据第三方调研机构 Sensor Tower 统计，2023 年「苹果税」全球收入高达 223.4 亿美元，外界普遍认为 App Store 的佣金，是苹果最赚钱的业务之一。

针对这个最新的判决结果，苹果表示「强烈反对」，接下来会遵守法律的命令并提起上诉。

不管是在头部产品 iPhone 的销量持续收缩这个大背景，还是今年以来关税波动和 AI 跳票这些小事件，苹果今年遭遇的质疑和挑战不断升级，而新的裁决再一次波及到了苹果的一个收入支柱。

苹果税不会消失

第三方支付被扶正，但 App Store 支付以及苹果税不会就此被取代。

走第三方支付，不代表用户打的钱，每一分一毫都能到开发者的账上。原因在上面也提到了，不走 App Store 也要给第三方渠道服务费，只是比例远比 App Store 要低，大概在 5%-15% 左右。

即使是 Epic 自己的 Epic Game Store，本身也会对上架的游戏抽成 12%。

强迫苹果开放第三方渠道，更多是让 App Store 支付从仅此一家的垄断地位，被迫参与到竞争之中，从而倒逼苹果减少抽成比例，以和第三方支付竞争。

而当「苹果税」和其他平台的费率来到一个水平，内购价格都一致，那用户还是会更青睐选择走 App Store 支付，毕竟它无需跳转，更方便也更安全。

本次作出的判决，主要都是针对苹果违抗的「开放第三方支付渠道」命令，其他依旧维持 2021 年的判决，也就是法官 Rogers 总体还是站在苹果这一边，认为 App Store 这个模式有其合理性，也不打算让苹果在美国跟欧盟一样，完全拆除围墙搞开放。

「苹果税」这个事情，本身其实不是对购买行为本身收费，而是从 App Store 的知识产权中获得利益，苹果花了大力气打造 App Store 生态，理应从中获得回报，而抽成则是最简单直接的方式，法官认可了这个说法。

去年，国内有消费者以苹果税过高为由起诉苹果，要求苹果开放应用内购的第三方支付方式，最终被驳回，官方虽然认定苹果有市场的支配地位，但认为 App Store 平台经营体系庞大，不能认定「苹果税」收取过高。

那么，在新的判决发出之后，苹果会在全世界范围内开放应用第三方内购渠道吗？

我持悲观的态度，至少他们不会在短期内主动全面开放，原因也很简单，这块肉太肥了，苹果不可能轻易放手。

事实上，App Store 在每个国家和地区的规则都不尽相同，如果没有被当地勒令调整，那就是最标准的「大企业 30%，小企业 15%，不允许第三方支付」规则，这也是我们目前的 App Store 政策。

但欧盟、美国相应的诉讼接连取得成功，无疑是开了一个好头，为更多地区的企业和消费者带来参考，采取法律手段逼迫苹果整改。

就在昨天判决结果出来后，今天苹果已经继续发邮件通知App Store开发者，表示美区已经解除了第三方支付的限制 –结果正在向更好的方向发展。

苹果税不会消失，但我们有希望看到它变得更加合理。而最终受益的，是开发 App 的劳动者，更是用户。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

Entitlements are settings baked into an app’s signature that enable it to do things that otherwise wouldn’t be allowed. Many let App Store apps do things their sandbox wouldn’t normally permit. Others give access to features that are controlled by privacy protection, so may be used by apps that aren’t sandboxed. A few enable apps specially approved by Apple to use features in macOS that aren’t generally available, such as working with APFS snapshots.

One way to run third-party apps in relative security is to confine them to a tightly restricted environment, a sandbox. That denies them the ability to access storage or other resources outside those dedicated to it in its sandbox. That’s too restrictive for the great majority of apps, which need to be able to open and save documents to folders such as ~/Documents, so entitlements specify which sandbox restrictions they’re allowed to break. In the case of opening and saving documents outside the sandbox, the entitlement is named com.apple.security.files.user-selected.read-write, and gives that app read and write access to files the user has selected in a standard macOS Open or Save dialog. Apple requires that all apps distributed through its App Store run in their own sandbox, so they all claim entitlements to be able to work beyond that.

Sandboxed apps all have their own entitlement to their sandbox, com.apple.security.app-sandbox, which isn’t used by apps that are notarized but not sandboxed. Whether sandboxed or not, an app might need access to the Mac’s camera, and for that it will need an entitlement named com.apple.security.device.camera.

Thus, entitlements fall into groups:

• Those that can be used by any app that wants access to controlled features, depending on whether it’s sandboxed or not.
• Those that give access to macOS features that have to be approved by Apple.
• Those that are private to Apple’s own apps and can’t be used by third-parties.

Viewing entitlements

The Finder and other macOS utilities don’t reveal whether an app runs in a sandbox, nor list its entitlements. For that you’ll need a third-party tool such as Mothers Ruin’s Apparency.

Apparency’s Entitlements pane lists all those baked into that app’s signature. My own free Taccy also lists entitlements, but for this purpose Apparency is the better tool by far.

Apps that aren’t sandboxed, only hardened and notarized, will only have entitlements if they need to access privacy-protected features, or use restricted features in macOS. In many cases, that means they will have neither entitlements nor a provisioning profile.

com.apple.security

These give an app access to files and features that are restricted, either by the sandbox, or by privacy protection.

Sandbox controls

These are options that extend an app’s abilities beyond the sandbox, starting with the entitlement that sets the sandbox in the first place. They aren’t used by apps provided outside the App Store that are only notarized and not sandboxed. Apple provides fuller details of the sandbox here.

Examples include:

• com.apple.security.app-sandbox runs the app in a sandbox, and is standard for all sandboxed apps
• com.apple.security.files.user-selected.read-write gives read and write access to files the user has selected in a standard macOS Open or Save dialog
• com.apple.security.files.bookmarks.app-scope gives access to security-scoped bookmarks with app scope
• com.apple.security.files.bookmarks.document-scope gives access to security-scoped bookmarks with document scope
• com.apple.security.network.client allows it to open outgoing network connections
• com.apple.security.print allows it to print.

Privacy controls

These give access to information, devices and features that are controlled by the privacy features in macOS, enforced either by Location Services or by TCC. These are used by any third-party app, whether supplied through the App Store or not, and include:

• com.apple.security.personal-information.addressbook gives access to the content of the address book
• com.apple.security.personal-information.location gives access to location data from Location Services
• com.apple.security.device.camera gives access to the camera
• com.apple.security.device.microphone gives access to the microphone
• com.apple.security.automation.apple-events enables automation using AppleEvents.

These normally have a corresponding list in Privacy & Security settings.

com.apple.developer

These entitlements can only be granted by Apple, and control access to macOS features that aren’t generally available. Among the most common are:

• com.apple.developer.endpoint-security.client enables it to monitor system events for potentially malicious activity using Endpoint Security
• com.apple.developer.persistent-content-capture is required for a Virtual Network Computing (VNC) app to have persistent access to screen capture
• com.apple.developer.driverkit gives an extension permission to run as a user-space driver
• com.apple.developer.vfs.snapshot gives access to snapshot features
• com.apple.vm.networking allows virtual network interfaces without their having to escalate privileges to the root user, typically in bridged networking.

com.apple.private

These are private to Apple’s own apps, and encompass many other com.apple entitlements that aren’t documented for third-party developers. Examples include:

• com.apple.private.applemediaservices
• com.apple.private.dmd.policy
• com.apple.private.octagon
• com.apple.authkit.client.private
• com.apple.duet.activityscheduler.allow.

Some appear self-explanatory, others are opaque.

Command tools and standalone executables

Although Mach-O binaries such as command tools and daemons can be hardened and signed, thus can be notarized, they can’t have a provisioning profile embedded, so can’t have entitlements. Apple recommends working around this by wrapping them in an app-like structure, as explained here.

Entitlements for access to features controlled by privacy protection rely instead on the attribution chain to determine whether they’re entitled. Thus a command tool called by an app isn’t expected to have the entitlement, but the app calling that binary is.

Stripping signatures

Because entitlements are baked into the signature, if you were to strip the signature from an app, that would remove all its entitlements. For a sandboxed app, that might not be fatal, but for most other types of entitlement, that could render the app non-functional. Resigning the app with an ad hoc signature wouldn’t help either.

References

Apple’s Entitlements documentation
Tech Note 3125 on provisioning profiles for code signatures
If you can’t find an entitlement in any of those lists, try looking in Jonathan Levin’s database of all known entitlements for iOS and macOS, which is as comprehensive as we’re likely to get.