WeChat Shows Liquid Glass in iOS 27, but Tencent Did Not Redesign It

WeChat displayed Liquid Glass controls for some iOS 27 users despite Tencent apparently making no dedicated redesign for those interface elements. The distinction matters because Apple, not WeChat, reportedly produced the visible change through native system controls.

Users noticed the glass-like treatment in editing menus, search actions, input controls, and selected pop-up windows on September 3, 2026. A person identified in Chinese reports as a WeChat employee said iOS 27 automatically applied the appearance where the app called Apple’s system components.

That explanation has not appeared in a formal Tencent statement, and the employee’s role has not been independently verified. However, the technical mechanism matches Apple’s published documentation. It also exposes the central conflict behind this small visual change: Apple controls part of every native iPhone app’s appearance, even when the app owner controls the surrounding product.

This is not simply a story about WeChat receiving shinier menus. It is a practical demonstration of how Apple can use its operating system and developer frameworks to move third-party software toward one design language.

The result pressures Tencent and other large developers in two directions. They can rely on standard controls and accept Apple’s evolving appearance, or replace more of those controls with custom interfaces that require greater maintenance.

What Actually Changed Inside WeChat

The reported WeChat change affected system-provided interface elements, not the app’s entire design.

Chinese users first highlighted translucent controls appearing in isolated parts of the iPhone app. Reports identified text-selection menus, long-press search options, editing controls, and certain pop-ups as visible examples.

These elements appeared to reflect or blur the content behind them. Their rounded shapes and changing highlights resembled Apple’s Liquid Glass design, which treats controls as a separate visual layer above an app’s content.

The change did not amount to a complete WeChat redesign. Chats, contact lists, profile pages, icons, and major navigation structures did not suddenly inherit one uniform glass treatment.

A September 4 report attributed the explanation to a WeChat employee using the name Ke Cun Xiao Jiang. According to that account, iOS 27 applied Liquid Glass automatically wherever WeChat used relevant system controls.

That statement is credible at a technical level, but its attribution requires caution. Tencent had not published a corresponding corporate announcement when the reports circulated. The available evidence establishes a reported employee explanation, not a formal product release from WeChat.

The timing adds another limitation. iOS 27 remained prerelease software in early September, so the interface observed by beta users was not necessarily the final public behavior. Apple could still adjust component rendering, compatibility rules, or visual intensity before general availability.

Even with those caveats, the event reveals something users often miss. An app screen can combine several ownership layers.

WeChat controls its content, product logic, and custom interface. Apple supplies the operating system, keyboard, text services, accessibility behavior, and many reusable controls. When one of those system layers changes, a familiar app can look different without receiving a conventional redesign.

That split explains why only selected surfaces acquired the effect. A system menu can change while the custom screen behind it remains visually unchanged.

It also explains why two people using the same WeChat release might report different appearances. Their iOS version, device settings, beta build, and the specific control being opened can all affect what they see.

Calling the event a “WeChat Liquid Glass update” therefore overstates Tencent’s role. A more accurate description is that iOS 27 exposed which pieces of WeChat still belong to Apple’s interface layer.

Why iOS 27 Can Restyle Native Controls

Apple’s frameworks let standard controls inherit the current operating system design, turning framework choices into visible product decisions.

Apple introduced Liquid Glass with iOS 26 in June 2025. The company described it as a translucent material that reflects and refracts surrounding content while responding to movement and interaction.

The design extended across Apple’s operating systems, including app controls, navigation bars, widgets, icons, and system surfaces. Apple also released APIs that developers could use when creating their own glass-like elements.

Apple’s original design announcement made clear that Liquid Glass was not intended as decoration alone. It became part of the structural interface shared by Apple platforms.

Developers build iPhone interfaces primarily with UIKit or SwiftUI. UIKit is Apple’s long-established framework for constructing native interfaces. SwiftUI is its newer declarative framework, where developers describe the interface state and let the system manage much of its presentation.

