shoutem.github.io: the documentation site behind the Shoutem extension platform

A Jekyll site, not the platform

The repository name gives away what this is. The shoutem.github.io repository holds the source of the website that serves the Shoutem developer portal, and the top-level listing is unmistakably a static site: a Gemfile and Gemfile.lock, a _config.yml, _includes/ and _layouts/ for the Jekyll templates, _sass/ and css/ for styling, a js/ and lib/ directory for scripts, an img/ directory for images, fonts/, static/ and video/ for assets, plus index.html, favicon.ico, a docs/ directory, a csv/ directory, and a jekyll-static.sh script.

So if you are looking for the Shoutem platform, the React Native application template, or the extension source, they are not here. What is here is the documentation that describes them.

The homepage for the site is shoutem.github.io, and the project description is Supercharging React Native development. The last push was on 2026-08-04, the repository is not archived, and it publishes no GitHub releases, which is normal for a site whose content is deployed from the default branch.

The audience is a developer writing Shoutem extensions, and a contributor who wants to fix or extend the documentation itself. The site is the first thing you open when you are building an extension, so understanding what it contains tells you what you need to know before you write any code.

Extensions as the unit of a mobile app

The platform's central idea is stated in the README as the WordPress for mobile apps. Apps are divided into smaller modules called extensions. On WordPress you build a website out of plugins; on Shoutem you build a mobile app out of extensions, and the README says this architecture is what achieves big development efficiency.

The analogy is doing real work in that description, because it explains the trade-off. A plugin model means a third party can ship a feature without modifying the core, and the host application stays stable while the capability set grows. The same applies to an app builder: the app is a composition of extensions rather than a monolithic codebase, and someone else can contribute a screen, a data source or a theme without touching yours.

The React Native foundation is the other half. The Shoutem app is a React Native app, and the extensions architecture was designed with the goal of not adding overhead over pure React Native. The README states this plainly: if you know React Native you will know how to write Shoutem extensions. For someone starting out with React Native, the project points to React Native School at school.shoutem.com, which is an honest acknowledgement that the platform assumes you already know the underlying framework.

That assumption cuts both ways. If you are coming from native iOS or Android, you are learning two things at once. If you already write React Native, the extension model is a packaging and configuration convention on top of code you could have written directly, and you have to weigh that extra indirection against the reuse you gain from the marketplace.

The marketplace and the fork-everything customisation model

Two practices define how work gets done on Shoutem, and both are about reuse.

The first is the extension marketplace. The README says Shoutem prepared and open sourced a lot of extensions that you can use in your apps, with the instruction not to reinvent the wheel: reuse extensions which are suitable for you, customize them or create new ones. The full list of extensions is in the shoutem/extensions repository, and the repository topics confirm the shape of the ecosystem with shoutem-extensions and shoutem-ui among them.

The second is that all the extensions are open sourced and can be modified by simply forking them, and you can also write your own from scratch. Forking is the escape hatch that makes the marketplace safe to use. A third-party extension that does almost what you need can be forked and adjusted rather than reimplemented, and because the source is public you can see what an extension does before you install it.

This is also where the operational cost sits. A marketplace of forked extensions means the versions of Shoutem extensions in your app can drift apart, and the usual discipline of pinning dependencies and updating deliberately applies with more force than in a normal package tree, because an extension is a fork of a fork once your team customises one.

The tooling around this is what the site documents. There is a Shoutem CLI for extension development, a Shoutem UI toolkit for faster component development, and the developer's portal where the concepts are documented, with the CLI reference and the UI toolkit reference both living under the shoutem.github.io domain.

Getting an account, and where the code actually lives

The README's final section points at the fastest way to start. If you are not already using Shoutem, you can create your account at new.shoutem.com and start developing beautiful mobile apps.

The site itself is hosted on GitHub Pages, given the repository name and the GitHub Pages configuration implied by the .github directory in the listing, and the workflow that puts the built site into production is the jekyll-static.sh script alongside the Gemfile that pins the Ruby dependencies for the build.

For a developer picking this up, the practical sequence is the one the README lays out. Read the developer portal for the concepts, use the CLI to scaffold and manage extensions, and use the UI toolkit for the component layer rather than writing your own from scratch. If you want to build the site locally you would use the standard Jekyll workflow with the bundled Gemfile, and the jekyll-static.sh script is the entry point for generating the static output that gets published.

Two support channels are named. There is a community on Facebook, and a Stack Overflow tag for shoutem questions. Feature requests are handled through issues with the feature requests label, where the README asks people to raise them and upvote the ones they care about, and says that the maintainers will apply an in progress label to the features they decide to implement.

The last line of the README is an invitation to contribute or raise an issue if you find a bug or have a suggestion for improving anything, and for a documentation site that is the most direct route to influence: a corrected command in a guide is a real contribution to the project.

Where this repository is the wrong thing to adopt

Three cases where reaching for this repository is a mistake.

The first is treating it as a framework. It is a documentation site. If you want to build a React Native app with the extension model, the artefacts you need are the Shoutem app template, the extensions repository and the UI toolkit, and this site is the manual for them rather than a component of them. The README's own structure makes the distinction, since the platform description, the marketplace and the tooling all point at other repositories and at shoutem.github.io for the reference pages.

The second is expecting the marketplace to solve your problem. The reuse story is real but bounded, because the extensions are community-maintained and their quality varies, and a fork is only as good as the fork. The README's framing, reuse what suits you, is a description of a catalogue rather than a guarantee of coverage, and the feature request workflow exists precisely because the catalogue has gaps.

The third is assuming the docs are current with your app. This is a documentation site deployed from a branch with no tagged releases, so there is no version stamp telling you which release of the platform a page describes. If you are starting a new app, the versions will usually line up, but if you are maintaining an existing one, the site can describe concepts that have moved on, and the concepts are the part that changes rather than the CLI flags.

There is one more practical detail for anyone who wants to contribute. The site is Jekyll with a Gemfile and a lock file, so the Ruby version and the gem versions are pinned and a build environment has to match. That is a small cost for a documentation contribution, but it is a cost, and it is why a documentation fix is better raised as an issue than attempted blind.

Editorial conclusion

Adopt this repository if you are building Shoutem extensions and need the developer portal, the UI toolkit reference and the extension guides as your reference set, and you want to run or contribute to the documentation site itself. Do not adopt it as an application framework, since the platform and its extension marketplace live in other repositories, and do not expect the site to be a package you consume from npm. Verify first that the documentation version you read matches the Shoutem app template you are targeting, since the site is versioned by the commit history rather than by a published release, and that the CLI and UI toolkit you install match the concepts the pages describe.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. shoutem/shoutem.github.io on GitHub