应用转手，Apple小企业计划的年度收益仍计入双方

摘要

卖掉一款应用，通常意味着以后不再经营它。Apple的小企业计划还会追问一句：今年这款应用赚过多少钱？产品已经过桥，收益记录仍在桥两端点名。对卖家，出售未必释放当年的资格空间；对买家，接手的也不只是一块代码。

这条规则摆在Apple计划说明里。应用一旦转让，该日历年的收益会归集到所有发起或接受转让的账户，用于判断能否参加计划。一款应用年内多次转手，协议还会把每个参与方都算进去。买卖双方签收的按钮，兼任不了历史删除键。

计划向符合条件并获准参加的开发者，对适用的付费应用和应用内购买收取15%的优惠佣金。宣传里的百万美元门槛有一个严格口径：收益是销售额扣除Apple佣金及部分税款、调整后的数额。它既不是用户付出的全部价款，也不是工作室利润，更不是收购应用时谈下的成交价。

资格核算会合并关联开发者账户，查看上一日历年内的十二个财政月份，并关注本年收益。参与者本年超过100万美元门槛，适用条件下的未来销售会在当年余下时间按标准佣金计算。以后某年回到门槛以内，可以涉及再下一年的重新申请资格。小团队的身份和获批参加计划之间，隔着一套实际的申请与核算。

这让报价单上的一个小百分号，变成组合资产的问题。同一款应用，放在现主人账户里享有的条件，搬到买家账户里可能已经不同。买家原有应用的收益、关联账户和接手应用的年度记录都参与计算。将卖家的历史毛利率贴进收购模型，等于把别人的账户条件当成了自己的财产。

开发者协议的附表2把关联账户说得很具体：拥有、控制，或者被另一个账户拥有、控制。持股超过50%是一种判断依据，拥有最终决策权也是。仅仅多办一张公司执照，未必多出一个独立门槛。协议还禁止通过不当使用多个账户获益。

转让参与方的规则走另一条路。买卖一款应用，不会自动把两家公司变成控制关系；双方仍会因这次转让，各自把该应用的年度收益纳入资格计算。平台既查“这是谁控制的生意”，也记“这项生意今年经过谁的手”。把两者混在一起，就会误判一宗普通资产交易的经济结果。

卖家的算盘也有必要重新拨。经营权交出去了，该年度的收益归集仍可能影响他保留的其他应用。出售能够换来现金、卸下运营任务，但优惠计划的年历不会配合交易文件翻页。账面上少了一款产品，资格计算未必同步瘦身。

Apple的应用转让指南允许符合转让条件的应用在交接期间继续供下载，保留评分、评论和Bundle ID，用户继续接收更新。这是应用交易真正有价值的一面：买家可以接住积累下来的产品信誉。

财务报表的边界不同。卖家仍能访问转让前交易的销售与付款信息，之后的交易信息不再向他开放；接收方拿到的是转让后交易的付款与销售资料。App Analytics另有自己的历史访问规则。产品连续、报表分段、资格跨着年度归集，三件事在同一交易里同时发生。

由此产生的实际问题，是谁提供计算所需的历史，双方按什么口径核对。应用在商店里成功换名，不能代替交易文件中该有的数据交接。Apple还明确，实际代码和构建资料由转出方直接交给接收方。商店交接了登记位置，运营交接仍有人要干。

这也解释了为什么“过去按15%算，所以今后也按15%算”是一句昂贵的省事话。产品的评分可以原样留下，账户的资格要重新放进买家的组合里。评估维护预算、人员安排和收购回本期，都得先扣掉适用于自己的分销成本。

要给一宗具体交易算出影响，还缺应用逐月美元收益、税款与调整、双方其他账户收益、已接受条款和转让时间。拿齐这些资料，价格讨论才有可用的利润基础。

平台最耐用的权力，有时藏在一个普通定义里。Apple允许产品流动，同时保留了决定谁算“小企业”的计算方式。于是买家购买的是一款可延续的应用，佣金优惠却仍要接受平台按账户与年历进行的核算。

一份好的出售合同，应该让双方明白交走了什么、留下了什么。应用已经搬家，收益还在原门槛上留下脚印。忘了看那道门槛，才会把别人的优惠买成自己的成本。