Hearthstone Will Stop Supporting 32-Bit Operating Systems When Patch 36.0 Launches

Published 3 weeks, 5 days ago by (Updated 3 weeks, 5 days ago)

This will likely not be relevant to the majority of you, but if you happen to be one of the few remaining souls who plays Hearthstone on a 32-bit operating system, then... you probably have a lot of other problems unrelated to playing Hearthstone.

But it also means that you won't be able to play the game because it will no longer support 32-bit operating systems when patch 36.0 launches. This seems as good of a time as any to upgrade your operating system if you want to keep playing Hearthstone... and the other numerous benefits that come with not being 32-bit.

Quote From Vyraneer

Hello everyone,

When the Hearthstone™ patch 36.0 is live, we will no longer support the Hearthstone game client for 32-bit operating systems. Players on 32‑bit Windows OS will be unable to launch the game after Patch 36.0.

The vast majority of Hearthstone players are already using a 64-bit operating system, and this change will allow us to focus on making the client as stable and efficient as possible.

If you are using a 32-bit operating system, you will need to upgrade to 64-bit to ensure continued updates and compatibility. Check with your OS maker to find out how to upgrade to a 64-bit operating system and what applications will be affected.

Why We’re Retiring 32-Bit Support

The memory limitations of 32-bit operating systems can impact the playability and stability of many modern games, and 64-bit operating systems have been industry standard for several years already, and as we’re nearing the end of the CATACLYSM cycle, the time is right to make this change for Hearthstone as well.

We recommend updating to the 64-bit version of the game before June 30th, 2026, to ensure your Hearthstone gaming experience is unaffected.

Hearthstone Team

Similar_Content
Blue Post
Remove Ads - Go Premium
Related_Articles
Escape from Violet Hold Card Reveals - Day 11 [Finished]
21 hours ago

Escape from Violet Hold Card Reveals - Day 11 [Finished]

Hearthstone 1
Escape from Violet Hold Card Reveals - Day 10 [Finished]
2 days, 2 hours ago

Escape from Violet Hold Card Reveals - Day 10 [Finished]

Hearthstone 3
Hearthstone Patch 35.6.2 Dev Update Livestream (Notes Inside)
2 days, 20 hours ago

Hearthstone Patch 35.6.2 Dev Update Livestream (Notes Inside)

Hearthstone

// join_the_conversation

Sign in to share your thoughts, vote on comments, and connect with the community.

Sign in Create account

