IronFox: a Mull-style private browser for Android

Continuing Mull rather than restarting it

IronFox is a fork of the Divested Computing Group's Mull Browser, based on Mozilla Firefox, and the README states the goal in one line: to continue the legacy of Mull by providing a free and open source, privacy and security-oriented web browser for daily use.

The lineage explains the project's character. A fork of a fork inherits the configuration work that makes a browser usable day to day, and the heavy lifting in a project like this is rarely the code, it is the thousands of decisions about which features, which defaults and which telemetry.

The project is private, secure and user first by description, and the site is ironfoxoss.org. The community is on Matrix, which the README marks as recommended, and on Discord.

It is worth being precise about what kind of artefact this is. IronFox is not a new browser engine. It is a maintained configuration and build of Firefox for Android with a specific set of privacy defaults, and its value to a user is that those defaults are curated by people who think about them, and its value to a developer is that the build is reproducible and documented.

GitLab is home, three mirrors are copies

The repository layout of a project like this matters more than usual, and the README is explicit about it. IronFox's home is GitLab, at gitlab.com/ironfox-oss/IronFox, and this repository is a read-only mirror of that. The README adds that the project is mirrored to both Codeberg and GitHub.

The three copies exist for different reasons. Codeberg is where the project can exist without depending on a single commercial host, GitHub is where most people will look first, and GitLab is where the work actually happens.

The bug tracker follows the same logic and is somewhere else again. The README asks that issues, bug reports and suggestions go to the unified issue tracker on Codeberg, at codeberg.org/ironfox-oss/bugs/issues. That is a deliberate choice, since a tracker that lives with the mirrors rather than in one of them survives a takedown or a policy change.

The practical instruction for a user is therefore simple: install from the distribution channels, file problems on Codeberg, and read the documentation on the site. And the README goes further than that, with a prominent note urging all users to read the documentation, especially the Limitations and Frequently Asked Questions pages, which is a reasonable thing for a browser to insist on.

Three distribution channels, two package ids

App installation is handled through the download page on the site, and the README shows the three channels the project uses. Accrescent, with the app listed at accrescent.app/app/org.ironfoxoss.ironfox, is one of them. F-Droid is the conventional route, with a repository at fdroid.ironfoxoss.org and a QR code for the F-Droid client. Obtainium is the third, configured through an obtainium link pointing at the updates JSON at releases.ironfoxoss.org.

Two application ids are in play, and the difference matters for anyone automating an install or tracking a nightly. The stable package is:

org.ironfoxoss.ironfox

and the nightly is a separate application:

org.ironfoxoss.ironfox.nightly

That is the standard pattern for a project that ships both, and it means the two can be installed side by side, which is how a developer checks a nightly without replacing the browser they use every day.

The Obtainium configuration in the README is unusually detailed, and it is worth a look for anyone automating this, because it shows the thinking: a preferred APK index of zero, a partial APK hash for matching, a custom User-Agent header so the update site returns the right file, a version extraction regular expression, and a setting to pretend to be Google Play for a store that checks. The project treats the update channel as something to be engineered, not assumed.

Verifying what you downloaded

The README publishes the SHA-256 hash of the signing certificate, and it is the number a user needs in order to check that the build on their device is the one the project produced:

C5:E2:91:B5:A5:71:F9:C8:CD:9A:97:99:C2:C9:4E:02:EC:97:03:94:88:93:F2:CA:75:6D:67:B9:42:04:F9:04

The same hash appears in the F-Droid repository link in the form of a fingerprint, which is how F-Droid clients verify a repository's signing key.

For a browser that handles the most sensitive data on a phone, this is the part of the distribution story that matters most, and the project takes it seriously enough to put the value in the README, in the badge links and in the store configuration at once. A privacy browser distributed through third-party channels is only as trustworthy as the key that signs it, and a reader who does not check is relying on the channel rather than on the project.

The F-Droid and Accrescent channels add a second layer, since those repositories have their own build and signing processes, and a reader who wants the strongest guarantee picks the channel whose signing they can verify end to end.

Building with the Fedora container image

