iPhone如何删掉健康应用,iphone删掉的应用还会有图标

#本文为人人都是产品经理《原创激励计划》出品。

近来，苹果一则关于“将下架长期不更新应用”的公告引起了不少业内人士关注。不少人都对此项措施表示不解，但其实透过此次公告，我们可以看到苹果在协调自身软硬件生态上的企图。具体如何解读，不妨看看作者的分析。

一、软件“强制更新”

4月29日，苹果在开发者网站正式发布公告，对于在过去三年内从未更新且未达到最低下载量的APP，苹果会以电子邮件的方式告知开发者其APP已被识别并可能从苹果App Store中移除。开发者需要在限期内及时更新他们的APP，限期时长从之前引起热议的30天延长至90天。

虽然可能会误伤一些无需频繁更新、下载量较少却极其实用的小众APP，但从官方在APP可发现性、安全及隐私和用户体验三个方面的解释而言，这样的改善计划又是可以理解的。

毕竟只有保证高质量和出色用户体验的应用环境，才能持续地吸引更多的用户到苹果的产品生态中，推动整个生态的发展。况且，一些既不更新又没有下载量的僵尸应用，既占用了App Store的位置，又需要耗费平台的资源进行维护。

二、硬件“性能过程”

为何苹果要在这个时间推出此项规定？是什么推动了此项决策呢？回答这个问题，还得从苹果的手机业务说起。

软件生态需要“强制更新”，苹果的硬件产品却是实打实的“性能过剩”。

最新款的iPhone 13 搭载的苹果A15芯片，采用5nm制成工艺，集成了150亿颗晶体管，较上一代A14的性能显著提升。以打破摩尔定律的速度不断提升的硬件性能加上以流畅性著称的iOS系统，使苹果手机的使用寿命越来越长久。时至今日，2015年发布的搭载A9处理器的iPhone 6s依然可以流畅使用。

与性能方面的不断升级相比，iPhone在功能层面却并没有出现iPhone 4一样革命性的创新，这也使得老用户升级新一代iPhone的意愿越来越低。

在营收上，自2021年Q2以来iPhone的营收增速一直处于下滑趋势。近期苹果发布的2022年Q2财报显示，iPhone 单季营收为505.70亿美元，相比去年同期的497.38亿美元，营收增速下降到了5.5%。

常年贡献一半以上营收的iPhone增速放缓，而苹果的服务类业务在2022年Q2收入飙升至198.21亿美元，同比增长了17.3%，连续五个季度创下新高。该季度中服务类业务的毛利率提升到了72.6%。服务类业务是苹果常年以来毛利率最高的业务，App Store正是服务类业务收入的大头。

作为硬件业务核心的iPhone在经历了降价打入中端手机市场之后再次显露疲态，苹果发力一直保持着良好增长势头和超高毛利率的服务类业务也就比较容易理解了。在硬件层面只能依靠性能的不断提升来升级产品的情况下，软件服务的创新或许能够为苹果吸引更多用户的青睐。

下架在过去三年内从未更新且未达到最低下载量的APP，使App Store中的应用整体适配新的屏幕尺寸和操作系统，提升App Store整体的用户体验，可能仅仅是苹果在服务类业务发力的一个开始。

同时，驱使APP整体向更高版本的操作系统迁移，也能变向地促使想要获取应用更新的低版本的硬件用户升级购买新的机型，进而推动苹果硬件产品的销量。

例如在最新的iOS 15的升级机型清单中，搭载了A9芯片的iPhone 6s就不在升级范围之中。尽管在硬件性能上iPhone 6s完全可以支持用户流畅的使用，但却无法更新和尝试新的iOS系统的新特性，也会有越来越多APP的最新版本无法安装。

三、用户已不愿更新APP

然而，这一招真的能刺激老用户升级硬件吗？

官方公告之前，“苹果商店将下架长期不更新应用程序”的话题就登上了微博热搜。意料之外的是，大部分的评论不是来自于APP的开发者，而是来自于手机用户：

