Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MacRumors

macrumors bot
Original poster
Apr 12, 2001
68,162
38,937


watchOS 26 brings a significant upgrade to the Apple Watch's architecture, transitioning the latest models to full arm64.

watchos-26.jpg

The change was revealed in Apple's "What's new in watchOS 26" video for developers. The Apple Watch Series 9, Series 10, and Apple Watch Ultra 2 are set to move from arm64_32 to the full arm64 architecture.

The arm64_32 architecture was a modified version of the standard 64-bit ARM architecture with 32-bit pointers, specifically optimized for the constrained memory environments of wearable devices. This hybrid architecture allowed Apple to implement the benefits of 64-bit instruction sets while maintaining a tighter memory footprint than full 64-bit systems.

The standard arm64 architecture provides 64-bit pointers and access to broader memory ranges, enhanced performance, and increased compatibility with general-purpose ARM computing standards. The move also opens the door for potentially more complex and computationally intensive watchOS applications, since arm64 provides access to more registers and system resources compared to the more compact arm64_32, as well as more direct alignment with development tools and runtime environments used across other Apple platforms.

watchOS 26 apps must now be built with awareness of both arm64 and arm64_32, depending on the target device. Apple clarified that older models, such as the Apple Watch SE (2nd generation) and Series 8, continue to use the arm64_32 architecture. As a result, watchOS apps need to include separate binaries to support both instruction sets. Xcode automatically manages the build process for arm64 and arm64_32 as long as developers maintain appropriate deployment targets and architectures in their project settings.

Existing apps built for arm64_32 will continue to run on newer Apple Watches running watchOS 26 via compatibility layers, but re-compilation for native arm64 is encouraged for best performance and forward compatibility. It is likely that arm64_32 support on the Apple Watch will gradually diminish over coming years as legacy hardware is retired. All of Apple's other platforms already use the full arm64 architecture.

Article Link: watchOS 26 Moves Latest Apple Watch Models to New Architecture
 
Wooo, this is truly a game changer for Apple Watch. With the move to arm64, the modern Apple Watches are truly the watches for ultra pros. This will allow developers to take watchOS apps to a whole new level, while maintaining the best-in-class privacy only Apple is known for. Apple can’t wait to see the incredible things customers do with the biggest leap forward in Apple Watch since the original Apple Watch.
 
Apple has really pushed the bounds of 64 bit computing for sure... but I absolutely do not see any benefit to going all in on 64 bit pointers on apple watch. The latest models have ~1 GB of RAM. They could quadruple that amount and still be fine with 32 bit pointers. I'd be interested to see what they are doing under the hood that truly makes going to 64 bit pointers all that great at this memory footprint that justifies this change - otherwise this feels like a slick way of combinging a 64 bit marketing win with forced obsolesce.

"Look!!! 64 bit stuff... oh by the way, the pointers take double the memory, so older devices will run even slower... time to upgrade!"
 
Every sentence in English should begin with a capital letter. This is a fundamental rule of English grammar.
I'm French and this apply to any language. What you don't get is
- 1/ watchOS is a trademark so it does not have to follow this rule
- 2/ This trademark starts without capital letters. Exactly like all other OS from Apple (iOS, macOS, tvOS, visionOS etc)

Take a coffee next time before posting bs
 
Apple has really pushed the bounds of 64 bit computing for sure... but I absolutely do not see any benefit to going all in on 64 bit pointers on apple watch. The latest models have ~1 GB of RAM. They could quadruple that amount and still be fine with 32 bit pointers. I'd be interested to see what they are doing under the hood that truly makes going to 64 bit pointers all that great at this memory footprint that justifies this change - otherwise this feels like a slick way of combinging a 64 bit marketing win with forced obsolesce.

"Look!!! 64 bit stuff... oh by the way, the pointers take double the memory, so older devices will run even slower... time to upgrade!"
The phones also started out on 32 bit ARM processors. What they gain by going to fully 64 bit is more registers and better optimized ISA. The code will get larger with larger pointers, so they probably waited with this step until they felt the gains overshadowed the disadvantages. It's more than just the addressable memory, it's about efficiency as well as when they transformed the phones to 64 bit.
 
