WeType UI Enhanced: theming the WeType input method on MIUI and HyperOS

An Xposed module aimed at one input method

The project description states the scope in one line: it provides interface beautification and optimisation for the WeType input method, and at the same time lifts the MIUI full-screen optimisation limits for other input methods in scope.

The README expands on it. It is an Xposed module whose primary function is WeType interface beautification and personalisation, with the additional job of lifting the MIUI full-screen optimisation limits for other input methods in scope.

The mechanism determines the audience. An Xposed module works by hooking into another app's process at runtime, which means the user has to have a rooting or hooking framework installed and the module has to be granted a scope in that framework. This is not an accessibility service or a system setting. It is a modification of a running process, and it carries the usual implications of that.

The requirements section lists them: Android 12 or later, LSPosed or a compatible Xposed framework, Xposed API version 102 or later, and WeType itself. The badges state the same constraints, along with Jetpack Compose for the settings interface and AGPLv3 for the licence.

The primary language is Kotlin, the project is not archived, and the last push was on 2026-10-17. The recent releases are 1.28.5 tagged on 2026-10-15, 1.28.0 on 2026-09-15 and 1.27.1 on 2026-08-09, so the release cadence is roughly monthly with hotfix builds in between.

The repository also carries an `AGENTS.md` file at the top level, and an `assets/` directory with the icon and preview images, a `docs/` directory, and a Gradle project with `build.gradle.kts`, `settings.gradle.kts` and the wrapper scripts.

What the beautification controls actually cover

The feature list is specific, and it is the most useful part of the README because it tells you exactly which values the module exposes.

On the WeType side, the settings cover the window background colour and opacity in both light and dark mode, the key colours, opacity and corner radius in light and dark mode, the background blur strength, the smooth corner radius and the edge highlight effect, and the global brand accent colour for the input method. There is also a slider for the toolbar icon background opacity, a slider for the candidate word background opacity and corner radius, and a setting for the pinyin margin on the first candidate and the candidate bar. A final entry lets the user block WeType's hot update.

That last item is worth understanding rather than glossing over. Blocking the hot update means the input method stops pulling its own remote changes, which is what a user wants when a cloud hot fix changes the interface and undoes the theming. It also means the input method stops receiving whatever else the hot update carries, and the user has to remember to turn it back off later.

The features are organised in the settings into groups, since the README refers to a colour group and an appearance group, and to a settings group where the surface tint values are saved. The naming implies a coherent settings screen rather than a flat list of toggles, and that screen is built with Jetpack Compose, using the `miuix` Compose library credited in the acknowledgements section.

The default look is stated as well, with the README saying the default effect uses the colour and corner radius values from Apple's official iOS 27 design draft. So the out-of-the-box appearance imitates Apple's current input method design rather than Xiaomi's, with the preview screenshots keyed to the `#FB7299` theme colour.

Glass and advanced finish, gated on the system

There is a separate section for advanced finish and liquid glass, and it is the part with the strictest prerequisites.

On HyperOS devices that support the corresponding system visual effect interfaces, the settings expose two options in the appearance group. The advanced finish adopts the frosted background effect of the Super XiaoAi input method while keeping the module's own custom smooth corner radius. System liquid glass enables native glass rendering on top of the advanced finish, with parameters for refraction, thickness, blur and highlight, using the light and dark background colours and opacities saved in the colour group as the tint.

Both default to off, and both require the system visual effect to be enabled. On a device that does not support them, the README says the corresponding switches are unavailable rather than broken, which is a sensible design since a disabled control is not a crash.

The design decision worth noting is that the module does not implement its own glass effect. It asks the system for it. That is why the feature is unavailable on unsupported hardware, and it is also why the module is restricted to HyperOS for this part of its behaviour, since the underlying system API is a Xiaomi one.

The system liquid glass parameter set, refraction, thickness, blur and highlight, is the same vocabulary the system uses, which means the module is a pass-through to a system renderer rather than an independent implementation of a visual technique.

The MIUI side: lifting limits and fixing clipboard access

The MIUI and HyperOS section describes a different kind of work, and the README is careful to position it as secondary.

On MIUI and HyperOS systems that support Xiaomi's full-screen keyboard optimisation, the module lifts the full-screen keyboard optimisation restriction limits for third party input methods, lifts the package name validation on Xiaomi's short phrases, and fixes the problem where a third party input method cannot obtain the system clipboard list.

Three concrete changes. The first removes a restriction that Xiaomi places on third party keyboards so they cannot use the full-screen layout the system keyboard gets. The second affects Xiaomi's own short phrase feature, which normally checks the package name of the input method and refuses to work outside the system keyboard. The third is a genuine bug fix on the Xiaomi side, where the clipboard list was not reaching third party input methods at all.

The README states clearly that this part is not the module's main function, that it does not enable on non-Xiaomi systems, and that it does not affect the WeType beautification features. That separation matters in practice, because the WeType part works on any device that can run WeType with a hooking framework, while the MIUI part only exists on Xiaomi devices. A user on a non-Xiaomi phone can still get the theming without losing anything except the lifted restrictions, which they could not have had anyway.