• “能不能把一些长期更新但还是不好用的应用下架……”
• “有些APP一直更新，还越做越烂”
• “部分APP更新频率太高了，关键是更新完也不知道更新了啥，新功能没有，旧BUG不改”
• ……

这些吐槽也很容易总结：APP频繁更新，越更新越不好用，怎么App Store还要强制要求更新？

大部分用户非但不认为App Store这样做会提升用户体验，而且对APP的频繁更新表达了不满。为什么产品经理和开发工程师费劲心思对APP进行的升级，用户却不买账甚至是厌恶呢？

首先，理论上来说，APP的更新一般会有如下四个原因：

• 第一，已有核心功能优化，即对已上线的核心功能不断优化用户体验。
• 第二，系统BUG修复，修复使用过程中出现的系统漏洞。
• 第三，增加新功能。新功能主要有三个来源途径，一是当前用户提出的新的需求，二是产品经理基于调研和分析设计出的功能，三是公司业务发展的需要而新增的功能。
• 第四，删除经过线上验证没有使用价值的功能。

表面上来看，以上这四点的初衷都是为了优化APP的用户体验。而回到现实，如今我们几乎每个人的生活都离不开手机，厌恶APP频繁更新的原因还是很容易总结，而且是可以引起共鸣的。

1. 更新频繁且运行不稳定

笔者目前使用的是苹果的手机，强迫症的我一定会将各类消息的提醒的红点消除掉，但是对于App Store的更新提醒却无能为力。在关掉自动更新的情况下，全部更新之后再过一周，基本上又会提醒有一半的APP需要更新，已经有些麻木了。

而且，虽然新版本会经过许多轮测试，但与熟练使用的老版本相比，稳定性上多少会有折扣，在使用的过程中总会遇到这样或者那样的BUG。在前后版本没有特别吸引用户的新功能增加的情况下，用户也更愿意使用老的版本而不进行升级。

这其实是个“狼来了”的故事，频繁地更新版本导致了用户的疲劳，用户都认为新版本只是为了更新而更新，而对新版本无动于衷，导致真正的新功能也长期得不到使用和反馈。

2. 新的版本广告含量猛增

对于大多数APP，广告收入是最大的收入来源，甚至对于Google、Facebook、字节跳动这样的互联网巨头也不例外。烧钱开发和推广、积累用户流量再到广告变现，成为了移动互联网最为常见的商业模式。而广告投放后还能够留得住用户，也成为了一款APP是否能够持续运营的关键。

对于如今的用户而言，似乎也都有使用一款APP从“喜欢使用”到“处处是广告”再到“寻找替代品”的心理预期。只要当前的功能能够满足使用，往往不愿意主动升级APP，害怕盲盒里开出“广告”这两个字。

比如，笔者一直很喜欢用喜马拉雅听一些音频节目，而最近一次更新之后，每新打开一个音频节目都有30秒左右的音频广告，需要手动点击关闭或者开会员免广告。虽然很理解公司运营需要收入支撑，但看到音频APP也逃不过添加广告，还是有些唏嘘。

3. 在“增长魔咒”中忘记初心

另一个主要的原因，是公司无法摆脱“增长魔咒”。

在核心功能相对成熟，沉淀了一部分用户之后，迫于产品和运营增长的需要，APP中总会长出用户交流、小游戏、勋章之类的功能。或者因为公司成长需要拓展新的业务，现有APP已经有了现成的用户流量，就直接将新功能整合到现有APP中，APP变成了“生态平台”的入口。

站在用户视角，APP升级之后甚至都无法快速找到原来喜欢使用的功能，愿意退回使用老版本，都是比较仁慈的做法了。

举个例子，如果不加提示，相信许多人是看不出来这是“饿了么”APP的主页。也许相比让用户更方便地点外卖，展示自己的“无所不能”会更有成就感。

4. 界面和操作需要重新适应

