Battle.net for Mac: 56 Intel Binaries, Zero ARM64, Six Years After M1
Mac users have asked Blizzard one technical question for years: when will Battle.net and Agent stop requiring Rosetta?
Blizzard’s public answer is still “actively investigating and planning.” The forums have filled the space around that sentence with predictions, staffing stories, and assurances about what Blizzard will probably do.
I audited what Blizzard ships instead.
I have been following this problem for years, saving the public claims, checking the binaries, and holding this post until the evidence could carry it.
On September 3, 2026, I rechecked the current Battle.net and Agent manifests from Blizzard’s own distribution system and reran the complete census. The final verification covered all 846 macOS-tagged payload entries, their content hashes, every native Mach-O object, and the native dependency links between them.
The result is not ambiguous:
- Battle.net build
2.52.10.17731: 53 native objects - Agent build
2.41.0.9775: three native objects - Total: 56 native objects
- Architecture: 56 thin x86_64
- ARM64: zero
- Universal 2: zero
The separately distributed Battle.net installer, version 1.19.3.3219, is also thin x86_64.
This is not Finder guessing. These are the CPU types recorded in the Mach-O headers Blizzard delivered.
The list includes Battle.net, battle.net-core.framework, Battle.net Helper, Agent, Switcher, Relauncher, both Blizzard Error executables, 16 Qt frameworks, the native Qt and QML plug-ins, Chromium Embedded Framework, CEF graphics libraries, and every other bundled dylib in the manifests.
Current World of Warcraft is already Universal 2. WoW can run natively on Apple Silicon because Blizzard ported it in 2020. The game is not forcing Rosetta onto the supported Mac lifecycle. Battle.net and Agent are.
Directly opening an installed and current WoW client may avoid Battle.net for that session. It does not install the game, apply the next patch, repair damaged data, update Agent, manage product state, or recover a failed update. Calling Battle.net “only a launcher” does not survive contact with the work it performs.
Battle.net is native C++, Qt, QML, and CEF
The Mac client is not React Native or Electron. The current package identifies a native C++ application built around Qt 5.15.1, QML, a Blizzard-patched CEF/Chromium 108 branch, Blizzard’s native core, and a separate Agent containing the TACT installation and patching machinery.
An ARM64 process cannot load an x86_64 framework or dylib. Blizzard has to rebuild, replace, remove, or isolate every Intel library loaded inside an ARM64 process. Compiling the top-level executable alone would produce an app that dies before its window appears.
That is real work. It is also ordinary platform migration work that Apple documented in 2020.
The blocker has a filename
Vague talk about “legacy dependencies” is no longer necessary. The strongest visible blocker is:
battle.net-core directly loads libvivoxsdk.dylib and libortp.dylib through strong LC_LOAD_DYLIB commands.
Both libraries are thin x86_64. The Vivox library reports 5.7.0.33710.368a1204 macOS x86_64. The oRTP library reports oRTP-0.14.0.
dyld resolves those libraries before Battle.net reaches normal application logic. Disabling the voice button after startup will not solve it because startup already required the Intel libraries.
Blizzard has four straightforward engineering choices:
- Build the Mac core without Battle.net voice.
- Make voice optional at load time.
- Move voice into a separate Intel helper while macOS 27 still provides Rosetta.
- Replace the dependency or obtain a vendor-supported ARM64 build.
Unity’s current Vivox documentation still warns that its macOS Apple Silicon target requires Intel64. That documentation cannot establish what Blizzard may obtain privately from the vendor, but it confirms that Vivox is a credible dependency problem.
It cannot explain why the installer, updater, UI framework, Chromium runtime, crash reporter, and every unrelated native component remain Intel-only. If an optional voice feature pins the entire Mac install-and-update chain to x86_64, the dependency graph is the bug.
Blizzard is still rebuilding this code
The installer is old. Its metadata identifies Xcode 10.1 and the macOS 10.14 SDK.
The live application is not sitting untouched beside it. Six current first-party objects were linked against the macOS 14.2 SDK shipped with Xcode 15.2:
- Battle.net
battle.net-core- Battle.net Helper
- Relauncher
- Agent
- Switcher
Blizzard is rebuilding first-party Mac code with an Apple Silicon-capable SDK and shipping the result as x86_64 only.
One compiler checkbox will not finish the migration. Qt, CEF, Vivox, oRTP, helpers, architecture-specific Chromium resources, signing, notarization, crash symbols, updater compatibility, and QA all have to move together.
The shipped evidence also rules out one abandoned binary that nobody can compile. The current product has active first-party build lanes. ARM64 simply is not among their shipped outputs.
CEF added Apple Silicon support upstream in M88 during December 2020. Battle.net reports a Blizzard-patched Chromium 108 lineage. Qt fully supported Apple Silicon in Qt 6.2 during 2021, with ARM work also documented for the Qt 5.15 line.
Blizzard may carry private patches. Its exact CEF build may fail in exciting and terrible ways on ARM64. Qt 5.15.1 should not be assumed to compile unchanged. None of that is shocking. That is what dependency owners, CI machines, compiler errors, and migration branches are for.
Six years is enough time to find out which error appears first.
The usual replies fail on the binaries
“Rosetta still works.”
Yes. Apple says macOS 27 is the final release with general-purpose Rosetta. Starting with macOS 28, the remaining support is limited to certain older, unmaintained games that depend on Intel frameworks. A maintained installer, updater, authentication client, and storefront should not bet its future on an exception for unmaintained games.
“Battle.net is optional.”
Not for a clean install, supported updates, repair, Agent self-update, and recovery from a failed patch. A workaround for launching today’s installed game is not a delivery plan for tomorrow’s build.
“There may be private dependencies you cannot see.”
Correct. That is why I am not claiming the entire product is a one-click recompile or promising a global release date from outside Blizzard. Unknown private work does not alter the architecture of the 56 native objects Blizzard currently ships. If another blocker exists, Blizzard can name the component without publishing source code.
“Blizzard still supports Intel Macs.”
That is what separate architecture packages and Universal 2 are for. Intel support does not require Apple Silicon customers to execute Intel code.
“A production client needs more QA than a prototype.”
Obviously. Blizzard owns the source, CI, signing credentials, updater protocol, crash telemetry, backend routing, and current maintainers. Those advantages are the reason a native canary is a credible four-week target inside Blizzard even though an outsider cannot promise full production rollout.
“Mac is a small market.”
That can be a business priority argument. It is not a technical explanation, and it does not match years of calling the Mac client supported while leaving the required distribution software on a compatibility layer with a published end state.
What two serious sprints look like
I would take the month-long bet on a signed ARM64 canary, not a fake promise of instant worldwide rollout.
Sprint one gets an ARM64 build onto clean Apple Silicon hardware. Rebuild Battle.net, core, Qt, CEF, helpers, Agent, Switcher, Relauncher, crash reporting, and every in-process library. Remove or isolate the Intel voice dependency. Sign and notarize the nested bundle. Prove install, login, MFA, embedded web content, game installation, update, repair, self-update, crash handling, and uninstall.
Sprint two tries to kill it. Test existing installations, interrupted downloads, rollback, low disk space, sleep and wake, network changes, regional CDNs, multiple accounts, and the supported macOS and hardware matrix. Verify ARM64 crash symbols. Route one percent of Apple Silicon users to the new package, then expand only after the install, login, update, and crash numbers hold.
Keep the current x86_64 package as a signed fallback and put architecture routing behind a server-side kill switch. Do not identify hardware with uname alone while the old client is translated. Use sysctl.proc_translated or another hardware-aware check.
This plan does not require a Swift rewrite, a Qt 6 migration, a new visual design, or a single giant Universal 2 package on day one. It requires Blizzard to treat ARM64 as a release target and stop allowing one Intel dependency to dictate the architecture of everything around it.
Six years moved this above the individual engineer
Apple announced Apple Silicon in June 2020. WoW shipped native support that November. CEF delivered upstream support in 2020. Qt’s supported path arrived in 2021.
An engineer can identify the blocker. An architect owns the dependency graph. Managers fund the work. Directors handle cross-team and vendor escalation. Product and executive leadership own the promise made to supported customers.
After six years, this is architecture governance debt. Blaming one developer would be lazy and probably wrong. Pretending nobody above that developer owns the outcome would be worse.
Badge color is not evidence
This thread is about Blizzard’s product, not any forum personality or anyone’s résumé.
Claims about Blizzard’s staffing, private priorities, testing practices, and future schedule have appeared repeatedly in Mac threads without public sources. Their accuracy cannot be checked, so they remain personal claims until Blizzard corroborates them.
An MVP can disagree with my conclusion. A badge cannot turn an x86_64 Mach-O into ARM64.
Private contacts do not close a public engineering question because nobody else can verify them. “I’m sure blizzard will make bnet universal eventually” is not a roadmap. “mac issues are always lowest priority to begin with” is not a staffing document. “it’ll just be at last minute like always” is not a release date.
Bring a Blizzard statement, an Apple or upstream document, a binary path, a load command, or a build. Forum rank and confidence are not substitutes.
The same rule applies to me. If the captured census is wrong, identify the ARM64 path in these builds or publish a corrected manifest. If Blizzard replaces the packages tomorrow, excellent. Date the change and ship it.
Seven questions Blizzard can answer without exposing source code
- Will the installer ship as ARM64 or Universal 2?
- Will Battle.net,
battle.net-core, every CEF helper, every Qt/QML native plug-in, and every bundled dylib ship for ARM64? - Will Agent, Switcher, self-update, install, repair, and rollback run without Rosetta?
- What is Blizzard doing with the Intel-only Vivox and oRTP linkage?
- Which other named component blocks ARM64?
- When does the Apple Silicon beta begin?
- Will a clean install, update, repair, authentication, and launch complete without Rosetta on macOS 28?
Hand me the repo Monday morning
I would not start by drawing a new launcher in SwiftUI. I would make the existing build tell me exactly where ARM64 stops.
1. Freeze one release set.
Pin Battle.net 2.52.10.17731, Agent 2.41.0.9775, the installer, every content key, every third-party version, the signing entitlements, and the server manifest that binds them together. A migration cannot be debugged while its inputs move underneath it.
2. Turn the census into a build gate.
Run file, lipo -archs, otool -hv, otool -L, and code-signature inspection over every executable, framework, plug-in, and dylib. Store the dependency graph as a build artifact. The ARM64 channel fails if any in-process dependency lacks ARM64, if a helper launches as Intel, or if a nested signature changes unexpectedly.
That gate replaces “we think everything is native” with a list of paths the linker can prove.
3. Create a separate ARM64 release lane.
Keep the current x86_64 package untouched. Add ARM64 to the real Xcode, qmake, CMake, or internal targets that already build these six first-party binaries. Set an Apple Silicon deployment target, produce independent symbols, and give the ARM package its own manifest and CDN route.
Do not begin with Universal 2. Battle.net ships architecture-specific Chromium resources, including an x86_64 V8 snapshot. A separate ARM64 package avoids pretending two executable architectures are the only files that differ.
4. Remove voice from the critical load path.
The current core strongly loads Vivox and oRTP. For a client that runs with no Rosetta installed, the first ARM64 build either needs ARM64 versions of both libraries or must link without them.
I would ship the first canary with Battle.net voice disabled before I allowed an optional voice feature to block install, update, repair, authentication, and game launch. Voice can return when its ARM64 dependency is ready. The launcher does not get to hold the updater hostage to a voice SDK.
5. Rebuild dependencies from the leaves upward.
Produce the ARM-capable Qt 5.15 LTS libraries and native QML plug-ins first. Build Blizzard’s exact CEF branch next, together with its Helper executable, Chromium resources, ICU data, SwiftShader libraries, sandbox behavior, and ARM64 V8 snapshot. Then build battle.net-core, Battle.net, Relauncher, and crash reporting against those artifacts.
Every successful target becomes an immutable, versioned input to the target above it. Nobody fixes this by dropping random dylibs into an app bundle until the linker stops yelling.
6. Port Agent as a product, not a sidecar.
Agent, Switcher, self-update, install, patch, repair, rollback, and elevation paths get their own ARM64 tests. Validate serialized state, file permissions, path handling, process launch, atomic replacement, and compatibility with games already installed by the Intel Agent.
The native launcher is unfinished if it has to wake an Intel updater.
7. Replace the bootstrapper.
Ship an ARM64 bootstrapper that selects the ARM64 release manifest on Apple Silicon. Detect translated execution with sysctl.proc_translated during migration instead of trusting uname to describe the hardware. The first-run path must not ask a new Mac owner to install Rosetta before it can download the native client.
8. Sign and notarize the first working bundle.
Sign every nested executable, framework, helper, and dylib in the correct order. Preserve only the entitlements CEF and the updater require. Submit the complete package with notarytool, staple it, download it through a quarantine-marked path, and install it on a clean machine.
Signing at the end creates a demo. Signing during the port creates software that can ship.
9. Prove the absence of Rosetta.
Use an Apple Silicon test Mac or VM that has never installed Rosetta. Perform a clean install, login, MFA, embedded web flow, WoW installation, update, scan and repair, interrupted-update recovery, Agent self-update, game launch, crash reporting, and uninstall.
The test fails if macOS requests Rosetta, an x86_64 process appears, or the ARM64 manifest contains an Intel native dependency.
10. Canary the release and keep rollback boring.
Route employees first, then one percent of Apple Silicon users, then 5 to 10 percent after the numbers hold. Compare install success, login success, update success, crash-free sessions, and rollback success with the Intel control. Keep the last signed x86_64 package available behind a server-side kill switch through macOS 27.
At the end of day one I expect a reproducible dependency graph, an ARM64 build lane reaching its first real compiler or linker failure, a written decision on Vivox, named owners for every remaining red target, and a clean definition of done.
A day-one meeting that produces only a migration epic is not progress. The first day should produce an ARM64 object file and an exact list of what prevents the next one.
Mac users have already waited six years. “Eventually” is not an engineering answer.
Ship the Mac client.
Sources
The forum restricts live external links for some accounts. Every address below is therefore presented as copyable text. The source titles are included so each document can also be found independently.
Apple
-
Upcoming changes to Rosetta support
https://developer.apple.com/news/?id=w5ngl9k2 -
Using Intel-based apps on a Mac with Apple Silicon
https://support.apple.com/en-us/102527 -
Building a Universal macOS binary
https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary -
Xcode 15.2 release notes
https://developer.apple.com/documentation/xcode-release-notes/xcode-15_2-release-notes
Blizzard
-
Battle.net on Macs: future compatibility changes
https://us.support.blizzard.com/en/help/article/000385709 -
Mac Support Update, November 16: World of Warcraft Apple Silicon support
https://us.forums.blizzard.com/en/wow/t/mac-support-update-november-16/722775 -
Support ending for Intel-based apps, Battle.net and Agent, post 29
https://us.forums.blizzard.com/en/wow/t/support-ending-for-intel-based-apps-battlenet-and-agent/2298145/29 -
Tahoe 26 added a border to my borderless window, post 14
https://us.forums.blizzard.com/en/wow/t/tahoe-26-added-a-border-to-my-borderless-window/2169098/14
CEF, Qt, and Vivox
-
CEF: Apple Silicon support in M88
https://groups.google.com/g/cef-announce/c/7xkf6tifVVg -
Qt on Apple Silicon
https://www.qt.io/blog/qt-on-apple-silicon -
Qt 6.2 LTS released
https://www.qt.io/blog/qt-6.2-lts-released -
Unity Vivox 16.9 changelog
https://docs.unity3d.com/Packages/com.unity.services.vivox%4016.9/changelog/CHANGELOG.html