Battle for Wesnoth is a GPL tactics game with an unmaintained iOS port and an alpha Android port

The default branch is master, and CI runs a second line for 1.18

The repository has no GitHub releases at all. Nothing appears in the release list, so a version number is not something you can point at and expect to download, and there is no release artefact to diff against. What identifies a build is the branch and the commit.

The default branch is master, and the CI badges at the top of the project file are split across two lines: one workflow query for master and one for 1.18. So the project is carrying a stable line alongside the development line. If you are packaging a build or pinning a dependency, the branch name is the only handle you get.

The last push to the repository landed on 2026-11-02, so the tree is being worked on rather than parked. Between those two facts sits the practical consequence for anyone automating a download: there is no release to watch for, so automation has to watch a branch, and a branch moves under you when you pin to its head.

Two build systems sit side by side, CMake and SCons

The top level of the tree carries both CMakeLists.txt and CMakePresets.json, and also SConstruct alongside a scons directory. Two build systems for one C++ project is unusual, and it tells you something about the project's age: one of them predates the other and both are still wired up.

CMake is the modern path, and the presets file means build configurations are defined in the repository rather than passed on a command line. There is a config.h.cmake for generated configuration, and a cmake directory for the modules. The older path is SCons, driven by SConstruct and the scons directory.

Alongside both there are dependency and platform files worth knowing about: vcpkg.json for the Visual C++ package manager, packaging for platform packages, projectfiles for IDE project files, and fastlane for mobile release automation. Contributors are asked for C++14 and later, which is the floor the engine code targets. Instructions for building from source are not in the project file itself but in a separate INSTALL document at the root.

Content is WML and Lua, not C++, and that is the cheaper way in

The contribution guidance is unusually specific about who is actually needed. The project says it is most in need of skilled C++ developers on C++14 and later, then lists what nearly anyone can help with: simple tasks in C++, the Lua and WML used for content scripting, Python used by various external tools, and even play testing and giving feedback on updated campaigns.

That ordering is the useful part. WML is the markup the game data and campaigns are written in, Lua covers scripting, and Python sits in the external tooling. None of those require you to understand the engine's internals or pass a C++ review queue. The map editor ships with multiple tools and hundreds of terrain types and can save and share maps, so the path from an idea to something playable does not require a compiler.

One gap is called out by name: the project lacks art for a variety of unit animations, and asks for help updating existing unit sprites or creating animations through its art contributions forum. If your skill is visual rather than logical, that is a named opening rather than a speculative one.

Source is GPL v2+, but new contributions come in under Creative Commons BY-SA v4.0

The licensing is not one licence. All source code is licensed under the GNU GPL v2 or later. Most art and music is also under the GNU GPL v2 or later. New contributions are now licensed under Creative Commons BY-SA v4.0.

For a player this matters in one concrete way: the assets you can reuse depend on when they entered the project. Older art and music carry GPL terms, newer contributions carry a Creative Commons share-alike licence, and a derived work that mixes both has to respect both. The project points at a wiki page on copyrights for the detailed accounting, and a copyrights.csv file and an update_copyrights script sit at the top of the tree.

For a packager or a distro, the GPL side means source obligations travel with anything you ship, and the GPL v2+ formulation means a later GPL version is permitted rather than locked to version 2.

The Android port covers 1.19 as alpha and the iOS port is frozen at 1.14

Mobile is where the platform story gets uneven, and the project is direct about it. Ports exist for iOS and Android. The iOS port is described as currently unmaintained and covering an older version, 1.14. The Android port is available for 1.19 only, marked alpha.

So the desktop game and the phone game are not the same game at the same version. Someone starting on Android is on an alpha of the 1.19 line, and someone on iOS is on the older 1.14, with nobody maintaining that port.

The macOS App Store listing is a separate matter from the iOS port. The store version is listed among the ways to install the game alongside Steam, itch.io and standalone installers, which makes the desktop macOS build reachable through a store while the iOS port sits unmaintained. Keep those two apart when you check whether Apple hardware is supported.

Five install routes, and Linux gets Flathub rather than an installer

The game runs on Windows, macOS and Linux, and the installation routes differ by platform in a way worth planning around. Steam covers all three. itch.io covers Windows and macOS. The macOS App Store covers macOS. Standalone installers on SourceForge cover Windows and macOS. Flatpak on Flathub covers Linux.

Linux is the odd one out because it has no standalone installer in that list. A Linux user either installs the Flathub Flatpak or builds from source. That is a real difference for anyone packaging for a distribution, since the Flatpak carries its own sandbox and runtime rather than depending on system libraries.

The route also changes what you get. A Steam or itch.io install is a build of the current desktop version, while the mobile ports are pinned as described earlier, and a source build follows whichever branch you checked out. Community content is described as highly moddable, with community created map packs, eras and entire campaigns.

Tests are scheduled as named targets rather than one suite

The build files at the top level show a testing setup built out of several entry points. There is a run_boost_tests script next to a boost_test_schedule, and a run_wml_tests script next to a wml_test_schedule. The WML schedule is the interesting one, because WML is the content language: running the WML tests means checking the campaign and scenario markup rather than the C++ engine.

There is also a Lua linter configuration in .luacheckrc, which covers the Lua side of content scripting, and a .clang-tidy configuration for the C++. So each language in the project has its own gate, and the content tests are separated from the engine tests by design rather than run as one blob.

A cwesnoth.cmd file at the root is the Windows entry point for the engine. Beyond testing, the tree carries data for game content, po and translations directories for localisation, fonts, images and sounds for assets, doc for documentation including the manual, and an attic directory that suggests retired content is kept rather than deleted outright.

Editorial conclusion

Battle for Wesnoth suits a player who wants turn-based tactics with a large community content library and a GPL codebase they can build and modify, and it suits a contributor who wants to write campaigns in WML or Lua rather than engine code. It does not suit someone starting on a phone, because the Android port covers 1.19 only and is marked alpha while the iOS port is unmaintained and frozen at 1.14. Before you commit, check the branch you are building from, since the default is master and CI runs separately for master and 1.18, and read the licensing split on the wiki, because source and older art are GPL v2+ while new contributions land under Creative Commons BY-SA v4.0.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Project website
4. README
5. wesnoth/wesnoth on GitHub