The README recommends using the Docker image for building IronFox, and explains why the build has been made easier and faster: prebuilt versions of the wasi-sdk sysroot and of llvm-project are used instead of building them locally, though the F-Droid builds still build those from source.

The image lives in the project's own registry and is pulled like this:

docker pull registry.gitlab.com/ironfox-oss/ironfox:latest

There is a main tag, which is the image used to build the latest IronFox release, and there are exact version tags, for example:

docker pull registry.gitlab.com/ironfox-oss/ironfox:v135-0

The distinction between latest and main is the interesting one, and it is the kind of distinction that causes trouble when it is not made. latest tracks the tip of the development branch, while main is the image that produced a release, so a build from latest is a development build and a build from main is a release build.

The Dockerfile shows what the image is. It starts from fedora:44, updates the packages, and installs the toolchain: as, bash, ca-certificates, clang, cmake, curl, gawk, gcc, git, jq, m4, make, nasm, ninja-build, patch, perl, shasum, tar, unzip, xz, yq, zip and zlib-devel. The working directory is /app and the default command is a shell. The list reads like a build requirements document, and the version of the base image is what makes the build reproducible, since the packages are updated at image build time.

Building without Docker, on four named systems

The non-Docker path is documented in detail, with an explicit support statement: builds on the latest versions of Fedora, macOS, secureblue and Ubuntu are supported, and your mileage may vary for other operating systems and environments. macOS users must install Homebrew first if they do not have it.

The first step is git, installed per platform with dnf on Fedora, brew on macOS and apt on Ubuntu, and nothing to do on secureblue where it is already present. Then the source is cloned, and the README notes that depth=1 is specified to reduce the size of the cloned repository and can be removed if preferred:

git clone --depth=1 [email protected]:ironfox-oss/IronFox.git IronFox

After that, the bootstrap script, which sets up and installs the dependencies required to build IronFox on the system:

cd IronFox
./scripts/bootstrap.sh

And then the get_sources script, which downloads the external sources the build needs. The README warns that this may take a while depending on network speed, and that if you need a different version of a dependency than the one IronFox currently uses, you have to modify scripts/versions.sh before running get_sources. That ordering is not an accident, since the version file is the input to the fetch step.

The repository layout supports that workflow, with a scripts/ directory for the tooling, a patches/ directory for the changes applied to upstream sources, templates/ and configs/ for the build configuration, tools/ for helper programs, docs/ and assets/ for the documentation and images, plus a .gitlab-ci.yml for the pipeline, a .shellcheckrc for the shell scripts and a pyrightconfig.json for the Python tooling.

AGPL-3.0, a read-only mirror, and a dev branch

The project is licensed under AGPL-3.0, with COPYING.txt at the repository root. For a browser, that is a strong choice and a defensible one, since it keeps modifications to the browser in the open, which is the same instinct that produces the Mull lineage.

The repository itself is a read-only mirror, and the description says so plainly, so it is not the place to send a pull request. The source of truth is the GitLab repository, and the tracker is on Codeberg.

The default branch is dev, and the project has no GitHub releases, which follows from the distribution model. Releases are published as application packages through F-Droid, Accrescent and Obtainium, and the build images are tagged by version, as in v135-0. So the versioning lives in the release channel rather than in the repository, and a reader looking for a release history will find a CHANGELOG.md in the root instead of a list of tags.

The repository is not archived, and the last push was on 2026-10-15. The activity is therefore real, and for a fork of a browser that many people use daily, that continuity is the thing that decides whether it is worth installing.

Editorial conclusion

Adopt IronFox if you want an Android browser with the Mull lineage and a F-Droid and Accrescent distribution model, and read the Limitations and FAQ pages on the documentation site before you commit, because the README urges every user to do exactly that. Do not adopt it expecting the Mull project to continue under its own name, since the fork exists precisely because that did not happen, and do not treat this repository as the place to file bugs, because it is a read-only mirror and the unified issue tracker is on Codeberg. Before you build, note that the recommended path is the container image, that the default branch is dev rather than a release branch, and that the nightly package has a different application id from the stable one.

Frequently asked questions

Official sources

1. ironfox-oss/IronFox on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README