The editorial argues that the standard Wine/DXVK/MoltenVK/Rosetta stack costs performance, battery life, and debuggability at every layer, and is effectively impossible on non-jailbroken iOS due to sandboxing and JIT restrictions. Transpiling C++ to Swift sidesteps all of it by producing a native ARM64 binary that links directly against Apple frameworks and can be signed for the App Store.
The editorial credits EA's earlier-this-year release of the original C++ source for Generals, Zero Hour, Red Alert, and Tiberian Sun under the GPL as the enabling event. Without raw access to the engine, SAGE-derived rendering path, and scripting system, modders and porters would still be stuck on reverse engineering or clean-room reimplementations.
By shipping a working native port of a large, template-heavy 2003 C++ RTS engine running on macOS, iPhone, and iPad, Reshi's project functions as an existence proof that Fable can handle the messy realities of legacy C++. The port runs natively on ARM64 with no Wine, Rosetta, or MoltenVK in the stack, implicitly arguing the transpiler cleared a high bar.
By submitting the project to Hacker News with framing that emphasizes 'natively ported... using Fable,' the submitter surfaces the transpiler angle as the newsworthy technical claim rather than the game itself. The 497-point score suggests the HN audience validated that framing as the interesting story.
On July 4, Ammaar Reshi published a GitHub repo — `ammaarreshi/Generals-Mac-iOS-iPad` — containing a native port of Command & Conquer: Generals and its Zero Hour expansion running on macOS (Apple Silicon), iPhone, and iPad. The Hacker News post climbed to 497 points in a day, which for a solo port of a 22-year-old RTS is well above the usual nostalgia-tax score.
The port is possible because EA open-sourced the original C++ source for *Generals* and *Zero Hour* earlier this year under the GPL, alongside *Red Alert* and *Tiberian Sun*. That gave modders and porters raw access to the engine, the SAGE-derived rendering path, and the scripting system — no reverse engineering, no clean-room reimplementation.
What makes this port interesting isn't that it exists — it's how it was built: Reshi ran the C++ codebase through Fable, a C++→Swift transpiler, and shipped the output as native Swift compiled for ARM64. No Wine. No Rosetta. No Proton. No DirectX shim running through MoltenVK running through Metal. The game becomes a Swift application that links against Apple's frameworks directly, which is why it runs on an iPad without a translation layer eating battery.
The standard playbook for getting a 2003 Windows C++ game onto Apple hardware is a stack of compatibility layers: Wine translates the Win32 API, DXVK or MoltenVK translates DirectX to Vulkan or Metal, and Rosetta 2 translates x86_64 to ARM64. Each layer costs performance, battery, and debuggability. On iOS, most of that stack is a non-starter anyway — Apple's sandboxing and JIT restrictions make Wine-style approaches effectively impossible on non-jailbroken devices.
Transpilation sidesteps all of it. If you can mechanically convert C++ to Swift with tolerable fidelity, you get a native binary that the App Store will actually sign. The interesting claim buried inside this port is that Fable handled enough of a 2003-era C++ codebase — templates, manual memory management, DirectX-adjacent graphics calls, a proprietary engine — to produce something that boots and plays. That is not a claim most transpilers survive. C++→anything conversion projects tend to die on template metaprogramming, undefined behavior the original code silently relied on, or platform-specific pointer arithmetic.
The historical comparison worth making is with [c2rust](https://github.com/immunant/c2rust) and its C++ cousins — projects that produce technically-Rust output that is functionally unsafe Rust wrapping the original C semantics, requiring extensive manual cleanup to become idiomatic. Reshi's port suggests Fable is at least in the same ballpark of usefulness for actually shipping software, which is a higher bar than academic demos usually clear.
There's also a graphics story here. Generals used a proprietary engine with a DirectX 8/9 render path. Getting that onto Metal without a Vulkan-shaped middle layer means someone — either Fable or Reshi's port code — mapped the render calls to Metal's command buffer model directly. That's the part that would normally take a team six months. If the transpiler is doing meaningful work on the graphics layer too, this stops being a curiosity and starts being a template.
Community reaction on HN focused on two things: whether the port would survive an EA takedown (the source is GPL, so probably yes, though the trademarked assets are a separate question), and whether Fable is a viable path for other legacy Windows titles. The subtext of both threads is the same — developers have wanted a mechanical path off Windows-specific C++ for a decade, and every previous attempt has been either too lossy or too manual to matter.
Most readers aren't porting RTS games. But the pattern generalizes to any team sitting on a C++ codebase they'd rather not maintain in C++: internal desktop tools, plugin ecosystems built on legacy SDKs, cross-platform native apps where the Windows build has drifted years ahead of the Mac build. If a transpiler can convert a real-world proprietary game engine to Swift and produce something that runs, the 'we can't afford to rewrite it' argument for a lot of legacy code just got weaker.
The concrete thing to try, if you have a candidate codebase: pull Fable, point it at a small self-contained module, and see what the output looks like. Not whether it compiles — whether it's *readable*. Transpiler output that no human wants to touch is only useful as a one-time port; transpiler output that a Swift developer can maintain is a migration strategy. That's the distinction that separated c2rust from being a research artifact vs. a serious tool.
The second-order implication is for iOS specifically. The App Store has always been the place where legacy Windows software goes to die, because there is no compatibility layer to hide behind. If mechanical transpilation from C++ to Swift becomes routine, the set of desktop applications that can plausibly ship on iPad expands considerably — and the argument for iPad as a real computing platform gets an unexpected boost from a 22-year-old RTS.
The test isn't whether *Generals* runs. It's whether the next person who tries this on a different C++ codebase — a CAD tool, a DAW, a scientific viewer — gets similar mileage. If Fable's approach holds up across a few more high-profile ports over the next six months, expect to see it referenced in more serious 'rewrite it in Swift' pitches. If it turns out *Generals* worked because Reshi filled in the transpiler's gaps by hand, this stays a cool weekend project. Either way, the Apple Silicon + open-sourced-legacy-code combination is quietly reshaping what 'native port' even means.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.