The acknowledgements section credits a separate MIT licensed project for providing the full-screen optimisation removal functionality, which is where that behaviour comes from rather than from new code, so part of this behaviour is adapted from an existing open source project rather than written from scratch.

Installing: framework, scope, and a restart you will need twice

There is no install command here, and the README says where to get the artefact. Downloads come from the releases pages of this repository or of the module repository, which is an Xposed module repository.

The setup sequence is short and worth following exactly. Install the module, enable it in LSPosed, tick the WeType scope, and then restart WeType. The scope matters, because a module that is enabled but has no scope hooked into the target app does nothing at all, and that is the most common reason a module like this appears not to work.

Configuration is reached in two ways. There is a desktop entry point into the settings, and there is a parasitic settings page reached by clicking the WeType logo on its about screen, which is the pattern that modules use when they cannot own a normal activity.

The README also warns that some settings only take full effect after restarting the WeType process. That is a consequence of the hooking model rather than a bug: the module changes the interface of an already running app, and some of the values it sets are read when the input method's views are created, so they need a new process to be read again.

The test environment section is specific enough to be useful. The device is a Xiaomi 17 Pro running HyperOS 4.0.0.27 Beta on Android 17, with LSPosed v2.1.1-it build 7846, and WeType 3.5.3.56201. That is a specific combination, and it tells you what the author validated against rather than what the project claims to support in general.

Where WeType UI Enhanced is the wrong tool

The first wrong-tool case is a device that is not running a hooking framework. The module cannot work without LSPosed or a compatible Xposed framework, and the requirement is stated as a hard condition rather than an optional one. On a device where the bootloader is locked, or on an organisation's managed profile, this is simply not available.

The second is a non-Xiaomi phone where the MIUI part is the goal. The README states those functions do not enable on non-Xiaomi systems, so a user whose only interest is the full-screen keyboard restriction gets nothing here.

The third is a user who wants a stable input method. This is a module that hooks into another application's internals, and the compatibility section says so plainly: the module is adapted primarily to WeType, and when WeType's internal implementation, resource names or cloud hot fixes change, some functions may temporarily stop working. That is a different reliability profile from a vendor setting, and the module also has a feature to block the hot updates, which is the same trade in the other direction.

The fourth is a device you cannot accept the risk on. A module with the permissions an Xposed module needs is a module that can read everything the target app can read, and for an input method that means the contents of everything you type.

The alternative worth naming is the system input method itself, since MIUI and HyperOS include Xiaomi's own keyboard and the module's own advanced finish option explicitly borrows its design. The difference in approach is that the system keyboard needs no hooking framework, receives its fixes with the system, and is already allowed to use the full-screen optimisation and the system glass effects that this module lifts for others, but it cannot be themed to the degree this module allows, since its surface colour, opacity, corner radius and blur are not user-configurable.

The licence change and what it obliges you to do

The licence section carries the most consequential line in the README, and it is a change rather than a statement of a fixed state: from 2026-08-16 the project uses the AGPL-3.0 licence, requiring that modifications and distribution also publish the source code, under the same licence.

The licence recorded for the project is AGPL-3.0, and there is a `LICENSE` file in the tree. For a personal user who installs the module and does not redistribute it, the practical effect is nil. For someone who modifies the module and shares the result, the AGPL requires that the modified source is offered to the recipients of the modified binary, under the same terms.

This is a deliberate tightening for a project that has just been picked up and reworked, and it makes sense for a module whose value is in its code rather than in a service. It is also a change to track, because a project that was previously under a permissive licence and is now under AGPL changes the terms for anyone who forked it earlier. The README notes the switch date explicitly, which is the kind of detail that matters when a licence changes under you.

On maintenance, the picture is healthy. The last push was on 2026-10-17, two days before the newest release tag of 1.28.5, and there is a release roughly every month through 2026 with the 1.28 line moving in September and October. The repository is not archived.

The practical advice for anyone evaluating this is to decide which of the two things you are adopting. The theming part is a personalisation layer you could reasonably live without. The MIUI part is a functional fix for a restriction you might have a strong opinion about. Those two justifications lead to very different tolerance for breakage, and the README's compatibility warning applies mostly to the first.

Editorial conclusion

Adopt WeType UI Enhanced if you run WeType on a Xiaomi device with HyperOS, you have already set up an Xposed framework, and you want the input method to follow the system design language or to expose the glass and surface parameters the vendor keeps to its own keyboard. Do not adopt it on a non-Xiaomi device for the MIUI part, since the README states those extra functions do not enable on other systems, and do not adopt it if you are unwilling to run a hooking framework on the device that holds your messages. Before you install, read the compatibility section, because the module adapts to WeType's internal implementation and can partially break when a hot update changes it, and note that the project switched to AGPL-3.0 on 2026-08-16, which obliges you to publish source if you modify and redistribute it.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. NEORUAA/WeType_UI_Enhanced on GitHub
3. Project website
4. README
5. Releases