Both frameworks provide standard components. These include buttons, menus, sheets, toolbars, tab bars, search fields, and navigation structures.

Apple’s adoption guidance says standard components can receive the latest appearance through system frameworks. Developers do not need to recreate every reflection, blur, transition, or changing highlight themselves.

That automation produces clear benefits. A standard menu can remain consistent with other iPhone apps. It can also inherit accessibility behavior, input support, layout adjustments, and future platform refinements.

It creates a corresponding loss of visual control. If Apple changes the standard menu, an app using that menu can change with it. The developer chooses the component, but Apple determines much of its current rendering.

Rebuilding against a newer software development kit can extend those changes across an app. An SDK is the collection of frameworks, tools, and interfaces used to build software for a particular platform version.

Apple tells developers to rebuild with the latest Xcode release, inspect the resulting interface, and remove custom backgrounds that interfere with system effects. It specifically warns that older styling layered over new materials can create awkward or redundant results.

The WeChat example appears narrower than a full rebuild-driven migration. The reported surfaces include system menus that iOS itself can present. That distinction matters because automatic adoption is not one universal switch affecting every pixel.

Some changes depend on the SDK used to build the app. Others belong to operating system services that appear whenever an app invokes them. Still others require explicit developer work.

The correct conclusion is therefore not that iOS 27 can arbitrarily redesign any app. It is that Apple can restyle portions of an app already delegated to Apple’s frameworks or system services.

That boundary is broad enough to be consequential. Editing text, presenting a system menu, opening a share sheet, or using a standard toolbar can expose Apple-controlled interface behavior inside a branded product.

Apple’s Design System Now Outranks App Intent

The central conflict is Apple’s demand for platform consistency against each developer’s desire for product-level control.

Apple wants iPhone software to feel coherent. Standard controls reduce relearning because familiar menus, navigation patterns, and interactions behave similarly across apps.

Developers also benefit from that consistency. They can avoid rebuilding common components and focus engineering resources on features that distinguish their products.

WeChat presents an unusually strong test of this arrangement. It is not a small utility with little visual identity. Tencent has developed a broad interface language around messaging, payments, services, channels, search, and mini programs.

Yet even an app of that scale still depends on operating system behavior. The appearance of a text menu demonstrates that Apple retains influence inside one of Tencent’s most carefully controlled products.

The power relationship becomes more visible in iOS 27 because Apple has narrowed the compatibility path. Apple previously provided a temporary option that let newer builds preserve the earlier interface appearance while developers reviewed their software.

The relevant property, UIDesignRequiresCompatibility, tells the system to present compatible UI elements using an older design. It was designed as a temporary migration aid, not a permanent veto over Apple’s visual direction.

Apple’s compatibility documentation states that the system ignores this key when an app is built for iOS 27 or later. Developers moving to the new SDK cannot depend on that escape route indefinitely.

This policy changes the practical negotiation. During the iOS 26 transition, developers could inspect Liquid Glass while preserving an earlier appearance for selected releases. With the iOS 27 SDK, Apple expects the new design to become the baseline.

A large developer can respond by replacing standard controls with custom ones. That option preserves branding, but it carries costs beyond drawing a different menu.

Custom controls require testing across screen sizes, languages, accessibility settings, input methods, and future system versions. Developers must handle animation, contrast, touch targets, focus behavior, and edge cases that system components already address.

WeChat must also maintain recognizable experiences across iPhone, Android, desktop systems, and the web. Following Apple too closely can widen the visual gap between its iOS and Android products.

Ignoring Apple’s patterns creates a different problem. An interface can feel dated or inconsistent beside updated system software. Users may interpret that mismatch as neglect, even when the older design reflects a deliberate cross-platform choice.

This is why the event pressures more than Tencent’s design team. It forces product leaders to decide which parts of an app should feel native to the device and which should remain native to the brand.

Meta faces the same question with WhatsApp. Google faces it across Gmail, Maps, and its productivity apps. Microsoft encounters it in Outlook, Teams, and OneDrive.

