Bagisto's Flutter Mobile App: What You Get and What You Configure

A Flutter client for a Bagisto backend, not a standalone store

The repository is a Dart application, and the README frames it as a companion to Bagisto rather than a store in itself. The stated prerequisite is blunt: you need Bagisto v2.0.0 or higher, and the bagisto-api module must be installed and set up on that Bagisto instance. Nothing in the README describes a local catalog, an embedded database, or an offline product source. If you do not already run Bagisto, this repository gives you a UI shell with nothing behind it.

The audience follows from that. It suits teams that already operate a Bagisto store and want a native Android and iOS presence without writing a storefront from scratch. It does not suit someone shopping for a complete commerce platform, because the platform is the other repository. The app covers the customer-facing half: home page and search, product types, dark mode and push notifications, discount coupons and guest checkout, wishlist and categories, order details and reviews. The README lists those as screenshots under Docs/features_images rather than as specification text, so treat the images as the feature inventory and the prose as thin.

Licensing is worth a direct look. The README's License section says Bagisto is open-sourced under the MIT license, but the repository metadata carries no license identifier. Those two facts do not contradict each other so much as leave a gap: the statement is about Bagisto, and the mobile app repository has no declared license file in the metadata. If you plan to redistribute a modified build, resolve that before you ship, and get your own legal read rather than relying on this article.

How the app reaches your store: GraphQL constants and Firebase

The wiring is small enough to describe in full. The app talks to Bagisto through a GraphQL endpoint, declared as a constant in lib/core/constants/api_constants.dart alongside a storefront key and an optional company name. There is no service-discovery layer and no runtime configuration screen documented in the README; the endpoint is compiled in. That means a build is bound to one storefront, and pointing the same binary at staging and production requires separate builds or a code change.

Push notifications run through Firebase. The README tells you to replace google-services.json for Android and GoogleService-Info.plist for iOS, and links to external knowledgebase articles for generating those files. The app does not manage Firebase projects for you. Theme and identity are also compile-time: primary colors live in an AppColors class, the Android app name lives in android/app/src/main/AndroidManifest.xml, and the iOS display name is set in the general tab of the identity settings. The splash image is a file swap at assets/images/splash.png, and the README notes no constant update is needed because the image is loaded directly in lib/features/splash/presentation/splash_screen.dart.

The architecture that emerges is a presentation layer over a remote API, with configuration pushed to build time. That is a reasonable choice for a white-label storefront: fewer moving parts, no admin panel to secure. It also means every storefront variant is a fork or a build flavor, and there is no documented mechanism in the README for swapping endpoints after compilation.

Installing it and getting a first build running

The README lists exact tool versions, and they are not suggestions you can ignore casually. Bagisto v2.0.0 or higher, Android Studio Meerkat | 2024.3.2, Flutter 3.38.9, Dart 3.10.8, Xcode 26.3, Swift 6.1. The README also recommends running a Hello World Flutter program first to confirm the environment works before you start. Take that advice; version pinning this tight is where most first attempts fail.

Start by cloning and pulling packages. The README gives these two commands in sequence.

git clone https://github.com/bagisto/opensource-ecommerce-mobile-app.git
cd <repository-name>
flutter pub get

After flutter pub get resolves the dependency tree from pubspec.yaml, connect a device or start an emulator, then run the app.

flutter run

Before that run produces anything useful, edit the API constants. The README points at lib/core/constants/api_constants.dart and shows the three values to replace. The endpoint example in the README is https://your-bagisto-server.com/graphql, and the storefront key comes from your Bagisto admin panel.

const String bagistoEndpoint = 'YOUR_BAGISTO_ENDPOINT_HERE';
const String storefrontKey = 'YOUR_STOREFRONT_KEY_HERE';
const String companyName = 'Your Company Name';

If you are testing on Android and want push notifications working, replace google-services.json in the Android project. For iOS, replace GoogleService-Info.plist. Without those files the app may still build, but the README ties the notification feature to them, so expect that feature to be inert until they are in place. Minimum platform versions are Android 22 and iOS 15.5, so an older emulator image will not run the build.

The configuration is compile-time, and that shapes your release process

