Generals-Mac-iOS-iPad: Zero Hour on Apple Silicon, iPhone and iPad

What this fork actually is, and who it is for

Command & Conquer Generals: Zero Hour is a 2003 Windows real-time strategy game. This repository compiles the original engine for ARM64 so it runs on Apple Silicon Macs, iPhones and iPads without an emulator. The README is explicit that this is "the real 2003 engine compiled for ARM64", not a reimplementation, and that rendering travels DirectX 8 to DXVK to Vulkan to MoltenVK to Metal.

The work sits on a chain of prior projects: EA's GPL v3 source release, TheSuperHackers' GeneralsGameCode, Fighter19's original Unix port, and fbraz3/GeneralsX. This fork adds the iOS and iPadOS port plus a set of engine fixes. If you already play Zero Hour on Windows and want campaign, skirmish and Generals Challenge on an Apple device, that is the audience. If you want a game you can install once and forget, this is not it, because the README states that no game assets are included or distributed and you must own a copy (the Steam listing is app 2732960).

The README also says the engineering was a human and AI collaboration, with Claude Code writing the C++ and cross-builds while a human directed and playtested. That disclosure matters for how you read the porting notes: the bug descriptions come from device testing, but the repository is a fork maintained by one person, not a studio.

The rendering and input chain, and why iOS made it hard

The engine speaks DirectX 8. An iPad speaks Metal. The path between them is DXVK translating D3D8 to Vulkan, then MoltenVK translating Vulkan to Metal. The README notes that DXVK had never been built for iPhoneOS, which required a Meson cross-build and a patch to its Vulkan loader because iOS confines dlopen to the app bundle. That patch lives at Patches/dxvk-ios.patch and is applied through the local-fork build.

Two other constraints shape the design. First, the engine assumes a writable filesystem wherever it lives, but iOS apps live in a read-only, code-signed bundle, so every config write, cache and save path had to be rerouted and the working directory bootstrapped from the bundle itself. Second, iOS owns the process: the README states that opening the app switcher makes the OS seize the Metal drawable without backgrounding the app, and drawing one more frame means death on resume. The render and simulation loop was changed to hold off in that state.

Input is the part most likely to surprise a desktop player. SDL3 delivers raw touch events, and the RTS semantics on top are new to this fork. Taps defer until the 2003 GUI has processed hover, otherwise menu buttons never highlight. A drag has to decide whether it is drawing a selection box or panning the camera. Long-press became right-click. A cancelled touch must not ghost-click a rally point. The documented touch vocabulary is tap-select, drag-box, long-press deselect, two-finger scroll and pinch zoom.

Building Zero Hour for macOS from the build scripts

The macOS path is the shorter one. The README lists prerequisites installed once: the Xcode command line tools, cmake, ninja, meson and pkgconf from Homebrew, the steamcmd cask, a full vcpkg clone with VCPKG_ROOT exported, and the LunarG Vulkan SDK with VULKAN_SDK exported. The README warns that a shallow vcpkg clone breaks manifest baselines, and that the Vulkan SDK must come from LunarG rather than the Homebrew cask.

xcode-select --install
brew install cmake ninja meson pkgconf
brew install --cask steamcmd
git clone https://github.com/microsoft/vcpkg ~/vcpkg && ~/vcpkg/bootstrap-vcpkg.sh
export VCPKG_ROOT=~/vcpkg
export VULKAN_SDK=$HOME/VulkanSDK/<version>/macOS

With the toolchain in place, the README's clone, build, deploy and asset sequence is four commands. The build script checks dependencies, configures and builds; the deploy script creates ~/GeneralsX/GeneralsZH with a run.sh; the asset script fetches game data you own using your Steam username.

git clone https://github.com/ammaarreshi/Generals-Mac-iOS-iPad.git GeneralsX
cd GeneralsX
./scripts/build/macos/build-macos-zh.sh
./scripts/build/macos/deploy-macos-zh.sh
./scripts/get-assets.sh <your_steam_username>
cd ~/GeneralsX/GeneralsZH && ./run.sh -win

The final line launches the game with a windowed flag. If the build script stops early, the usual causes are the two environment variables above not being visible in the shell that runs it.

The iPhone and iPad build, signing included

iOS adds requirements on top of the macOS prerequisites: a full Xcode signed into your Apple ID, xcodegen from Homebrew, and an Apple Developer team, free or paid. The README's sequence initializes the DXVK submodule used for the iOS dylibs, fetches a pinned and checksummed MoltenVK.framework, stages Liberation fonts renamed the way the game expects, configures the ios-vulkan CMake preset, builds the z_generals target, then packages, signs and installs with your team id.

cd GeneralsX
git submodule update --init references/fbraz3-dxvk
./scripts/build/ios/fetch-moltenvk.sh
./scripts/build/ios/stage-fonts.sh
cmake --preset ios-vulkan
cmake --build build/ios-vulkan --target z_generals
GX_TEAM_ID=<your-team-id> GX_BUNDLE_ID=com.you.generalszh \
    ./scripts/build/ios/package-ios-zh.sh --install

