For the first time, both major smartwatch platforms have lined up their 64-bit deadlines in the same calendar year. Apple's watchOS 26 SDK requirement, which lands on April 28, 2026, mandates 64-bit slices on every new submission and update. Google has followed with a Wear OS announcement requiring 64-bit native libraries on every new app and update from September 15, 2026. The two deadlines are five months apart, but the engineering work overlaps more than most teams expect, and the planning window is narrow enough that it's worth treating them as one project.
This guide walks through what's actually changing on each platform, why both vendors are pushing 64-bit on the wrist now, where the migration is likely to bite indie developers, and what a realistic six-month plan looks like if you maintain apps on both.
What changed on watchOS#
Apple's announcement is the more abrupt of the two. From April 28, 2026, every watchOS app submitted to App Store Connect must be built with the watchOS 26 SDK, and every watchOS app submitted from that date must include a 64-bit slice. Existing apps already on the store keep working — but you cannot push an update of any kind, including a screenshot refresh or a metadata correction, without producing a 64-bit watchOS 26 binary first.
This is the first time watchOS has had a 64-bit requirement at all. Apple Silicon S-series chips have supported 64-bit instructions for years, but Apple has historically allowed watchOS apps to ship 32-bit-only binaries because the install base of older watches still had a meaningful share. The cutoff aligns with the broader iOS 26 SDK enforcement and is part of the same April 28 wave.
The practical effect for most developers is that the ARCHS build setting in Xcode needs to be left at its default Standard architectures value, which produces a single binary with both 64-bit (arm64) and the legacy 32-bit slice if needed. If you've ever overridden this setting in your watch target — to shave binary size, to work around an older toolchain bug, or because you copy-pasted a build configuration from a tutorial — that override is what you need to remove.
What changed on Wear OS#
Google's announcement, made in early April, sets a September 15, 2026 cutoff for new Wear OS app submissions and updates that contain native code. From that date, native libraries must include both 32-bit and 64-bit versions, or the upload is rejected at the Play Console.
The phrasing matters. Google is requiring 64-bit in addition to 32-bit, not replacing it. Older Wear OS hardware that lacks a 64-bit processor will continue to receive 32-bit packages from the Play Store. The new rule is that you have to also ship 64-bit for the watches that need it. This is a bigger deal than it looks, because it means the entire chain of native dependencies in your app needs 64-bit support — not just your code.
Apps built entirely with Kotlin or Java are not directly affected by the requirement. The compiled bytecode runs on any architecture. Where teams will get caught is in third-party libraries that quietly include native code: image processing SDKs, ML runtimes, custom Bluetooth stacks, payment libraries, anything wrapping a C/C++ implementation. If one of those libraries ships only armeabi-v7a and x86, your update is blocked from September 15 onward until that library either updates or you replace it.
Why now, and why both at once#
The 64-bit transition on phones happened years ago — Apple in 2017, Google in 2019. Smartwatches lagged for three reasons that have all changed in the last twelve months.
The first is hardware. The S-series chips in modern Apple Watches and the Snapdragon W5+ class chips in modern Wear OS watches all have 64-bit cores. The fraction of active devices that genuinely need 32-bit-only support has dropped below the threshold where carrying it makes sense.
The second is the AI workload story. On-device models on the wrist — for things like fitness inference, local ASR for dictation, and the new wave of always-on smart features — are bumping into the 4 GB memory ceiling that 32-bit pointers impose. A 64-bit-only world unlocks the addressable space these models actually need.
The third is platform consistency. Both Apple and Google have been steadily pruning the architecture matrix their developers have to support, because the matrix itself is a tax on platform stability. Killing 32-bit on the wrist removes one of the last places in the developer toolchain where the architecture decision was even a question.
The convergence is not coordinated, but it is not coincidental either. The pressures pushing both platforms in the same direction are the same pressures.
Where the migration actually bites#
A short tour of the patterns I see hurting indie smartwatch developers right now.
Stale build settings on watchOS. The single most common issue is a watch target with VALID_ARCHS or ARCHS set to a hard-coded list that excludes the modern 64-bit slice. This setting was a recommended workaround in some 2018-era guides for keeping binary size down, and it has been quietly ignored ever since. Search every .xcodeproj in your watch target for VALID_ARCHS and ARCHS. If you find them, remove them.
Watch-only third-party libraries. Some smartwatch-specific libraries — particularly older complications frameworks, custom watch face engines, and a few sensor wrappers — were never updated for 64-bit. If your app depends on one, you have a hard choice: replace the dependency, ship without it, or skip the deadline. There is no fourth option.
Wear OS apps with native components. Even if you're a Kotlin shop, check whether anything in your dependency tree pulls in native libraries. The fastest way to check is unzip -l app-release.aab | grep .so — every .so file is a native library, and each one needs a 64-bit variant. If you see lib/armeabi-v7a/libfoo.so without a corresponding lib/arm64-v8a/libfoo.so, that library is a blocker.
Companion apps that share code. A lot of indie watch apps share an SDK with their phone app. If the phone-side SDK was built before 64-bit-only enforcement, the watch slice may have been generated from a 32-bit-first codebase. The fix is usually a clean rebuild against the modern toolchain, but the gotcha is when the SDK is vendor-supplied and you have to wait for the vendor.
Build pipelines that hard-code architecture flags. CI scripts, Fastlane lanes, and release automation all sometimes contain explicit architecture flags that override the project default. These are the worst kind of bug because they pass local Xcode builds and only fail when CI produces the upload binary. Audit your CI scripts.
A six-month plan that hits both deadlines#
Here is the schedule I'd run if I had a watch app on both platforms today, with five months until the watchOS deadline and four-and-a-half until Wear OS.
Week 1 (now): audit dependencies. Run unzip -l on your latest Wear OS bundle and lipo -info on every framework in your watchOS app. Make a list of every dependency that lacks 64-bit support on either platform. This list is the project. Everything else is execution.
Week 2: file vendor tickets. For every third-party dependency on your audit list, open a support ticket or GitHub issue asking for 64-bit support and a target date. Vendors tend to prioritize the ones that ask. Don't wait until July to find out a critical SDK isn't shipping a fix.
Week 3: migrate the watchOS target. Remove any ARCHS or VALID_ARCHS overrides. Bump to Xcode 26 and the watchOS 26 SDK. Build, archive, and upload to TestFlight. Don't worry about Liquid Glass adoption or new APIs yet — get the architecture migration done first, isolated from the design migration.
Week 4: ship the watchOS update through TestFlight. Run real device testing on the oldest 64-bit-capable Apple Watch you support. The simulator covers most things but not the radio stack and not the haptics. Get a TestFlight build out before April 28 even if you don't push it to production yet — uploading the binary buys you the option to ship.
Week 5: submit before the watchOS deadline. Push the update to production. If anything breaks in the wild, you still have the rest of the year to react with normal updates instead of fighting Apple's deadline policy.
Weeks 6 through 12: Wear OS migration. With watchOS landed, turn to the Wear OS side. Update your app/build.gradle.kts to ensure both arm64-v8a and armeabi-v7a are in your ABI splits. Replace any vendor library that didn't ship 64-bit support by week 12. Test on a 64-bit Wear OS device, not just the emulator.
Weeks 13 through 16: Wear OS QA and release. Submit a 64-bit-compatible Wear OS update to internal testing. Verify in Play Console that both ABIs are present in the uploaded bundle. Run a broader closed test before September 15 lands.
Week 17 onward: monitor. Watch crash reports for the architecture-specific failures that tend to surface only in the wild. Crashes that look memory-related on 64-bit slices are often pointer-size assumptions left over from 32-bit code paths.
The plan is conservative on purpose. The cost of being a week early is nothing. The cost of being a day late on the watchOS deadline is "you cannot ship updates until you fix it," which on a small team often translates to weeks of follow-on damage.
A note on dropping support entirely#
A small but real fraction of indie devs will look at this dual deadline and decide to deprecate their watch app altogether. The maintenance burden of a watch companion has always been disproportionate to the install base, and the 64-bit work is one more reason to ask whether the watch surface is worth it. That is a legitimate answer. If you choose it, do it deliberately — pull the watch app from the store on your own timeline, communicate it to your users, and don't let it die through a missed deadline. A planned sunset reads very differently to your users than a silent disappearance.
How Stora handles this#
When you push a watchOS or Wear OS build through Stora, the compliance engine inspects the architecture slices in the binary before submission and flags the cases that will get rejected at Apple's or Google's review queue. For watchOS, it checks for the 64-bit slice and warns if any framework in the bundle is 32-bit-only. For Wear OS, it inspects the AAB for native libraries and reports which ABIs are present per library, so you can see exactly which third-party dependency is going to block your September 15 update before you waste a Play Console upload finding out the hard way.
The build repair agent can fix the most common cause — stale ARCHS overrides on the watchOS side — automatically. The third-party dependency cases need a human, but at least Stora tells you which dependency to chase before you discover it on the Tuesday morning the deadline hits.
Conclusion#
The 64-bit-on-the-wrist transition is the kind of platform change that quietly sorts indie developers into the ones who plan five months out and the ones who get caught the week of the deadline. Both Apple and Google have given enough runway that there is no excuse for the second category. The work itself is mostly mechanical — the cost of doing it on time is low, and the cost of doing it late is missing your ability to ship updates on a platform where you've already invested years of work.
Audit your dependencies this week. File the vendor tickets. Get the watchOS migration done in May, not in late April. Get the Wear OS migration done in July, not in mid-September. The deadline is the deadline. The wrist is no longer a 32-bit platform.