Actualité
Google sets September 15 deadline for 64-bit Wear OS apps
Google Play will block new Wear OS apps and updates containing native code unless they include 64-bit versions, with developers urged to audit libraries before September 15.
Wear OS developers are heading toward a firm compatibility deadline. Google says that, from September 15, 2026, every new Wear OS app and app update containing native code must include 64-bit support in addition to 32-bit support when published through Google Play.
The change is part of Android’s wider move toward 64-bit software. In its official developer announcement, Google says Play Console will begin blocking uploads that do not meet the requirement. The policy targets the publishing pipeline rather than existing installations, so the immediate impact is on developers preparing releases, not on people simply using a current Wear OS app.
What is changing for Wear OS
The rule applies when an app or update includes native code. That can mean code written through the Android NDK, but it can also arrive indirectly through a third-party SDK, game engine, analytics package or other dependency. An app written mainly in Kotlin or Java may therefore still need an audit before its next release.
Google is not removing support for 32-bit devices under this announcement. Existing 32-bit Wear OS devices will continue to receive compatible apps through Google Play. The publishing requirement is designed to make sure new software is ready for 64-bit-only environments while maintaining support for older hardware where it is still available.
Why the deadline matters
Wearable apps increasingly rely on native libraries for graphics, media, Bluetooth communication, machine-learning features and performance-sensitive background work. If one of those libraries exists only in a 32-bit version, an otherwise modern app can fail to install, start or complete a task on a 64-bit-only image.
Google’s rationale is broader than a compliance checkbox. The company says 64-bit architectures provide a foundation for faster and richer experiences, while giving developers a clearer path for future Wear OS hardware and software. The practical result is that developers must confirm architecture support before they submit an update, rather than discovering the problem after a release is rejected.
How developers can check an app
The first step is to inspect the APK or Android App Bundle with Android Studio’s APK Analyzer. Developers should look for native shared-object files inside the lib directory. On ARM devices, the relevant folders are lib/armeabi-v7a for 32-bit libraries and lib/arm64-v8a for 64-bit libraries.
The audit should compare the two architectures rather than merely confirming that one 64-bit file exists. For every native 32-bit architecture an app supports, Google recommends providing the corresponding 64-bit ABI. Missing files can come from an SDK that has not been updated, a bundled binary that predates the change or a build configuration that excludes the required architecture.
If a dependency is available only in 32-bit form, the next step is to contact its provider or replace it with a 64-bit-compatible release. This is particularly important for closed-source libraries, because an application team may not be able to rebuild the affected component itself. Keeping a record of each native dependency also makes future Play Console checks easier.
Testing beyond the upload check
Architecture parity does not guarantee that an app behaves correctly at runtime. Google recommends using the Wear OS Android Emulator to verify the 64-bit build. The goal is to confirm that the 64-bit version retains the same features and quality as the 32-bit version.
Testing should include the parts of the app that load native code dynamically. Google specifically warns that loaders such as SoLoader, along with older OpenSSL versions, may need updates on 64-bit-only hardware. Developers should test launch, background work, watch-to-phone communication, media playback and any feature that depends on a native library, rather than limiting the check to installation.
Wear OS apps submitted to Google Play already have to target Wear OS 4 or higher, and Google notes that many developers may therefore be using newer 64-bit-only images already. That reduces the amount of work for compliant apps, but it does not replace an explicit inspection of the final bundle.
What users should expect
For most Wear OS owners, the transition should be largely invisible. Google is not announcing a new requirement to replace existing watches, and apps already installed on older 32-bit devices are not being described as immediately unsupported. The visible change will mainly be behind the scenes: developers must ship architecture-complete updates, while Google Play filters out non-compliant submissions.
The deadline also gives users a useful reason to keep Wear OS and companion-phone software current. Updates delivered after September 15 should have passed Google Play’s new upload check, although individual app compatibility can still depend on the developer’s testing and the watch model involved.
With the enforcement date approaching, the safest workflow is straightforward: inspect the release bundle, identify every native dependency, add matching 64-bit libraries, update outdated SDKs and exercise the result in the Wear OS emulator. Developers who complete those checks before submission should be better placed to avoid a rejected update and to keep their apps ready for the next generation of Wear OS devices.