WeChat 在 iOS 27 中呈现 Liquid Glass,但腾讯并未重新设计它
尽管腾讯显然并未针对这些界面元素进行专门改版,部分 iOS 27 用户仍在 WeChat 中看到了 Liquid Glass 控件。这个区别很重要:据报道,带来可见变化的是 Apple 的原生系统控件,而非 WeChat 本身。
用户在 2026 年 9 月 3 日注意到,编辑菜单、搜索操作、输入控件及部分弹出窗口出现了玻璃质感处理。中国媒体报道中一位被称为 WeChat 员工的人士表示,只要应用调用 Apple 的系统组件,iOS 27 就会自动应用这一视觉效果。
这一说法尚未出现在腾讯的正式声明中,该员工的身份也未获独立核实。不过,其技术机制与 Apple 已公开的文档相符。它也揭示了这项细微视觉变化背后的核心矛盾:即便应用所有者掌控周边产品,Apple 仍控制着每个原生 iPhone 应用外观的一部分。
这不只是 WeChat 获得了更炫亮菜单的故事。它实际展示了 Apple 如何借助操作系统和开发者框架,推动第三方软件向同一套设计语言靠拢。
这一结果使腾讯和其他大型开发者面临两种方向:继续依赖标准控件,接受 Apple 持续演进的视觉风格;或以需要更多维护的自定义界面,取代更多此类控件。
WeChat 内部究竟发生了什么变化
据报道,WeChat 的变化涉及系统提供的界面元素,而非整个应用的设计。
中国用户最先指出,这款 iPhone 应用的局部区域出现了半透明控件。报道列举的可见例子包括文本选择菜单、长按搜索选项、编辑控件及特定弹窗。
这些元素似乎会反射或模糊其背后的内容。其圆润轮廓与不断变化的高光,让人联想到 Apple 的 Liquid Glass 设计;该设计将控件视为悬浮在应用内容之上的独立视觉层。
这一变化并不等于 WeChat 完成了全面重新设计。聊天、联系人列表、个人资料页、图标和主要导航结构,并未突然统一采用玻璃质感。
一篇 9 月 4 日的报道 将这一解释归因于一位名为 Ke Cun Xiao Jiang 的 WeChat 员工。根据该报道,只要 WeChat 使用了相关系统控件,iOS 27 就会自动应用 Liquid Glass。
这一说法在技术层面具有可信度,但其归属仍需谨慎看待。报道传播时,腾讯尚未发布相应的企业公告。现有证据只能证实这是一位据称员工的解释,而非 WeChat 的正式产品发布信息。
时间点也带来另一层限制。9 月初 iOS 27 仍属预发布软件,因此测试版用户观察到的界面未必代表最终公开版本的行为。Apple 仍可能在正式普及前调整组件渲染、兼容性规则或视觉强度。
即便存在这些保留,事件仍揭示了用户常常忽略的一点:一个应用界面可以由多个不同归属层构成。
WeChat 掌控其内容、产品逻辑和自定义界面。Apple 则提供操作系统、键盘、文本服务、辅助功能行为以及诸多可复用控件。当这些系统层中的某一层发生变化时,一个熟悉的应用即使未经历传统意义上的改版,也可能呈现不同外观。
这种分层解释了为何只有部分界面获得了这一效果。系统菜单可以发生变化,而其背后的自定义页面在视觉上仍保持不变。
这也解释了为何使用同一 WeChat 版本的两个人,可能报告不同的外观。他们的 iOS 版本、设备设置、测试版构建以及所打开的具体控件,都会影响他们所见的效果。
因此,将这件事称为“WeChat Liquid Glass 更新”夸大了腾讯的角色。更准确的说法是,iOS 27 显露出 WeChat 中哪些部分仍属于 Apple 的界面层。
为什么 iOS 27 能重新塑造原生控件
Apple 的框架让标准控件继承当前操作系统设计,使框架选择成为可见的产品决策。
Apple 于 2025 年 6 月随 iOS 26 推出了 Liquid Glass。该公司将其描述为一种半透明材质,能够反射并折射周边内容,同时响应移动和交互。
这一设计延伸至 Apple 的各类操作系统,涵盖应用控件、导航栏、小组件、图标和系统界面。Apple 还发布了 API,供开发者创建自己的类玻璃元素。
Apple 的最初设计公告明确表示,Liquid Glass 并非只是一种装饰。它成为 Apple 平台共享结构化界面的一部分。
开发者主要使用 UIKit 或 SwiftUI 构建 iPhone 界面。UIKit 是 Apple 长期以来用于构建原生界面的框架。SwiftUI 则是较新的声明式框架,开发者描述界面状态,而系统负责管理大量呈现工作。
两种框架都提供标准组件,包括按钮、菜单、工作表、工具栏、标签栏、搜索字段和导航结构。
Apple 的采用指南指出,标准组件可通过系统框架获得最新外观。开发者无需自行重建每一道反射、模糊、过渡动画或变化中的高光。
这种自动化带来了明确好处。标准菜单可以与其他 iPhone 应用保持一致,也能继承辅助功能行为、输入支持、布局调整及未来的平台优化。
相应地,它也会造成视觉控制权的减少。如果 Apple 修改标准菜单,使用该菜单的应用也会随之变化。开发者选择组件,但 Apple 决定了其大部分当前渲染方式。
基于新版软件开发工具包重新构建应用,可能将这些变化扩展到整个应用。SDK 是用于为特定平台版本构建软件的一组框架、工具和接口。
Apple 要求开发者使用最新版本的 Xcode 重新构建,检查生成的界面,并移除会干扰系统效果的自定义背景。它特别警告,在新材质之上叠加旧样式,可能产生别扭或冗余的结果。
WeChat 的例子看起来比由全面重新构建驱动的迁移更为局部。据报道,受影响的界面包括可由 iOS 自身呈现的系统菜单。这一区别很重要,因为自动采用并不是影响每一个像素的通用开关。
有些变化取决于构建应用时使用的 SDK;有些属于应用每次调用时都会出现的操作系统服务;还有一些则需要开发者明确投入工作。
因此,正确的结论并不是 iOS 27 可以任意重新设计任何应用,而是 Apple 可以重新塑造那些已委托给 Apple 框架或系统服务的应用部分。
这一边界足够广泛,因而影响重大。编辑文本、展示系统菜单、打开分享面板或使用标准工具栏,都可能在品牌化产品中呈现由 Apple 控制的界面行为。
Apple 的设计系统如今优先于应用意图
核心矛盾在于:Apple 对平台一致性的要求,与每个开发者对产品层面控制权的诉求之间存在冲突。
Apple 希望 iPhone 软件具有连贯感。标准控件降低了用户的重新学习成本,因为熟悉的菜单、导航模式和交互方式在不同应用中表现相似。
开发者同样能从这种一致性中受益。他们无需重建常见组件,可以将工程资源集中在能够使产品脱颖而出的功能上。
WeChat 为这种安排提供了一个格外有力的考验。它并不是一个缺乏鲜明视觉身份的小型工具。腾讯已围绕消息、支付、服务、频道、搜索和小程序发展出广泛的界面语言。
然而,即使是这样规模的应用,仍依赖操作系统行为。文本菜单的外观表明,Apple 依然能够影响腾讯最精心控制的产品之一。
在 iOS 27 中,这种权力关系变得更加明显,因为 Apple 收窄了兼容路径。此前,Apple 提供过一项临时选项,允许较新的构建版本在开发者审查软件期间保留较早的界面外观。
相关属性 UIDesignRequiresCompatibility 会告知系统以旧版设计呈现兼容的 UI 元素。它被设计为临时迁移辅助工具,而不是对 Apple 视觉方向的永久否决权。
Apple 的兼容性文档指出,当应用面向 iOS 27 或更高版本构建时,系统会忽略这一键。迁移至新 SDK 的开发者无法无限期依赖这条退路。
这项政策改变了实际协商方式。在 iOS 26 的过渡阶段,开发者可以在为部分版本保留旧外观的同时检查 Liquid Glass。使用 iOS 27 SDK 后,Apple 希望新设计成为基准。
大型开发者可以通过以自定义控件取代标准控件来应对。该方案能保留品牌特征,但其代价不止是绘制一个不同的菜单。
自定义控件需要在不同屏幕尺寸、语言、辅助功能设置、输入方式及未来系统版本中进行测试。开发者还必须处理动画、对比度、触控目标、焦点行为以及系统组件已能应对的边缘情况。
WeChat 还必须在 iPhone、Android、桌面系统和网页端维持可识别的一致体验。过于紧随 Apple,可能扩大其 iOS 与 Android 产品之间的视觉差距。
忽视 Apple 的模式则会带来另一种问题。与更新后的系统软件并列时,界面可能显得过时或不一致。即使旧设计反映了有意为之的跨平台选择,用户也可能将这种不匹配解读为疏于维护。
这正是为何该事件施压的不只是腾讯的设计团队。它迫使产品负责人决定:应用的哪些部分应当更贴近设备原生体验,哪些部分应继续忠于品牌本身。
Meta 在 WhatsApp 上面临同样的问题。Google 在 Gmail、Maps 及其生产力应用中也面临这一问题。Microsoft 则在 Outlook、Teams 和 OneDrive 中遇到同样的挑战。
每家公司都同时采用平台原生组件和自定义组件。每种组合都会形成不同的迁移节奏,以及不同程度的视觉碎片化风险。
WeChat 的局部变化让这种碎片化变得可见。一个 Liquid Glass 菜单悬浮在较旧的自定义页面之上,看起来可能不像重新设计,反而更像两套设计系统的碰撞。
自动采用 Liquid Glass 不等于自动获得高质量体验
系统层面的采用可以带来一致性,但无法保证混合界面仍然清晰、连贯且有意图。
Liquid Glass 融合了透明度、模糊、高光和响应式动态效果。这些特性高度依赖控件背后的内容。
半透明菜单在简洁背景上或许显得井然有序。但当它叠加在照片、密集文本、视频或高饱和色彩之上时,清晰度可能会下降。
自 iOS 26 首次推出以来,Apple 一直在完善这一设计。针对 iOS 27,公司宣布将提供一个设置滑块,让用户可将 Liquid Glass 调整为更清透或更深的染色效果。
Apple 的 iOS 27 概览 将这一控制项定位为个性化功能。它同样承认:固定的透明度水平并不能适合所有用户或使用情境。
这为开发者带来了一个测试矩阵。控件应当在浅色和深色模式、不同壁纸颜色、辅助功能偏好、更高对比度、减少动态效果,以及新的透明度设置下保持易于理解。
自动渲染会处理材质本身,却不会判断周围的自定义界面是否提供了恰当的信息层级。
Apple 建议开发者避免叠加玻璃效果、过度拥挤控件,或在系统材质后方放置自定义背景。这些建议表明,框架自动化仍然需要设计审查。
因此,即便 Tencent 并非有意打造这些玻璃表面,WeChat 仍应将其作为产品元素进行测试。公司必须检查菜单是否遮挡聊天内容、标签是否保有足够对比度,以及触控目标是否依然可预测。
本地化让挑战更为复杂。WeChat 支持长度差异显著的界面文案。简短的英文操作及其中文对应表达可能占据不同宽度,从而影响半透明菜单的尺寸和移动方式。
辅助功能是另一项压力点。折射和动画能够帮助建立纵深感,但也可能干扰偏好减少视觉动态效果的用户。
新的设置控件让用户对最终效果拥有一定主导权。不过,开发者不能假定每位用户都会发现或调整这些选项。
这还涉及信任问题。人们通常会将可见的应用变化理解为应用开发者的有意决定。他们很少区分 Tencent 设计的按钮与 Apple 渲染的文字菜单。
即使是 iOS 提供了新表面,若用户不喜欢,WeChat 仍可能收到投诉。若用户喜欢,他们也可能错误地认为 Tencent 已完成更广泛的 Liquid Glass 迁移。
这两种理解都无法准确反映界面混合归属的现实。
这种不确定性应当缓和“WeChat 已‘采用’Liquid Glass”的说法。采用通常意味着经过规划的设计审查、实施、测试流程和产品发布。
已报道的事件只能证明某些控件显示了这种材质。它并不能证明 Tencent 已批准围绕该材质的一套完整视觉策略。
在 iOS 27 面向普通用户正式发布后,这一区别将更加重要。Beta 版观察可以揭示正在进行的过渡,而正式版则代表开发者必须大规模支持的设计。
WeChat 效应是对每位 iOS 开发者的警示
原生组件能减少工程工作量,但也会将应用未来外观的一部分控制权交给 Apple。
这种权衡早在新版 iOS 到来之前就开始了。团队每次在标准组件与自定义替代方案之间做选择时,都会面临它。
使用标准文本菜单,可让应用获得成熟的复制、粘贴、搜索、翻译及其他上下文操作行为。Apple 可以为该菜单增加功能,而无需每位开发者从头重建交互。
同一层抽象也让 Apple 能够改变菜单的形状、动画、间距和材质。出于功能选择的依赖,随之变成了对视觉政策的依赖。
对于小型开发团队而言,这种交换通常是合理的。复刻系统行为会消耗本应投入应用核心目标的时间。
大型团队拥有更多资源,但承担的风险也更大。一项视觉变化可能触及数百万用户,出现在截图和支持页面中,并与既有设计系统发生冲突。
最稳妥的应对方式并不是替换每一个原生组件。那样会增加维护负担,并带来新的辅助功能风险。
开发者需要盘点哪些界面由 UIKit、SwiftUI、嵌入式 Web 内容、自定义渲染或系统服务控制。没有这张地图,团队就无法预测操作系统更新会在哪些位置变得可见。
随后,他们应测试工作流,而非孤立的截图。静态工具栏可能看起来正确,却会在滚动时意外改变形状。弹出窗口可能在一个界面中保持可读,却在另一个界面中失去对比度。
标准间距同样重要。Apple 警告不要硬编码布局尺寸,因为新的控件形状和尺寸可能打破基于旧界面建立的假设。
在原生栏位上叠加自定义背景的团队也会遇到类似问题。背景可能干扰滚动边缘效果,或形成多层半透明叠加。
这些问题可能影响功能。偏移的控件可能遮挡内容。导航栏可能占据意料之外的空间。自定义图标可能在更新后的系统按钮中显得未对齐。
开发者也应将兼容模式视为争取来的时间。Apple 明确将其描述为临时措施,而 iOS 27 构建无法使用该键来保留旧设计。
这一政策意味着推迟并不会消除迁移,只会将测试集中到未来的 SDK 截止日期附近。
WeChat 事件提供了一个有用的内部示例。产品经理在说明为何操作系统 Beta 版值得进行结构化审查时,可以引用它,即使团队尚未安排重新设计。
知识团队应将每个 Beta 周期的截图、测试笔记、开发者文档和决策保存在可搜索的工程知识库中。这些记录有助于区分预期的框架行为与真正的回归问题。
这一经验同样适用于 Apple 平台之外。Android 设计库、浏览器、桌面框架和嵌入式 Web 引擎都会影响应用的外观和行为。
Apple 的紧密整合让这种影响尤为显著。公司掌控硬件、操作系统、开发工具、界面框架和分发渠道。
这套技术栈赋予 Apple 非同寻常的影响力:它可以将设计建议变成默认值,再将默认值转变为未来构建的要求。
开发者依然可以选择自己的界面有多少采用 Apple 的系统。他们只是不能再将这一选择视为视觉中立的选择。
iOS 27 面向用户后值得关注什么
三个信号将表明 WeChat 的外观是临时的 Beta 版产物,还是更广泛的平台驱动重新设计的开端。
第一个信号是 iOS 27 正式发布后 Tencent 的下一次公开 WeChat 更新。发行说明、界面变化或官方开发者声明,都将澄清 Tencent 是否接受这种自动处理方式。
若导航和控件中出现更广泛的相同外观,便表明这是有意采用。更有限或经过修改的实现,则意味着 Tencent 希望保留更多既有视觉身份。
沉默并不意味着漠不关心。大型应用经常调整框架行为,却不会记录每一项界面变化。实际正式构建比非正式评论更能提供有力证据。
第二个信号是 Apple 最终的兼容性行为。开发者需要确认,哪些元素因为应用使用 iOS 27 SDK 而发生变化,哪些变化仅仅因为设备运行 iOS 27。
这一区别将决定 Apple 设计政策的影响范围。若旧版应用构建同样获得更多系统渲染的表面,用户将在开发者完成更广泛迁移前就看到变化。
Apple 对 UIDesignRequiresCompatibility 的处理将尤为重要。其文档称 iOS 27 构建不能依赖该键,但团队必须针对真实应用测试最终 SDK。
如果正式版的行为与文档一致,Apple 的立场将更加强势。更新工具链的开发者必须接受当前系统设计,或者投入资源打造经过充分论证的自定义界面。
第三个信号是 Beta 期结束后的用户反馈。少量爱好者的报告无法预测更广泛用户群体在日常消息沟通中的反应。
应关注关于对比度、动态效果、样式不一致,或控件显得与 WeChat 内容脱节的反复投诉。还应观察用户在调整 Apple 的透明度设置后,是否更偏好修改后的菜单。
积极反馈将支持 Apple 的主张:通用材质能够改善跨应用的熟悉感。持续的困惑则会加强另一种观点:自动一致性可能削弱单个产品内部的连贯性。
这些信号对任何长期使用 iPhone 软件工作的人都很重要。即使底层应用没有宣布新功能,系统更新也可能改变围绕写作、选择、分享和组织信息的工具。
对于开发者而言,眼下的行动很直接:在最终 iOS 27 构建上测试关键工作流,并识别每一处由系统框架控制的界面。
对于用户而言,更有用的问题不是 WeChat 是否“照搬”了 Apple 的设计。应当问的是,眼前的界面元素由哪家公司控制,以及这种分工是否改善了任务体验。
下一版 WeChat 构建、Apple 最终的兼容性规则,以及生产规模的用户反馈,将比一张 Beta 截图更可靠地回答这个问题。在此之前,关于 Liquid Glass 菜单的报道应被视为 Apple 平台影响力的证据,而非 Tencent 已完成重新设计的证明。