用户界面升级也是APP常喜欢做的更新。特别在APP上线的早期，由于业务和需求都在不断地迭代，用户操作界面不断优化是比较平常的。根据节日、最近的流行元素、各种运营活动等原因，一些APP的界面设计和功能入口也会经常调整。

但界面的升级给用户带来的更多是负担，而不是惊喜。每一次界面和交互的调整，用户都需要去重新学习界面操作，相比而言用户可能更愿意退回熟悉的旧版使用。一些粘性弱的APP甚至可能由于频繁的界面调整直接流失大量的用户。

下图是笔者截图的知乎官方账号发布的知乎8.0改版升级的文章的高赞评论。即便像知乎里这样乐于求知的用户，也依旧不喜欢探索新版本操作的“奥秘”。

5. 要获取过多的资源和权限

APP功能的不断升级，占用硬件的体积和内存量也会水涨船高，最终导致硬件平台和系统的运行也越来越慢。很多手机已经使用很久但暂时没有升级设备的用户，在没有特别想要使用新版本功能的情况下，都会选择不升级任何APP的版本，基本上也不会影响使用体验。

近些年用户数据隐私防范意识也不断提高。APP升级需要的扩展用户数据的访问权限，也会导致用户的反感而不愿意升级。

特别是一些APP获取的权限明显超出APP功能所需，比如P图软件需要获取手机通讯录权限、交通卡重置软件需要获取用户相册的权限等等。更有一些不能获取到全部需要的权限的APP，整个功能都不允许用户继续使用，可谓是相当“自信”。

笔者一直很喜欢用一款日常习惯打卡的APP“小日常”，最近的一次更新添加了“打卡地图”的功能，需要获取手机的位置权限，被我果断拒绝。

相比于“打卡地图”这样的辅助功能，更为重要的还是自己位置数据的隐私性。而且笔者之所以付费升级为永久会员，主要是由于APP日常习惯打卡的操作体验简洁流畅，现在反而担心它也会变得臃肿起来。

四、如何能够破局？

没有硬件功能上的创新，也没有促使用户愿意升级硬件设备的软件生态，单靠硬件性能的提升，已经不足吸引如今的用户。

如果自身生态中软硬件长期无法相互推进发展，苹果也只能陷入在一片红海中抢占其他品牌厂商的用户来保持自己的增长。笔者认为，或许苹果可以从以下三个方向尝试破局。

1. 增大单个应用体积限制

如果移动端App Store增大应用体积的限制，或许能迎来一些转机。

手机和平板电脑无论是存储空间还是处理能力都在逐年增强，性能已经远超目前移动端应用运行的需要，但无论iOS还是Android还都限制单个应用的体积不能超过4GB。

2015年，苹果的App Store将支持的应用大小的上限从2GB提高至4GB，之后至今一直未做调整。单个应用体积大小的限制保证了操作系统和硬件的流畅运行，也在一定程度上限制了整个移动端软件生态的想象空间。

首先，增大应用体积的限制。也不必APP的体积都盲目增大，毕竟更小的体积用户也更容易下载安装，功能与体积大小不匹配也会引起用户的吐槽，其实目前对于绝大部分APP来说根本用不到4GB的大小。

其次，许多因为大小限制而无法登录端的游戏可以尝试延伸到移动端。

在PC端，现在的游戏超过100GB大小的已经不稀奇。体积大也带来了与之相匹配的高清无损的画质和身临其境的体验，玩家也愿意为此买单。而且愿意升级硬件设备，2021年游戏显卡甚至一度出现了价格炒作的现象。

Steam大火的《艾尔登法环》的游戏截图

最后，相信大型游戏也不会是增大APP大小限制后的唯一答案。现有的APP可以在功能和画质上进一步增强。结合移动端的使用场景又可能会孕育出更多现象级的APP。

APP具有足够的吸引力，升级硬件也能够获得更好的用户体验，软硬件才能真正地相互推动发展。

