Nylo is a Flutter micro-framework that hands you routing, MVC and a CLI

A micro-framework with an architectural opinion

Nylo describes itself as a micro-framework for Flutter designed to help simplify developing apps. The README is specific about what that means in practice: every project provides a simple boilerplate and an MVC pattern to help you build apps easier.

That single sentence tells you most of what you need to know. A micro-framework is a thin layer over the platform rather than a replacement for it, and an MVC pattern is an opinion about where code lives. You are not getting a new rendering model or a new widget system. You are getting a project skeleton, a routing layer, and a set of conventions, and you keep Flutter itself.

The alternative, which is plain Flutter with the standard project template, is not wrong. It is what most Flutter code in the world is built on, and the platform's own conventions are well understood. Nylo exists for the case where you want the decisions already made and the wiring already in place, especially when you are starting a new app and want to spend your time on the product rather than on the plumbing.

The repository is a Dart project with pubspec.yaml, an analysis_options.yaml, the platform folders android and ios, a lang directory and a test directory, and there is an .env-example file at the top, which tells you the framework expects environment values to be part of the setup.

The project is MIT licensed and the documentation lives at nylo.dev, with a Discord server for questions and a sponsorship option that funds further development.

The feature list is short and concrete

The README lists a set of core features, and each one links to a documentation page.

Routing is the first, and it is the layer that turns a skeleton into an application. Themes and styling come next, followed by localization, which for a Flutter app is a substantial decision about how strings are stored and resolved. There is a CLI for generating project files, described in the README as a tool for generating project files, which is the piece that creates the boilerplate in the first place.

Networking is covered by what the README calls elegant API services, and there is a page for creating app icons, which handles one of the chores every Flutter project has: producing the platform icon sets.

Two more entries round it off. Project configuration covers the settings you would otherwise spread across several files, and a final entry points at the project structure page describing the directory layout the framework produces.

Read as a group, these are the parts of a Flutter project that every team rewrites and that nobody enjoys rewriting. That is a fair summary of the value proposition: not new capabilities, but a decided starting point for the parts that Flutter deliberately leaves to you.

One documentation detail is worth knowing before you go looking for something. The feature list entry for the CLI links to a page whose address ends in metro rather than in cli, so the CLI documentation is filed under a path named after a different tool. The link works, but the naming does not match the feature list.

Getting the boilerplate: clone and read the versioned docs

Installation is a single clone:

git clone https://github.com/nylo-core/nylo.git

The requirement to check before that is Flutter 3.24.0 or newer, which the README lists as the only entry under Requirements.

There is no package to add to a pubspec and no install command, which is a difference from the usual framework. Nylo is not added as a dependency to your app. You take the project it generates, or the repository as a starting point, and the framework code lives inside your application rather than beside it. The lib directory and the pubspec.lock in the repository listing are consistent with that: the framework is your application code, copied into your repository.

That has an obvious consequence for upgrades. There is no dependency resolver step that pulls a newer Nylo into your project. Taking a new release means reapplying whatever changed, which is why the version numbers and the changelog matter more here than they would for a package you depend on.

The documentation is organised by version, with paths under /docs/7.x for the current line, and the CHANGELOG linked from the README for what changed recently. The default branch of the repository is 7.x, which is another sign that the major versions are handled as branches.

Version 7 in the docs, and where the boundaries are

Two limits are visible without testing anything.

The first is the version floor and the branch layout. The documentation is written per major version, the default branch is 7.x, and the changelog link in the README points at a CHANGELOG on the 7.x branch of a repository named framework. That is a lot of moving parts for a project that describes itself as a micro-framework, and it means that reading the docs for the version you actually cloned is a step you have to take deliberately.

The second is the opinion itself. An MVC pattern with a routing layer and a generated directory structure is a decision, and it is a decision your team will live with. Teams that already have a house style for Flutter projects, or that prefer a different separation of concerns, will find themselves working around the framework rather than with it. The same applies to the CLI: it generates the files it expects, and once you have edited them heavily, regenerating is not a simple operation.

There is also a scope limit that the README does not emphasise. Nylo is aimed at mobile applications. The repository contains android and ios folders and no web, desktop or platform folders, and the feature list has nothing about multi-platform output. If you need a project that ships to web or desktop from the same codebase, this boilerplate does not obviously cover it.

Security handling is conventional and worth noting because it is stated. The README asks that security issues be emailed to [email protected] rather than filed in the issue tracker, which is the right practice for a framework that generates project files, since a vulnerability report in a public tracker can expose users before a fix exists.

The alternative, and how to decide

The comparison that matters is with plain Flutter, because that is what the framework is layered on.

Plain Flutter gives you the platform, the standard project template, and the freedom to pick your own routing, state management and directory layout. Everything Nylo provides is a decision you would otherwise make, and the difference in effort depends on how much you would have enjoyed making them.

The trade is direct. With Nylo you get routing, theming, localization, API services, icon generation, a configuration model and a generated structure, and you spend your first hours reading the documentation instead of designing the app. Without it, you keep every choice and every hour of design work.

Two situations favour Nylo clearly. A new app where the team has no established Flutter conventions gets a working structure immediately, and a developer who is new to Flutter gets the pieces of an application that are usually the hardest to discover, such as where localisation strings live and how navigation is wired.

Two situations favour plain Flutter. A team with an existing Flutter codebase will not gain much by grafting an opinionated skeleton on top of a structure they have already settled, and a project that is really a library or a package rather than an application has no use for an app shell at all.

There is a third consideration that is easy to skip: exit cost. Because the framework is copied into your project rather than depended on, you can read all of its code, change it and, in the worst case, delete it. That is a genuine advantage over a package-based framework, and it is the strongest argument for the boilerplate route when the commitment is uncertain.

Releases, licence and how the project is funded

The release history shows a steady cadence with a clear major version boundary. Version 6.10.6 was published on 2025-12-13, version 7.0.0 on 2026-02-06 and version 7.2.2 on 2026-09-23. The last push to the default branch was on 2026-10-18 and the repository is not archived.

The jump from the 6.x line to 7.0.0 in February 2026, with patch releases following on the new line, matches the versioned documentation layout and the branch-per-major structure. For a team that has adopted Nylo, that means the upgrade path is a branch and a changelog rather than a dependency bump.

The licence is MIT, which keeps the commercial and modification questions simple. The README also points to a licence file in the repository, and there is a mismatch worth a glance: the licence link in the README points to a file named licence in the lowercase while the repository listing shows a LICENSE file in the uppercase, which on case-sensitive systems can be the same file or can be a broken link depending on how the repository stores it.

Funding is handled through sponsorship on the project site, and the README is explicit that this is how development is funded. The community is organised around a Discord server described as Q&A and show and tell, and the contributor list in the README shows a broad spread of individual names rather than a single company team.

For anyone considering it, the contributing page is linked in the README and lives in the same versioned documentation, which is where you would find the conventions the framework expects.

Editorial conclusion

Adopt Nylo when you are starting a new Flutter app and want routing, theming, localization, a networking service layer and a project structure already decided, and you are willing to work inside its MVC layout rather than your own. Do not adopt it for an existing Flutter codebase with its own architecture, for a library or package with no application shell, or when the team needs full control over navigation and state management. Before you commit, read the directory structure and configuration pages in the versioned documentation, check that Flutter 3.24 or newer is available on your machines, and clone the repository to see the boilerplate, because the framework's value is entirely in that starting point.

Frequently asked questions

Official sources

1. License: MIT
2. nylo-core/nylo on GitHub
3. Project website
4. README
5. Releases