WooSignal's Flutter template for turning a store into an app

A Flutter client for a store that already runs WordPress

Most WooCommerce stores already have a working web checkout, a customer account system and a product catalogue, so the question is usually what a native app adds. This repository is a template rather than a library. It is called Label StoreMax, and it is a complete Flutter application wired to a WooCommerce store through the WooSignal service, with a customer login that goes through WordPress rather than a separate identity system. The documented requirements are short and specific: WooCommerce 3.5 or newer, the WP JSON API plugin at version 5.0 or newer for customer login and registration, Flutter 3.44 with Dart 3.12, and Android Studio or VSCode to run it. The app is built on the Nylo framework, whose documentation for the 7.x line is linked from the project. The value of the template is that the boring parts of a store app are already written, and the trade-off is that some of that wiring runs through a vendor.

Branding and language live in the WooSignal dashboard

Configuration is split across two places, and this is the part that catches teams out. The documentation says you can change the app name, the logo, the default language, the currency and more, and that you can customise the look and feel of the app in the WooSignal dashboard. In other words, the visible identity of the app is a property of your WooSignal account, not of the code you clone. The code holds one key that connects the two: you copy your app key from the dashboard into WOOSIGNAL_APP_KEY in the .env file. The build then reads that value through a generated Dart file, lib/bootstrap/env.g.dart, which is produced by a command and is deliberately not committed to git. That arrangement keeps the key out of version control, but it also means the app you build locally depends on a value that lives in a browser tab on someone else's site. Anyone who cannot reach that dashboard cannot rebrand the app, and the store owner has to keep working in WooSignal even after the code is forked.

Cloning the template and building the first run

The getting started sequence is five steps, and one of them is easy to miss. You download or clone the repository, sign up on WooSignal and link your WooCommerce store, and copy the app key from the dashboard into WOOSIGNAL_APP_KEY in the .env file. The fourth step generates the encrypted environment file that the app reads.

dart run nylo_framework:main make:env

That command produces lib/bootstrap/env.g.dart, and the documentation is emphatic about the consequence of skipping it or repeating an old version. The file is not committed to git, and the app keeps using the previous values until you rerun the command after every change to .env. This is the failure mode to expect in practice: you change a key, you rebuild, and the app behaves as though nothing happened, because the generated file is what the build actually reads. The fifth step is to hit play in Android Studio, and the full walkthrough for iOS and Android is linked from the project documentation. Publishing then follows the standard Flutter deployment guides for the iOS app store and Google Play.

Customer accounts come from WordPress, not from the app

The most important architectural decision in the template is that it does not own the customer. Login and registration are handled by WordPress through the WP JSON API plugin, which is why the plugin appears in the requirements list with a version of 5.0 or newer, and why the app is described as letting customers log in via WordPress. The plugin is not optional if you want accounts, which means the store owner has to install and maintain a WordPress plugin in addition to running the store. The upside is that a customer who already has a WordPress account for the store can use the same credentials in the app, and the app does not become a second, divergent copy of the customer database. The same logic applies to orders: the feature list states that orders show as normal in WooCommerce, so the app does not create a separate order pipeline. What that means for a team is that anything you need to do with orders, refunds or customer records happens in the WordPress admin, and the Flutter code is a storefront and a checkout.

Localization and payment methods are presets in the build

The feature list is short enough to read in one go, and it tells you what you get before you start changing anything. The app is described as app store ready, with simple configuration, product browsing, ordering and customer login through WordPress, adjustable name, logo, default language and currency, light and dark mode, theme customization, and orders appearing normally in WooCommerce. Localization covers twelve languages: en, es, pt, it, hi, fr, zh, tr, nl, de, id and th. Payment methods are preset to Stripe, Cash On Delivery and PayPal. For a store in one of those markets with one of those payment methods, the template is plausibly enough on day one. For anything else, the work is yours, and the documentation does not describe a plugin or hook point for adding a payment provider, so the realistic path is to find the checkout code in the LabelStoreMax directory and extend it. The same applies to shipping rules, tax handling and any backend extension your store relies on.

The template ties your release to a vendor dashboard

Three limitations deserve to be stated plainly. The first is the dependency on WooSignal for configuration. The README describes signing up for free and linking the store, and the dashboard is where the app name, logo, language and currency are changed, so the vendor is part of your build and release process even though the code is open. The second is the plugin dependency for accounts, which adds a WordPress plugin to the critical path of every release and every customer login. The third is the upgrade path, which the documentation does not cover. The releases here are recent and frequent, with v9.0.0 and v9.1.0 both published on 2026-10-12 after v8.2.7 in May 2026, while the default branch is still named 8.x and the repository root holds a single LabelStoreMax directory alongside the README and the licence file. Nobody documents how to move a customised fork from one major version to the next, which is where template-based projects usually lose their value. If you fork this, expect to own the merge.

Two licence statements that do not match

The licence situation needs a second look, because the two places that describe it do not agree. The project is listed under the BSD 2-Clause licence in the repository metadata, while the README states that the Label StoreMax framework is open sourced software licensed under the MIT license. MIT and BSD 2-Clause are both permissive and similar in effect, so the practical difference is small, but a discrepancy like this in a template you intend to fork and ship is worth resolving with the project rather than assuming. Neither statement covers the WooSignal service itself, which is a separate commercial product behind the dashboard, and the plugin you install on the store carries its own terms. The security contact published in the README is a [email protected] address for vulnerability reports. One thing the project does not offer is any guidance on testing, continuous integration or automated release, so those parts of a store app pipeline are yours to build.

Editorial conclusion

Adopt the Label StoreMax template when a store needs an iOS and Android client quickly and the team is willing to configure the app through the WooSignal dashboard and install the WP JSON API plugin on the store. Skip it when branding and configuration must live in your own repository, or when you need payment methods, shipping logic or a checkout flow the template does not implement. Before your first build, confirm that the WooSignal account can link the store, that the plugin is installed for customer login, and that you rerun dart run nylo_framework:main make:env after every change to the .env file, because the app otherwise keeps using the previous values.

Frequently asked questions

Official sources

1. License: BSD-2-Clause
2. Project website
3. README
4. Releases
5. woosignal/flutter-woocommerce-app on GitHub