一个更新到最新系统的Pixel手机,一条现成的日历订阅链接。点开,想加进日历,App却告诉你:不支持。
这不是老机型的兼容问题,是Google自己写在官方帮助页上的规矩——订阅新日历,必须用电脑网页浏览器,安卓、iPhone、iPad三端应用全部不支持。
这事有意思的地方,不在“又一个bug”,而在它干净利落地戳穿了一句行业常挂在嘴边的话:App里“更好用”,常常只是一句没法验证的承诺。最直接受影响的是两类人——只想在手机上办完一件小事的普通用户,和被迫在网页、应用两端各写一套代码的开发团队。
订阅一个日历,要绕这几步
Google的帮助页写得很直白:新增日历只能用电脑网页浏览器操作,安卓、iPhone、iPad应用都不支持订阅新日历。
作者的实际做法是,在手机浏览器里打开桌面模式,访问calendar.google.com,把日历加进去。加完之后,它会自动同步回手机App。
这套流程能解决问题,但绕这一圈本身就是问题。需要说清楚的是,卡住的只是“加一条新订阅”这个动作——公开日历的搜索、已订阅日历的日常查看,安卓App都能正常用。
普通用户的应对很现实:记住这招“开桌面模式”,或者干脆放弃在手机上订阅,等坐回电脑再办。
App为什么总慢半步
App更新要过设备测试和应用商店审核,走完这套流程,用户才能用上新功能。网页改一行代码,刷新就生效。这个滞后,是App架构自带的成本,不是Google一家的毛病。
| 维度 | App | 网页 |
|---|---|---|
| 原生调用、推送 | 支持 | 有限 |
| 离线体验 | 支持 | Service Worker已补齐大半 |
| 更新速度 | 受设备测试+商店审核,滞后 | 改代码即生效 |
| 订阅新日历(本次问题) | 不支持 | 支持 |
更现实的猜测是,主屏图标和打开次数是团队要交的活跃度指标。把用户留在App里,比把一个功能做完整,更容易被看见、被记功。这只是行业惯常的猜测,没人会把KPI写进产品发布会,但App半成品的现象,和这套指标逻辑对得上号。
评论区有位读者说,Google的软件只有两种状态:已废弃,或者还没做完。这话刻薄,但半成品体验攒多了,大家自然会往这个方向联想。
我不太买账的是什么
App没有原罪。原生调用、推送、离线体验,这些都是真优势。但这些优势不再是App独占的,浏览器这几年靠渐进式网页和Service Worker,补齐了大半功课。
真正该被质疑的,不是App能不能做,而是企业说“请用我们的App”时,有没有把事情做完。没做完,那句承诺就只是入口占位,用户被当成活跃度素材,不是被当成要解决问题的人。
早年门户网站也想把用户圈在自己的围墙花园里,不情愿放人去开放的网页。App的主屏图标,有几分同一套逻辑换了个壳——但不完全一样:今天连Google自己都留了后门,做不到的时候,还是靠网页兜底。这至少说明,它自己心里也清楚,App没做完时该信谁。
接下来值得留意的,是这个缺口会不会在后续版本被补上,还是继续当成默认状态——目前还看不清。这类“App做不到、网页兜底”的逻辑,如果在更多产品上反复出现,才真正值得警惕,而不该把这一次的个案,直接当成Google整体软件治理失败的证据。
那条日历订阅链接,最后是靠浏览器桌面模式救场的。这大概是对“App里体验更好”这句话,最诚实的注脚。