Comments

  • I wonder what their plans are regarding Apple removing support for Rosetta 2 next year.

    Friendly

    • Probably just allow those Macs to run the iOS version. I don't see them developing another version, I feel like there aren't many Mac players.

      Staff

      • Better at least be the iPad version. They do already have a Mac native version, but only for Intel, so they just need to make an Apple Silicon build for it, the Battle.net launcher, and ever single other game that they support on Mac. I hear WoW is Apple Silicon native. Given the fact that Hearthstone uses Unity and runs on iOS/iPadOS, it probably wouldn't even be hard.

        I mean, I play on my Windows PC, but I hate the idea that they would drop Mac support for games that have been supported since the beginning.

        Friendly

        • Yeah it's an odd one for sure. WoW is indeed native, it was one day 1 of the Apple Silicon drop which was awesome to see such a major game come out with that support; Apple definitely worked with Blizzard on it to show the capabilities of the chip.

          Blizzard doesn't just have to update Hearthstone though, the Battle.net Launcher is still not natively supported and runs through Rosetta, as seen below in a screenshot I just took.

          Blizzard has had five years now to support it on the desktop app, what are they holding back for? Granted, the Hearthstone move I imagine will be pretty easy because they are currently using IL2CPP for the iPad and iOS versions of the game, so either just let us use the iPad version (please no) or change your build targets to make an IL2CPP MacOS with probably minimal problems. Though Mono has been supported on Apple Silicon natively for years now, shortly after the new chips dropped, so Blizzard really should be shipping a universal binary for Hearthstone as the transition period happens for the removal of Rosetta; Which is completely possible with Unity builds.

          It would be super bullshit to see the removal of MacOS from Hearthstone. I feel like a move like that they'd have to get way ahead of that announcement and make it known soon because when MacOS 28 drops fall 2027, people need to know they should not update if their games aren't going to work... which is messy because I know Apple said they'd be shipping a stripped down Rosetta 2 in MacOS 28 to help with unsupported games, but who knows what qualifies for that and also how long they even plan to support it. It's not really in their best interest to keep supporting a translation layer as the population of users that is using it keeps declining.

          The move to arm was the best move for them though, I'll always stand behind that (not that we're even arguing about that lol). I would love to see the death of the power hungry x86 architecture that is just as bad as Windows because its trying to stay compatible with too much stuff. I know Intel did announce X86S to remove 16 and 32 bit instruction sets on future CPUs, but they cancelled that not even a year later but formed some council with AMD which maybe will lead to similar things. I'm not even going to get into the whole clock alignment and instruction length thing, but that's a big important architectural difference too between the two.

          I see no reason though why we need to have 16-bit support on modern processors (lol to boot the computer, absolutely insane), and although 32-bit support removal would hurt old games, if you really want to play old games, I don't think it's that crazy to think having an old gaming machine around would be a bad thing; Though emulation/translation would 100% be possible, and I'm sure Microsoft would be first in line to make it happen. I know we wouldn't see wild power reductions or even savings on how much of the die no longer needs to exist, but not having to test legacy stuff would be a win of sorts and any engineering simplicity would be nice. I'd 100% buy into a 64-bit only processor to run Windows and Linux on it, but I'm also a bit of a masochist because I'm willing to game on MacOS hah. The biggest wins would be that Windows could just ditch so much legacy bullshit if they truly wanted to say, hey Windows 12 is now 64-bit only. The bloat removal would be incredible, it would give them more space to add more garbage AI into the OS /s

          I will also say, AMD has been pretty boss with their TDPs. That's one of my big cheers towards Apple with their silicon, they are just so damn power efficient. I've got a Mini PC running Ryzen and their own graphics and it runs stuff quite well. Not AAA 60 FPS well, but considering how power efficient it is, I'm very impressed.

          The fuck did I just go on about?

          • I mentioned the launcher. I wouldn't expect that to require much porting effort. Games like SC, SC2, D3, and HotS use a custom rendering engine that might come with architecture specific optimizations and shit and require a concerted effort to get running on Apple Silicon. So given how much time there is left, I hope they started awhile ago.

            As for Rosetta supporting old games, I thought that was for games where the developer was no longer around or something. They shouldn't have to do that for Blizzard games since they could update their games if wanted to.

            I'm not even sure if Apple Silicon chips have ditched all support for 32-bit instructions on the die. I'd guess so, since macOS hasn't supported 32-bit processes since Mojave, and iOS hasn't supported them for ages either. As for Intel still supporting 16-bit instructions, do you still need that for booting with modern UEFI? I'd guess there are still a lot of people that are using the CSM because, last I heard, Windows refuses to boot from an MBR drive unless you enable that.

            Fixed-width would obviously simplify the decoding logic on the die, and while I'm not an engineer of any kind, I'd not be surprised if that translated to huge power efficiency wins. I have no idea what the hell clock-alignment is. I know about memory alignment, and some archs do allow unaligned access.

            Friendly

            • Yeah the StarCraft and Diablo titles are probably the bigger pain, more so on the StarCraft side due to potential competitive issues if the ports don't go great... if Blizzard even cares at this point? Haha, everyone playing competitively is likely on Windows anyway.

              I do believe you are correct, Rosetta's continued support is only for what is effectively abandonware, and that's a good call on their part because devs should be forced to make their stuff native if they want the audience!

              AArch32 has not been supported on any of the Apple chips which is nice since it was only optional at that point in the v8 reference; M1, M2, and M3 were all based off various ARMv8 specs and M4+M5 moved up into ARMv9.2. Thanks to the folks at Asahi Linux for discovering there is zero native 32 in their exploration, which, makes sense because if Apple had included it, there'd have been no real need for Rosetta and if they included partial instructions.. why? haha. iOS dropped 32-bit apps back in 2017 as well so I suspect the phone chips dropped it the same year for new models.

              You are correct though, UEFI does not require the 16-bit instructions. Purely a silly thing to keep on die for historical compatibility... I suppose someone out there is trying to run some archaic operating system on modern hardware and making it work which likely requires the aforementioned legacy boot option which all boards still support to my knowledge. Still though, who in their right mind is trying to run modern windows on MBR? It's cool that we have a lot of backwards compatibility stuff but it just feels so ick to me.

              And yes, I'm no engineer either, just a bit of a nerd, so my assumptions in power reduction with a fixed-width set of instructions may or may not matter. I can't see a world where there wouldn't be some amount of power efficiency gains, because by nature of the CPU having to run additional logic, you're using more power, but is it really that much? Maybe AMD and Intel can shed some light on that... that would be an interesting question to field them but I'm not even sure where you'd even go for that. Public relations for a shot in the dark?

              I totally misspoke on clock alignment though I meant to say memory alignment and yeah, looking into that, I had no idea modern ARM supported unaligned access just like x86. That was a pretty major difference in architectures between the two so my knowledge was ancient. ARMv6 introduced support for unaligned access which was disabled by default, and then in ARMv8 it was the default for most instructions but it is still controllable.

              https://developer.arm.com/documentation/ddi0338/g/Beieghbg

              https://www.scs.stanford.edu/~zyedidia/docs/arm/armv6.pdf

              "New hardware support for word and halfword unaligned accesses." (This took a while to load)

              https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/Armv8-A%20memory%20model%20guide.pdf

              Now I've got a stupid itch to write assembly.

              • Forgot to mention WC3. I assume that is Intel only as well.

                Also, I edited my last reply to correct a typo, and it isn't being reflected. Might want to look in to that.

                The M-series supporting AArch32 would not do anything for the Rosetta situation as that is there for translating x86-64 code. As for MBR, it would be someone who upgraded an older PC and never converted their drive. Last I know, Microsoft doesn't provide an easy way to convert to GPT without wiping the drive. It can be done, but it requires a few steps I believe. I don't know why the Windows Installer couldn't just convert without data loss.

                The legendary power efficiency on those chips has to come from somewhere. I thought simpler instruction decoding logic would be a big part. Maybe differences between TSMC's and Intel's fabrication process at the same time as well, but I know very little about that.

                Yeah, I didn't remember any specific architectures that allowed unaligned memory access, just knew that some could. With a performance penalty, I'm sure, as it probably replaces the instructions behind the scenes and moves one or two bytes at a time depending on the address and the size of the data. I didn't want to assume anything in case clock alignment was a real thing and that was what you meant. I think actions happen on the leading or trailing edge of the clock pulse. Not sure which, but I bet it would take effort to misalign that.

                Friendly