2. 降低APP收入分成比例

总所周知，苹果会对App Store内应用收取15%-30%的抽成，这也是苹果达到70%左右毛利率的服务类收入的重要来源。

尽管安卓官方的Google Play商店也收取抽成费用，但是安卓系统更为开放，用户可以通过其他的应用商店和其他各种方式正常地安装应用，而iPhone只能通过App Store下载安装。

如此高比例的收入抽成，让苹果生态上的开发者负担了更多的成本，在App Store中开发付费类APP的意愿降低，更多地采用广告变现的方式获取收入，或者干脆以降低用户体验为代价尝试各种外链购买的方式。这些做法反向也损害了苹果手机用户的使用体验。

此外，一些公司选择将这部分费用转嫁到用户身上，同样的服务对于苹果手机的用户收取更高的费用，以摊平苹果抽成的成本，也会在一定程度上造成苹果手机用户的流失。

降低抽成比例能够激苹果生态中开发者们的积极性，减少开发者对于付费应用模式的顾虑。再叠加App Store构建的完整的应用购买环境，相信可以吸引更多的开发者创造更多苹果生态中独有的付费应用，提高整个苹果生态的吸引力。

事实上，多个国家都已经对苹果此项收成展开反垄断调查，马斯克也在推特上评论称苹果其实是在对整个互联网收取30%的“税”，比合理的比例高了十倍。

然而，作为苹果精心构建的生态中最为重要的一环和毛利率最高的重要收入来源之一，主动放弃这块肥肉来开始自我革命，可谓难上加难。

3. 拓展新的移动硬件平台

即便在存储空间和处理性能上，手机和电脑已经无限接近，但是考虑到手机屏幕大小和输入方式的限制，很多场景还是在PC端操作更方便，比如日常的文字输入、界面设计等工作。

虽然移动端的硬件设备也在不断地尝试着突破这些限制，平板电脑可以配置各式各样的便携式键盘，手机的显示屏越做越大，更有折叠屏手机试图兼容便携性和更大的屏幕。但是，对于移动端的硬件来说，便携是基础，在输入硬件和显示大小上慢慢扩展为电脑的形态，显然不是未来的发展方向。探索能够兼容方便携带、方便输入和感官体验的硬件设备，或许才是解决这一难题的最终路径。

这条赛道上，一直在硬件设备上希望有所突破的谷歌在2012年就开始投入研究以增强现实技术（AR）为核心的谷歌眼镜。用户可以通过查看镜片投射出的较大的虚拟屏幕和语音控制，进行拍照、查看邮件等操作。但由于续航和安全等方面的原因，谷歌在2015年暂停了谷歌眼镜的生产。

2021年，随着“元宇宙”概念的爆火，虚拟现实（VR）设备也开始变得火热。其中，Facebook直接更名为Meta，孤注一掷地开启了“元宇宙”计划。旗下Oculus在VR头显设备已经占据了80%的市场份额，Meta也希望能够借助“元宇宙”构建自身软硬件的生态闭环。

与Meta相同，同样缺少自身硬件平台和系统的字节跳动也在2021年收购了VR硬件产商Pico进军此赛道，并在2022年开始就展开了疯狂的营销。

各大互联网公司的纷纷布局，再加上“元宇宙”带来的无限畅想，VR/AR设备也最有希望成为下一代互联网硬件基础设施平台。无论最终是AR/VR设备，还是手机的自我进化或其他新的硬件设备最终突围，硬件平台演进的脚步始终不会停下来。

作为移动联网孕育出的科技巨头，苹果能否不像微软错过移动互联网那样错过下一个互联网生态，都让人拭目以待。

#专栏作家#

吴之猫，微信公众号：有不知，人人都是产品经理专栏作家。健康管理小硕，医疗健康产品汪+文艺猫。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

本文为人人都是产品经理《原创激励计划》出品。

题图来自 Unsplash，基于 CC0 协议