freeCodeCamp mobile: the same curriculum, in a Flutter app for learning offline

The same curriculum, repackaged for a phone

freeCodeCamp.org is described as an online learning platform offering a comprehensive curriculum in web development and machine learning, which is self-paced and available free of charge, with interactive coding challenges to help learners expand their skills. The mobile app exists to provide more flexibility. The README says the curriculum has been adapted to a Flutter based mobile application, and that the app aims to provide an alternative option for users who are not able to access a computer or a high-speed internet connection, and that it may be useful for those who prefer to learn on the go or need offline access to the curriculum. That last clause is the design brief in one line. The app is not a companion to the website with push notifications, it is the curriculum with a different distribution channel, and the constraint that shapes everything is that the target user may be offline for long stretches.

Two codebases in one repository, a Dart app and a Node API

The repository layout explains the shape of the project. There is a mobile-app directory and a mobile-api directory, and the root package.json is a private package named for the mobile app with a version of 0.0.1, which is a placeholder rather than a shipped version. The scripts show the two halves running side by side. The api build script changes into the mobile-api directory and runs its build, and the api develop script does the same and runs its dev server, while the app develop script changes into mobile-app and runs flutter run. There is a dedicated build runner script for the Dart side that runs the build_runner with the delete-conflicting-outputs flag, which is the code generation step for a Flutter project, and the install scripts mirror that split with npm ci for the API and flutter pub get for the app. A postinstall script runs both installs in parallel, and a prepare script wires up husky, so a single clone and install gets you both halves ready.

The development loop is one command that starts everything

The develop script is the entry point for anyone working on the app, and it is defined in the root package.json alongside the other tasks.

    "develop": "npm-run-all flutter:build-runner -p develop:*",
    "develop:api": "cd mobile-api && npm run dev",
    "develop:app": "cd mobile-app && flutter run",

So the develop command runs the Flutter build runner first and then the develop tasks in parallel, which is how the API and the app start together with the app pointing at the local API. The npm-run-all package provides the parallel and sequential execution, and the root package.json pins it as a dev dependency along with dotenv for environment variables, husky for git hooks and lint-staged for staged file checks. The develop command assumes you have already installed, since the postinstall hook does the install for both directories, and the repository requires Node 24 or newer, with a .nvmrc file recording the version the project uses. There is a renovate configuration for dependency updates, which is the usual way a project of this kind keeps its transitive dependencies current.

CI builds the release, so the app ships from a pipeline

The codemagic.yaml file at the repository root is the clearest signal about how releases happen, because Codemagic is a CI service built for mobile apps. A Flutter application needs a native build for each platform, signing, and store upload, and putting that in a CI configuration rather than in a contributor's laptop is what makes a release reproducible. The release history shows the app shipping on a regular cadence, with v7.5.6 in August 2026, v7.5.5 in July 2026 and v7.5.4 in early July 2026, so the 7.5 line is a mature version rather than an early one. The repository is not archived and the last push was on 2026-10-20, so it is actively worked on. The licence is BSD-3-Clause, with the licence file at the root, and the package manifest is private, which is correct for an application repository rather than a library.

A first-timers-only project, and where the setup instructions live

The README is short and points outward for everything else. It says the freeCodeCamp.org community is possible thanks to thousands of kind volunteers and welcomes all contributions, and it points to the contribution guide for the steps to set the mobile app up locally. The badges are worth reading as a statement of intent rather than decoration, since the project advertises that pull requests are welcome and that it is friendly to first-timers only, and it links the Discord server for people who get stuck. That combination is the point. A project whose contributors are mostly people taking their first steps through open source needs the setup path to be reproducible and the support channel to be easy to find, and the README's brevity is only sensible because both exist elsewhere. The home for the app's contribution documentation is contribute.freecodecamp.org, and the mobile app is also described as freeCodeCamp's open-source mobile app for learning to code from a mobile phone.

What the README does not tell you, and where to look instead

There is a limit to what the repository documentation covers, and it is worth being explicit about the gaps rather than filling them with guesses. The README does not describe the offline mechanism, so how the curriculum is downloaded, cached and invalidated is not something you can learn from it. It does not describe the API's endpoints or its data model, only that a Node service exists alongside the app. It does not list the Dart package dependencies, the state management approach or the test strategy, and the sample data and environment variables are not documented in the readme either. The repository is a working application with a small, focused readme, and the practical route is the contribution guide and the Discord, plus the source of the two directories. For a project that welcomes first-time contributors, that is a deliberate choice, but it does mean you should budget time to read the code rather than expect a tour.

Editorial conclusion

freeCodeCamp mobile fits a developer who wants to contribute to a learning platform's app, especially a Flutter developer looking for a real project with a live audience, or a learner who needs the curriculum offline. It does not fit a team that wants a reference architecture for offline-first apps, since the offline story is a goal rather than a documented architecture, and it does not fit someone who wants a small codebase. Verify first that you have the Flutter and Node toolchain the scripts expect, read the local setup steps in the contribution guide before touching anything, and note that the app version in the repository manifest is a private placeholder while the released app ships under the 7.5 line.

Frequently asked questions

Official sources

1. freeCodeCamp/mobile on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases