Versioning, and Releasing with Digia
This documentation provides a complete walkthrough of how Digia manages versioning, and releasing product updates — from the moment a version is created to the point it’s delivered to users.
It explains each stage of the release funnel in depth — including version creation, staging, review, pre-launch validation, and controlled rollout — helping teams understand both the technical flow and the strategic purpose behind every action.
By the end, you’ll have a complete understanding of how to:
Confidently version your UI and configurations.
Stage and test releases in safe environments.
Strategically roll out new versions.
1. Managing Versions — From Idea to Release
Every project evolves. With Digia, versioning gives you full control — from experimentation to production deployment, all in one place.
What Versioning Means
Versioning in Digia is how you capture, organise, and evolve your app’s progress — without shipping code every time.
Each version acts as a snapshot of your project’s design, logic, and content at a given point.
It lets teams experiment, preview, and iterate independently — all while keeping production stable.
Think of it as your UI source control, purpose-built for dynamic apps.
Creating a Version
Creating a version means saving a checkpoint of your project’s state — ready for safe testing or collaboration.
You give it a version name, optionally add a change log, and Digia instantly stores it as a new working copy.
This helps teams document what changed, why it changed, and who made it.
It’s your first step toward controlled releases and frictionless rollbacks.
How to Create:
Press the Create Version as show bellow
Add a version name and an change log describing what’s new.
Click Create, and your version is instantly ready for staging.
🧠 Pro tip: Keep change logs human-readable — they help your team and QA track updates easily.
Staging a Version
Staging is where your version gets to prove itself in the real world — safely.
You can test layouts, workflows, and data integrations on a staging environment identical to production.
Teams can invite QA, designers, or stakeholders to explore updates interactively before launch.
It’s your sandbox for validation, ensuring everything feels right before going live.
How to Stage:
Go to Version Control → Release to Stage
Deploy to staging to verify layouts, API integrations, and theming.
Here is how you can initialise Digia with you version
void main() async {
WidgetsFlutterBinding.ensureInitialized();
final digiaUI = await DigiaUI.initialize(
DigiaUIOptions(
accessKey: 'YOUR_PROJECT_ACCESS_KEY',
flavor: Flavor.staging(environment: Environment.production),
//flavor: Flavor.versioned(environment: Environment.production, version:1),
strategy: NetworkFirstStrategy(timeoutInMs: 2000),
),
);
runApp(DigiaUIApp(
digiaUI: digiaUI,
builder: (context) => MaterialApp(
home: DUIFactory().createInitialPage(),
),
));
}
Share staging builds with QA or clients for real feedback before release.
🧠 Pro tip: If any issues are found during staging, you can fix the problem, create a new version, and stage it again. The QA team will see the new changes in next app launch.
Checkout Version
The Checkout step allows developers or designers to switch to and work on any existing version. Benefits of checkout feature are-
Seamlessly move between stable and experimental versions.
Ideal for debugging issues, reproducing QA bugs, or continuing feature development.
Analogy: Like checking out a branch in Git — you can explore, test, or fix things safely before merging or staging.
For Checking out version you have to follow these steps
Go to Version Control → Checkout Version
Enter the version Name and press checkout for switching
Releasing a Version (from Digia)
Releasing from Digia means publishing your updates directly to production — instantly, and without sending update by play store and app store.
Once released, your users get the latest UI and logic through the Digia runtime — no store updates needed.
Admins can push, roll back, or gradually roll out versions with full analytics visibility.
It’s the fastest, safest way to keep your apps fresh and your users delighted.
💡 Admin-only: Only authorised admins can trigger production releases.
How to Release:
Open Version Control → Stage Releases → Select the version you want to release
Press the Release to Production button
When you initiate a release, there opens the Release Modal (shown below) for configuring rollout strategies, compatibility, and audience targeting before going live.
This modal provides all the necessary levers for a strategic, data-driven, and safe launch — preventing missteps that could impact your users or analytics.
Key Components of the New Release Modal
Select Version
1️⃣ Choose which staged version (e.g., Version 1.1) you want to release to production.
This ensures only the fully tested and approved build gets deployed.
Minimum Supported Version
Define which app version can receive this release.
2️⃣ Use New — Enforces a higher minimum app version (e.g.,
1.1.2).Use this when you have made changes to the native code interfacing with the Digia SDK and the new version is not compatible with the older app Version. Eg You add a new mandatory page argument to a Digia page which you are opening from native code. Since you do not want this version to break on older releases provide the newer app version.
3️⃣ Use Previous — Keeps compatibility as before.
4️⃣ Previous Version Rollout Info
This area displays the current rollout state of the version that’s already live.
For both Android and iOS, you’ll see whether the existing version is fully rolled out or still in partial deployment.
Why It Matters:
Avoids overlapping releases.
Helps determine if the new version should replace an ongoing rollout.
5️⃣ Rollout Percentage
Defines how many users will receive the new version initially.
Example:
10%— Only a small percentage get the update for early validation.60%— Wider deployment to confident audiences.100%— Full release to all users.
Purpose:
Supports phased rollouts for gradual adoption and data-backed confidence before going all-in.
Once all parameters are configured, click Release to push your version live.
This triggers rollout monitoring, adoption tracking, and (if enabled) internal notifications.
Pre-Release Checklist:
✅ Correct version selected
✅ Rollout percentage intentional
✅ QA and stakeholder sign-offs done
✅ Minimum versions validated
🏬 Releasing to Play Store or App Store
This is reserved for times when you update your native Flutter shell, not the Digia UI itself.
Unlike Digia-driven updates, these require submitting a new build through Google Play or the App Store.
Once approved, your app can still pull live UI updates powered by Digia — reducing how often you need store releases.
In short, the store release updates the container, while Digia releases update the experience.
For Native Releases:
Or Apple’s App Store review process
💡 3. Notes & Best Practices
Keep your Digia workflow fast, stable, and collaborative:
🧠 Version Meaningfully: Use clear version names and detailed change logs.
🧩 Preview Before Stage: Validate every change in the Digia Preview App first.
⚙️ State Matters: Use Global, Page, Component, and Local states wisely for predictable UI behaviour.
💬 Collaborate Before Release: Always notify your team before pushing to production.
🕐 Keep Rollbacks Ready: Stable older versions = instant recovery plan.
✨ Build Faster. Release Smarter.
Digia UI brings agility to app development — letting teams focus on experience, not deployments.
Integrate once, version as you go, and ship updates instantly.
Last updated