The most consequential limitation is not a missing feature; it is where configuration lives. Endpoint, storefront key, colors, app name, splash image and Firebase credentials are all baked into the build. There is no documented runtime settings screen, no environment file, and no mention in the README of a flavor or scheme mechanism for holding multiple storefronts in one codebase. A team running a staging store and a production store has to manage two builds, and a team running three client storefronts has to manage three.

That constraint interacts with the release cadence. The repository shows releases v2.4.8 on 2026-09-04, v2.4.9 on 2026-09-10 and v2.5.0 on 2026-09-18, with the last push on 2026-09-18. Frequent upstream releases are a benefit if you track main and a cost if you have forked to change hardcoded values, because each upgrade is a rebase against files you have edited. The README does not document a rollback procedure, and it does not document a migration path between app versions. If you fork, you own that merge work.

A second limitation is documentation depth. The README says "For detailed usage instructions, refer to the official documentation" without naming a path in the repository, and the feature list is a set of screenshots. Configuration_guide.md exists at the repository root, but the README does not describe its contents. Anyone evaluating this should read that file directly rather than assume the README is complete. The API side is documented separately at api-docs.bagisto.com under the GraphQL API introduction, which is the reference you will need when the app's requests fail and you want to know why.

Bagisto mobile app versus building on a headless commerce API

The realistic alternative is not another mobile app repository; it is writing your own client against a headless commerce API. The difference is where the work sits. With this project, the screens, navigation, cart flow and checkout UI already exist, and your work is configuration plus rebranding: change the constants, swap the splash and icons, replace the two Firebase files, adjust AppColors. With a from-scratch client, you own every screen, but you also choose your state management, your endpoint strategy, and your release process without fighting hardcoded values.

The trade-off is sharpest around multi-store and multi-tenant setups. The related searches include multi tenant eCommerce platform open source, and this app does not address that pattern in anything the README documents: one build, one endpoint. If you need a single binary that switches storefronts at runtime, this repository is the wrong starting point, and you would be better served building against the Bagisto GraphQL API directly, using the app as a reference for which queries a storefront needs rather than as your base.

The other alternative is a hosted mobile commerce product. The README links live demos on Google Play and the App Store under a Mobikul-branded listing, which suggests a commercial path exists alongside the open source code. That is a real option for teams that would rather pay than maintain a fork, and the README does not compare the two, so the decision is yours to make on cost and control. What the open source repository gives you that a hosted product does not is the Dart source in lib/ and the ability to change any screen.

Upgrade cost, licensing and what to check before you fork

Upgrade cost is driven by two things: the release frequency visible in the repository, and how far you have diverged from upstream. Between 2026-09-04 and 2026-09-18 there were three tagged releases. If you consume them without editing tracked files, upgrading is a pull. If you have edited api_constants.dart, AppColors, AndroidManifest.xml or the splash asset, every upgrade is a merge. The pragmatic move is to keep your customizations in as few files as possible and to record which ones they are, because the README does not provide an override mechanism.

On licensing, the only statement available is that Bagisto is open-sourced under the MIT license. The repository metadata does not declare a license, and the README's License section does not distinguish between the framework and this mobile app. MIT is permissive and generally allows modification and redistribution with the copyright notice retained, but the app repository's own terms are not stated here. If you intend to ship a branded build to app stores, confirm the applicable license for this repository specifically, and take your own legal advice; nothing in this article is legal advice.

Two practical checks belong on your list before you invest. First, confirm your Bagisto install has the bagisto-api module working and that a GraphQL request against your endpoint with your storefront key returns data. Second, read Configuration_guide.md and the Docs/ directory, because the README defers to official documentation for usage and those files are where the detail likely lives. Neither check requires a build, and both can save you from debugging configuration problems inside a Flutter app.

Editorial conclusion

Adopt it if you already run Bagisto v2.0.0 or higher with the bagisto-api module installed and you want a Flutter storefront you can rebrand through AppColors and the AndroidManifest label. Do not adopt it if you have no Bagisto backend: the app is a client, and there is no standalone mode. Before committing, verify three things on your own store: that the GraphQL endpoint answers at the path you put in bagistoEndpoint, that your storefront key resolves, and that Android 22 / iOS 15.5 covers the devices you actually support.

Frequently asked questions

Official sources

1. bagisto/opensource-ecommerce-mobile-app on GitHub
2. Issues
3. Project website
4. README
5. Releases