Apple has really pushed the bounds of 64 bit computing for sure... but I absolutely do not see any benefit to going all in on 64 bit pointers on apple watch. The latest models have ~1 GB of RAM. They could quadruple that amount and still be fine with 32 bit pointers. I'd be interested to see what they are doing under the hood that truly makes going to 64 bit pointers all that great at this memory footprint that justifies this change - otherwise this feels like a slick way of combinging a 64 bit marketing win with forced obsolesce.

"Look!!! 64 bit stuff... oh by the way, the pointers take double the memory, so older devices will run even slower... time to upgrade!"
It's not just about addressable memory. While you are correct that pointers will generally take double the memory when moving from 32 to 64 bit, storage of pointers is usually a tiny fraction of an applications memory footprint. It *may* impact how much you can fit in a cacheline if you have containers with a lot of pointers (assuming the cacheline does not double with this move, too - I'm only going by the article and it doesn't mention it). So, overall, a fairly negligible downside. Note that there should not be a difference in speed of access of a 32 bit pointer vs a 64 bit pointer (although alternate pointers in a consecutive range may see a difference, depending on how that mapping is implemented).

The upside is, at the very least: more registers (if the article is correct) - which is often even more important than the capacity of the cacheline! There is some handwaving in the article about things like "more system resources" 🤷🏻‍♂️ Could mean memory (but we don't seem to be close to the limit there, as you say), so there may be other benefits.

But based on access to more registers alone I'd say this is likely to be a net performance advantage for most (if not all) apps.

Of course none of this is straightforward and the reality may look quite different to my speculation, above.
 
Apple has really pushed the bounds of 64 bit computing for sure... but I absolutely do not see any benefit to going all in on 64 bit pointers on apple watch. The latest models have ~1 GB of RAM. They could quadruple that amount and still be fine with 32 bit pointers. I'd be interested to see what they are doing under the hood that truly makes going to 64 bit pointers all that great at this memory footprint that justifies this change - otherwise this feels like a slick way of combinging a 64 bit marketing win with forced obsolesce.

"Look!!! 64 bit stuff... oh by the way, the pointers take double the memory, so older devices will run even slower... time to upgrade!"
“…a slick way of combinging a 64 bit marketing win with forced obsolesce.”

Bingo!
Take the rest of the day off.
 
I'm still trying to get my mind around the necessity of 64-bit with a mere 1GB of RAM.

I'm also wondering when Siri in watchOS on my Series 10 will stop responding with random responses when I'm listening to audio books...I'm sincerely tempted to turn-off Siri on the Watch, as this can be quite distracting....
 
translation: Future Apple watches will have increased memory.
Correct and an updated arm cortex to not support the other version of the tree. They are slowly marching it down the road, with the universal binary idea they have, this is not a huge loss for existing users, while making the new watch feel a lot more snappy with minimal changes.
 
Good to know about the changes. Think the series 7 might stop receiving software update sooner than expected.
 
  • Like
Reactions: mganu
I think this is more about Apple not wanting to have to maintain multiple compilers, not having to test multiple versions of an OS, and the maintaining of different OS patches. Retire the old devices, move everything else to a 64bit OS.
 
  • Like
Reactions: RichardGroves
Will the enhanced performance lead to increased efficiency and thus better battery life? I love my series 10, but an hour of exercise (running) and my battery is toast by evening!
 
Apple has really pushed the bounds of 64 bit computing for sure... but I absolutely do not see any benefit to going all in on 64 bit pointers on apple watch. The latest models have ~1 GB of RAM. They could quadruple that amount and still be fine with 32 bit pointers. I'd be interested to see what they are doing under the hood that truly makes going to 64 bit pointers all that great at this memory footprint that justifies this change - otherwise this feels like a slick way of combinging a 64 bit marketing win with forced obsolesce.

"Look!!! 64 bit stuff... oh by the way, the pointers take double the memory, so older devices will run even slower... time to upgrade!"
It's a whole lot simpler to have a common code base and tool chain, even if that increases binary size by 15% or whatever.

It probably the case that, however they modified the toolchain to support a mixed 64/32 model, that mixed model does not allow for various HW pointer flags, like MTE. So they can pour more time into preserving the model and updating all the tools. Or they can just say "screw it, this is no longer necessary" and switch to the common model.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.