Each company uses a mixture of platform-native and custom components. Every mixture creates a different migration schedule and a different risk of visual fragmentation.

WeChat’s partial change makes that fragmentation observable. A Liquid Glass menu sitting above an older custom screen can look less like a redesign and more like two design systems colliding.

Automatic Liquid Glass Is Not Automatic Quality

System adoption can deliver consistency, but it cannot guarantee that a mixed interface remains readable, coherent, or intentional.

Liquid Glass combines transparency, blur, highlights, and responsive movement. Those properties depend heavily on the content behind a control.

A translucent menu may look controlled above a simple background. The same menu can lose clarity above photographs, dense text, video, or highly saturated colors.

Apple has refined the design since its iOS 26 debut. For iOS 27, the company announced a settings slider that lets users adjust Liquid Glass from clearer to more heavily tinted.

Apple’s iOS 27 overview frames this control as personalization. It also functions as an acknowledgment that one fixed transparency level does not serve every user or context.

That creates a testing matrix for developers. A control should remain understandable across light and dark modes, different wallpaper colors, accessibility preferences, increased contrast, reduced motion, and the new transparency setting.

Automatic rendering handles the material itself. It does not evaluate whether the surrounding custom screen provides the right hierarchy.

Apple advises developers to avoid stacking glass effects, overcrowding controls, or placing custom backgrounds behind system materials. Those recommendations show that framework automation still requires design review.

WeChat’s isolated glass surfaces therefore deserve testing as product elements, even if Tencent did not create them deliberately. The company must check whether menus obscure chat content, whether labels retain sufficient contrast, and whether touch targets remain predictable.

Localization makes the challenge harder. WeChat supports interface strings that vary substantially in length. A compact English action and its Chinese equivalent may occupy different widths, affecting the size and movement of a translucent menu.

Accessibility is another pressure point. Refraction and animation can help establish depth, but they can also distract users who prefer reduced visual motion.

The new settings controls give users some authority over the result. However, developers cannot assume every user will discover or modify those options.

There is also a trust issue. People generally interpret a visible app change as an intentional decision by the app developer. They rarely distinguish a Tencent-designed button from an Apple-rendered text menu.

If users dislike a new surface, WeChat may receive the complaint even when iOS supplied it. If users like it, they may incorrectly conclude that Tencent has completed a broader Liquid Glass migration.

Neither interpretation captures the mixed ownership of the screen.

This uncertainty should temper claims that WeChat has “adopted” Liquid Glass. Adoption usually implies a planned design review, implementation, testing process, and product release.

The reported event establishes that certain controls displayed the material. It does not establish that Tencent approved a comprehensive visual strategy around it.

The distinction will become even more important after iOS 27 reaches general users. A beta observation can expose a transition in progress, while a production release represents a design developers must support at scale.

The WeChat Effect Is a Warning for Every iOS Developer

Native components reduce engineering work, but they also transfer part of an app’s future appearance to Apple.

This tradeoff begins long before a new iOS version arrives. Teams make it whenever they choose between a standard component and a custom replacement.

Using a standard text menu gives an app established behavior for copying, pasting, searching, translating, and other contextual actions. Apple can add capabilities to that menu without requiring every developer to rebuild the interaction from scratch.

The same abstraction lets Apple modify the menu’s shape, animation, spacing, and material. A dependency chosen for functionality becomes a dependency on visual policy.

For small development teams, that exchange often makes sense. Reproducing system behavior would consume time better spent on the application’s core purpose.

Larger teams have more resources, but their risk is also greater. A visual change can reach millions of users, appear across screenshots and support pages, and conflict with an established design system.

The safest response is not to replace every native component. That would increase maintenance and create new accessibility risks.

Developers need an inventory of which surfaces are controlled by UIKit, SwiftUI, embedded web content, custom rendering, or system services. Without that map, teams cannot predict where an operating system update will become visible.