GX_TEAM_ID and GX_BUNDLE_ID are the two variables you must supply, and the README says the team id is found in Xcode under Settings then Accounts. Assets ship inside the app bundle so the install is self-contained, and the --dev flag skips the roughly 2.7 GB asset copy when you are iterating on code. The repository layout confirms the pieces: ios/ holds the XcodeGen signing-stub project and ios/config/ holds a staged Options.ini and dxvk.conf.

Memory pressure on iPad and other documented failure modes

The known issues section records the sharpest limitation: long sessions on iPad can be killed by iOS for memory at roughly 3 GB or more resident, and the app exits to the home screen with no dialog. Session logs, current and previous, are placed in the Files app. There is no in-game warning and no graceful save prompt, so a long skirmish can end abruptly. This is an operating-system constraint rather than a bug in the port, and it is the reason to think twice before treating the iPad build as a marathon platform.

The README's own bug archaeology shows how subtle the failures can be. A minimap rendered black because a 2003 texture-format fallback silently dropped the alpha channel. The EVA voice went randomly mute because one zombie audio stream held a global "don't talk over speech" flag while chirping forever. Both were chased to root cause on a real device and fixed, and the README says the fixes were offered upstream. The existence of that section is also a warning: this is a port of a 2003 engine, and defects of this shape will keep appearing.

One more boundary is legal rather than technical. Because no assets are distributed, the port is useless without a purchased copy of the game, and the asset script takes your Steam credentials to fetch data you already own. The repository's licence field reports NOASSERTION, while the README states the port is built on EA's GPL v3 source release. That combination is worth reading carefully before you redistribute anything.

How this differs from Porting Kit and similar wrappers

The common way to play an old Windows game on a Mac is a compatibility wrapper, and Porting Kit is the name people search for when they want that. A wrapper keeps the original Windows binary and supplies a translation layer underneath it, so the game still thinks it is running on Windows. This project does the opposite: the C++ is recompiled for ARM64, the filesystem assumptions are rewritten for a signed app bundle, and the input layer is replaced with touch semantics. There is no Windows binary in the finished app.

That difference decides which tool fits. A wrapper can often run a game the day you install it, without a toolchain, but you inherit the wrapper's own compatibility gaps and you are still running translated x86 code. A native port can behave better on Apple Silicon and can expose touch controls that no wrapper could invent, but it only exists because someone did the work for this specific title. If your game is not Zero Hour, this repository offers nothing.

The README points at docs/port/PORTING_PATTERNS.md as a generalized methodology for porting classic Windows games to Apple platforms, which is the closest thing here to a reusable alternative. It is documentation, not a tool: you would still be writing the port yourself.

Maintenance, upgrade cost and where to verify first

The repository is not archived and the last push was on 2026-07-05. That is roughly two and a half months before this writing, so the project is recent but there is only one push date to judge by, and no releases were retrieved. Treat upgrade cost as real: the build depends on a vcpkg manifest with a lock file, a pinned MoltenVK framework fetched by checksum, a DXVK submodule plus a local patch, and CMake presets for the ios-vulkan path. Moving any of those forward means re-testing the DXVK and MoltenVK boundary, which is where the rendering translation lives.

On licensing, the README says the port is built on EA's GPL v3 source release, while the repository's declared licence is NOASSERTION and the game assets are explicitly not distributed. The practical implication is that the source lineage carries GPL obligations and the assets carry none of them, because you supply those yourself from a store purchase. That is a description of what the files say, not legal advice; if you plan to redistribute a build, read LICENSE.md and the upstream projects rather than this summary.

The repository ships documentation meant exactly for this kind of check: docs/port/PORTING_PLAYBOOK.md, docs/port/PORTING_PATTERNS.md and docs/port/RELEASE_CHECKLIST.md, plus TESTING.md and SECURITY.md at the top level. The playbook's section 8 is where the black minimap, the silent EVA lines and the chirp are written up. Read it before filing a bug, because the failure you are seeing may already have a root cause recorded there.

Editorial conclusion

Adopt this if you own Zero Hour on Steam, have a Mac with the Xcode toolchain or an iPad you can sideload to, and are comfortable building a C++ project from scripts rather than double-clicking an installer. Do not adopt it if you expect a packaged download: the repository states plainly that no game assets are included or distributed, and the iOS path needs a full Xcode install, xcodegen, an Apple Developer team and a signing identity. Before you start, verify three things: that your Steam account owns app 2732960, that the LunarG Vulkan SDK is installed rather than the Homebrew cask, and that you have read the known issues, which record that long iPad sessions can be killed by iOS for memory at roughly 3 GB or more resident and exit to the home screen with no dialog. The port is real and the playbook documents its bug hunts in unusual detail; those three checks are what separate a working build from a weekend of guessing.

Frequently asked questions

Official sources

1. ammaarreshi/Generals-Mac-iOS-iPad on GitHub
2. Issues
3. README