676个程序员暴怒：你的App不过是张网页
2026年7月9日，英国程序员Dan Q写了一篇文章，标题就带着火药味：《你的”App”本来可以是个网页（所以我帮你修好了）》。这篇文章在Hacker News上引发了676位程序员的激烈讨论，420条评论，把App Store经济和开放Web之间那层窗户纸捅了个对穿。
事情的起因很生活化。Dan的孩子要去迪士尼乐园演出，旅行公司要求家长必须安装一个叫”Travelbound”的手机App才能查看行程安排。Dan查了一下这个App的大小——安装包43MB，装完后膨胀到124MB。作为一个十几年的老程序员，他觉得这太离谱了：我就想看个时间表而已，为什么要下载一个比超级马里奥还大的App？
他做了件程序员最擅长的事：逆向工程。
一个124MB的App里面到底有什么
▲ 这就是那个124MB的Travelbound App，功能是显示一堆文字、图片和PDF链接。来源：Dan Q个人博客。
Dan用抓包工具拦截了这个App的网络流量，发现了一个令人哭笑不得的真相：这个App做的唯一一件事，就是通过用户名和密码拼接一个网址，从服务器取回一堆数据，然后把数据显示在屏幕上。
具体来说，这个App背后的逻辑是这样的：
https://travelbound.api.vamoos.com/api/itineraries/{用户名}-{密码}服务器返回的是一大段JSON格式的数据——里面有行程列表、住宿信息、PDF下载链接、配套图片。而这些内容，本身就被包装成了HTML格式。换句话说，这个App的服务器端已经在生产网页了，只不过它选择把网页塞进一个124MB的壳子里才让你看。
▲ 截获的服务器返回数据，可以看到行程信息已经以HTML格式存在。来源：Dan Q个人博客。
那这124MB到底装了些什么，让一个本质上是”网页查看器”的东西变得这么臃肿？Dan发现，这个App比网页多出的功能只有两个：
- 追踪你的Google账号，把使用数据回传给旅行公司
- 推送广告（官方措辞叫”旅行灵感”），诱导你购买更多行程
Dan的说法更直接：这两样东西是”反功能”——对用户有百害而无一利。
从124MB到0.05MB：一个网页就够了
Dan花了半天时间，写了一段小小的Ruby脚本，定期从服务器抓取最新数据，自动生成一个纯网页版本。效果怎样？
- App版：124MB（包含追踪和广告）
- 网页版：0.05MB的HTML页面，外加一些可选的图片（35MB，但你可以选择不下）
网页版用密码保护，和原App用同一套账号。它没有花哨的界面，但可以复制粘贴、可以打印、可以保存到手机、可以在任何设备上打开——而这些恰恰是原App做不到的。
▲ Dan自己制作的网页版，去掉了广告和追踪，保留所有核心信息。来源：Dan Q个人博客。
Dan最后发出了一句灵魂拷问：
“有些App确实是需要做成App的。Travelbound不属于其中任何一个。我无法理解我们是怎么走到今天这一步的——软件公司宁可让自己的生活更困难（也更贵：上架App Store可不便宜！），就为了把HTML内容推送给更少的人、带着更少的功能。“
为什么会走到这一步？苹果经济学
Dan的困惑，背后藏着一个更大的问题：为什么明明网页能解决的事，开发者非要打包成App？
在Hacker News的676人讨论中，最高赞的一条评论直指核心——苹果和谷歌花费了数十亿美元，重塑了普通人的心智模型，让人们相信”用手机做事=使用App”。
想想看，当一个普通人拿到新手机，他们在主屏幕上看到的是什么？是一排排App图标。他们要找东西怎么办？打开”应用商店”。他们想用某个服务怎么办？“有没有App？”
这种”App即一切”的认知不是天然形成的。它是过去十五年、两大科技巨头用真金白银砸出来的结果。
而这背后的驱动力，是钱——确切地说，是那笔出名的”苹果税”。
苹果税：30%的抽成经济学
任何通过苹果App Store销售的应用或数字内容，苹果都要抽取15%到30%的佣金。2024年，仅App Store一项就为苹果创造了超过850亿美元的收入（根据苹果官方披露以及与Epic Games诉讼中公开的财务数据推算）。这在整个互联网行业中，几乎找不到第二个这么赚钱的”收费站”。
而网页呢？网页是开放的。任何人发布一个网页，不需要付钱给苹果，不需要通过苹果的审核，用户直接用浏览器就能打开。如果一个服务以网页形式存在，苹果就拿不到一分钱。
这就解释了为什么苹果在iOS系统上，有意无意地让网页App变得”不好用”：
- 所有iPhone上的浏览器，必须使用苹果自己的WebKit内核——即使是Chrome、Firefox，在iPhone上也只是一个披着不同皮肤的Safari。2026年6月，微软工程师发布了一份基准测试报告，显示如果允许Chromium内核在iOS上运行，浏览器性能可以比Safari高出28.6%。
- 网页App（PWA）在iOS上无法使用Face ID、不能后台同步数据、推送通知严重受限——这些恰恰是很多App的核心卖点。
- Safari对网页标准的支持比Chrome落后数月甚至数年——开发者想用新技术？对不起，先等苹果跟上了再说。
在欧洲，《数字市场法案》（DMA）已经在试图破解这种局面，要求苹果开放浏览器引擎限制。但苹果的应对方式被美国法官形容为”恶意服从”——它表面上修改了规则，实际上设置了一系列技术障碍让竞争对手难以真正进入。
这一切的最终效果是什么？开发者被”逼”上了App Store这条船，用户被”惯”成了只认App图标的人。
争议的另一面：有些场景App确实更合适
说到这里，笔者必须声明：这不是一篇”App原罪论”的文章。在HN的讨论中，有相当一部分开发者指出了App确实优于网页的场景：
一位名叫OkayPhysicist的程序员分享了他的经历：公司内部有个报销和文档工具，他把它做成了适配手机的网页版。结果呢？同事们追着他问”怎么把网站放到手机上？""网站怎么在手机上打开？""能不能做成App？”
问题出在使用习惯上。**对于大多数普通用户来说，“App”是可理解的概念，“网页”反而是抽象的。**你让他们在浏览器地址栏输入网址，不如让他们点一个彩色图标来得自然。
另一位开发者提出的观点也很有道理：**如果你每天要用一个服务十几次，一个独立的原生App确实比在浏览器里切来切去方便得多。**比如微信、支付宝、地图——这些高频使用场景下，App的性能优势（更快的响应速度、更流畅的动画、离线功能）是真实存在的。
还有一些场景是网页技术目前难以覆盖的：
- 高性能游戏：需要GPU加速、复杂的3D渲染
- AR/VR应用：需要深度访问摄像头和传感器
- 专业音视频编辑：需要实时处理和硬件编解码
- 需要后台持续运行的服务：比如运动追踪、导航
这些都是网页技术的合理边界。笔者不认为所有东西都应该变成网页，但同样也不认为所有东西都有理由变成App。
本质问题：不是技术之争，是权力之争
这场”App vs 网页”的争论，本质上是谁来决定你能用什么软件的权力之争。
在开放Web的世界里，你用一个网址就能发布服务，浏览器就是你的”应用商店”。没有人能审查你的内容，没有人能抽走你的收入，没有人能决定你的产品能不能”上架”。
在App Store的世界里，苹果和谷歌是守门人。他们决定什么能通过审核（500个审核员管着200万个App），他们决定抽多少成（15%到30%），他们决定你的App能用手机的哪些功能。用户确实获得了一定的”安全保障”——至少理论上，App Store里的东西经过了审核——但代价是失去了选择权。
这就是Dan那篇文章引发676人暴怒的深层原因：整个系统被设计成了这样——把一个本该是0.05MB的网页，硬生生变成了124MB的App。那个旅行App本身并不差，但系统逼着它走了一条臃肿的路。
尾声：你的选择是什么？
Dan的故事有一个温暖的结尾。他把自制的网页版分享给了同行团队的其他家长，大家第一次发现，原来不用装那个臃肿的App也能看到行程。他的女儿在迪士尼舞台上又唱又跳的时候，他的手机上少了一个124MB的追踪器。
对于我们普通人来说，这个故事的启示其实很简单：下次有人让你下载一个App来看点东西的时候，多问一句：这不能是个网页吗？
因为很多时候，答案是可以的。
参考链接：
- Dan Q：你的”App”本可以是张网页（所以我修好了它）
- Hacker News热门讨论：676条评论深度辩论App vs Web
- 微软工程师基准测试：iOS浏览器因WebKit限制性能落后28.6%
- 苹果WebKit限制与欧盟DMA合规争议分析报告
- PWA在iOS上的限制与Safari支持现状（2026年完整指南）
- 苹果30%佣金政策变更：Epic Games反垄断诉讼后续影响
- App Store审查制度争议：500名审查员与200万App的真实状况
- 开放Web倡导组织：苹果浏览器引擎限制的反竞争影响