They should then test workflows, not isolated screenshots. A static toolbar might appear correct while changing shape unexpectedly during scrolling. A pop-up might remain readable on one screen and lose contrast on another.

Standard spacing also matters. Apple warns against hard-coded layout measurements because new control shapes and dimensions can break assumptions built around older interfaces.

Teams that layered custom backgrounds over native bars face a similar problem. The background may interfere with the scroll-edge effect or create multiple translucent layers.

These issues can affect functionality. A shifted control might overlap content. A navigation bar could occupy unexpected space. A custom icon might appear misaligned within a revised system button.

Developers should also treat compatibility mode as borrowed time. Apple explicitly describes it as temporary, and iOS 27 builds cannot use the key to preserve the older design.

That policy means postponement does not eliminate the migration. It concentrates testing near a future SDK deadline.

The WeChat episode offers a useful internal demonstration. Product managers can point to it when explaining why operating system betas deserve structured review, even when a team has not scheduled a redesign.

Knowledge teams should preserve screenshots, test notes, developer documentation, and decisions from each beta cycle in a searchable engineering knowledge base. That record helps distinguish expected framework behavior from a genuine regression.

The lesson also applies outside Apple’s platforms. Android design libraries, browsers, desktop frameworks, and embedded web engines all mediate how applications appear and behave.

Apple’s tight integration makes the effect especially visible. The company controls the hardware, operating system, development tools, interface frameworks, and distribution channel.

That stack gives Apple unusual leverage to turn a design recommendation into a default, then turn the default into a requirement for future builds.

Developers still choose how much of their interface uses Apple’s system. They simply cannot treat that choice as visually neutral.

What to Watch as iOS 27 Reaches Users

Three signals will show whether the WeChat appearance is a temporary beta artifact or the start of a broader platform-driven redesign.

The first signal is Tencent’s next public WeChat release after iOS 27 becomes generally available. Release notes, interface changes, or an official developer statement would clarify whether Tencent accepts the automatic treatment.

A broader appearance across navigation and controls would indicate intentional adoption. A narrower or modified implementation would suggest that Tencent wants to preserve more of its established visual identity.

Silence would not prove indifference. Large apps often adjust framework behavior without documenting every interface change. The actual production build will provide stronger evidence than informal comments alone.

The second signal is Apple’s final compatibility behavior. Developers need to confirm which elements change because an app uses the iOS 27 SDK and which change solely because the device runs iOS 27.

This distinction will determine the reach of Apple’s design policy. If older app builds also receive more system-rendered surfaces, users will see changes before developers complete broader migrations.

Apple’s handling of UIDesignRequiresCompatibility will be particularly important. Its documentation says iOS 27 builds cannot rely on the key, but teams must test the final SDK against real applications.

If the final release behaves as documented, Apple’s position becomes stronger. Developers updating their toolchain must either accept the current system design or invest in carefully justified custom interfaces.

The third signal is user response after the beta period. Reports from a small group of enthusiasts cannot predict how a wider audience will react during everyday messaging.

Watch for repeated complaints about contrast, motion, inconsistent styling, or controls that feel detached from WeChat’s content. Also watch whether users prefer the revised menus after adjusting Apple’s transparency setting.

A positive response would support Apple’s claim that common materials improve familiarity across apps. Persistent confusion would strengthen the argument that automatic consistency can undermine coherence within individual products.

These signals matter to anyone who uses iPhone software for sustained work. A system update can change the tools around writing, selecting, sharing, and organizing information, even when the underlying app has not announced new features.

For developers, the immediate action is straightforward: test critical workflows on the final iOS 27 build and identify every surface owned by a system framework.

For users, the more useful question is not whether WeChat “copied” Apple’s design. Ask which company controls the interface element in front of you, and whether that division improves the task.

The next WeChat build, Apple’s final compatibility rules, and production-scale user feedback will answer that question more reliably than a beta screenshot. Until then, the reported Liquid Glass menus should be read as evidence of Apple’s platform leverage, not proof of a completed Tencent redesign.