DEV Community: Pravin Kunnure

Engineering Resilient Flutter Apps That Survive Backend Changes

Pravin Kunnure — Wed, 25 Feb 2026 04:29:18 +0000

Designing mobile systems that remain stable as APIs evolve.

*Mobile apps don’t update instantly.
*
Some users disable auto updates.
Some stay on older versions for months.
Some rarely update at all.

Now imagine this.

*Your backend team:
*
Renames a response field

Changes a required parameter

Modifies authentication logic

Suddenly, thousands of users are using a broken app — and you can’t fix it immediately.

Because mobile apps are long-lived clients.

This is where resilient system design matters.

The Core Problem

Web applications are simple.

You deploy → everyone gets the new version.

Mobile applications are different.

You deploy → some users update.
Others don’t.

*Which means:
*
Your backend must evolve without breaking older mobile versions.

If it doesn’t, you end up shipping emergency hotfix releases.

Mature engineering teams avoid this situation entirely.

How Big Companies Think About This

Companies like Netflix and Uber assume one thing:

Old mobile app versions will exist in production for months.

They design APIs with backward compatibility as a rule — not an afterthought.

*They don’t ask:
*“Will users update quickly?”

*They assume:
*“They won’t.”

That mindset changes everything.

The Architecture Pattern That Prevents Breakage

Here’s a simplified architecture used in resilient mobile systems:

Flutter App
↓
API Gateway
↓
Compatibility Layer
↓
Core Services

The key idea?

The backend adapts — not the mobile app.

Instead of forcing an app update, the server maintains compatibility.

*Principle 1: Add, Don’t Mutate
*
*Safe API evolution rule:
*
✅ Add optional fields
✅ Add new endpoints
✅ Extend responses

❌ Don’t remove required fields
❌ Don’t rename response keys casually
❌ Don’t change response types

*Example:
*
*Old response:
*
{
"user_name": "Pravin"
}

*Instead of renaming it directly, evolve safely:
*
{
"user_name": "Pravin",
"username": "Pravin"
}

Old apps continue working.

No emergency release required.

*Principle 2: Version Your APIs
*
Instead of modifying existing routes:

/api/v1/profile
/api/v2/profile

Old app → stays on v1
New app → migrates to v2

You sunset v1 only after adoption is high enough.

This isolates breaking changes safely.

Principle 3: Send App Version in Every Request

Every Flutter app request should include headers like:

X-App-Version: 1.3.0
X-Platform: android

*Now backend can:
*
Serve compatible responses

Monitor outdated versions

Decide when to deprecate

Roll out changes gradually

This gives you control instead of chaos.

*Principle 4: Use Feature Flags Instead of Hardcoding Logic
*
Instead of hardcoding new features inside Flutter, let backend control behavior.

*Example:
*
{
"enable_new_dashboard": false,
"max_items": 5
}

Now the app adapts dynamically.

*You can:
*
Disable features remotely

Roll out gradually

Avoid urgent releases

Run experiments safely

*Principle 5: Defensive Parsing in Flutter
*
Flutter should never assume APIs are perfect.

*Instead of:
*
final username = json['username'];

*Use:
*
final username = json['username'] ?? json['user_name'] ?? '';

Small defensive decisions prevent large production crashes.

When You Still Need a New Release

Let’s be realistic.

*You must release a new version when:
*
Authentication flow changes

UI structure changes

Security patches are required

Native SDK updates are required

Some changes are unavoidable.

But resilient architecture ensures those releases are planned — not panic-driven.

The Real Engineering Mindset

*Junior mindset:
*
“Backend changed. Release new app.”

*Senior mindset:
*
“Design the system so backend evolution doesn’t break clients.”

Resilience isn’t about avoiding releases forever.

*It’s about:
*
Eliminating emergency hotfixes

Supporting long-lived clients

Designing APIs with discipline

Respecting backward compatibility

That’s what separates feature development from system engineering.

Final Thoughts

Flutter apps don’t break because Flutter is fragile.

They break because backend evolution is careless.

If you understand both mobile and backend systems, you can design applications that survive change — gracefully.

And in real-world production systems, that’s what truly matters.**

{% embed %}
`
**

Flutter Clean Architecture Explained Simply

Pravin Kunnure — Tue, 24 Feb 2026 04:04:37 +0000

Most Flutter apps start simple.

A few screens.
Some API calls.
A bit of state management.

Then features grow.

And suddenly:

Business logic is inside widgets

API calls are everywhere

Models are mixed with UI

Refactoring becomes painful

That’s where Clean Architecture helps.

Let’s break it down in the simplest way possible.

What Is Clean Architecture (In Simple Words)?

Clean Architecture is about one thing:

Separate your app into layers so each layer has one responsibility.

It helps you:

Write scalable code

Test business logic easily

Change backend without touching UI

Avoid messy projects

The 3 Main Layers (Simplified for Flutter)

Forget complicated diagrams.
For Flutter, think of just 3 layers:

Presentation → Domain → Data

Let’s understand each one.

1️⃣ Presentation Layer (UI Layer)

This is your Flutter world:

Screens

Widgets

State management (Bloc / Riverpod / Provider)

ViewModels

What it does:

Displays data

Takes user input

Calls use cases

What it should NOT do:

Call APIs directly

Contain business rules

Talk to database logic

Example:

context.read().login(email, password);

UI doesn’t know how login works internally.
It just triggers it.

2️⃣ Domain Layer (Business Logic)

This is the heart of your app.

It contains:

Entities

UseCases

Repository interfaces

This layer:

Has NO Flutter imports

Has NO API logic

Has NO database logic

It only contains pure business rules.

Example:

class LoginUseCase {
final AuthRepository repository;

LoginUseCase(this.repository);

Future call(String email, String password) {
return repository.login(email, password);
}
}

Notice:

It depends on an abstract repository

It doesn’t know where data comes from

This makes it testable and clean.

3️⃣ Data Layer (API & Database)

This layer:

Implements repositories

Calls APIs

Handles local storage

Maps JSON to models

Example:

class AuthRepositoryImpl implements AuthRepository {
final AuthRemoteDataSource remote;

AuthRepositoryImpl(this.remote);

@override
Future login(String email, String password) {
return remote.login(email, password);
}
}

This is where Dio/http lives.

Why This Structure Is Powerful

✅ Easy to Test

You can test UseCases without UI.

✅ Backend Can Change Easily

Switch from REST → GraphQL?
Only data layer changes.

✅ Large Teams Work Better

UI team works on presentation.
Backend integration team works on data layer.

✅ Code Becomes Predictable

Every feature follows the same structure.

Suggested Folder Structure

lib/
├── features/
│ ├── auth/
│ │ ├── presentation/
│ │ ├── domain/
│ │ ├── data/

Each feature is self-contained.

This scales very well.

Common Mistakes Developers Make

❌ Putting API calls inside widgets
❌ Mixing models between layers
❌ Skipping repository interfaces
❌ Using Clean Architecture for tiny apps (overengineering)

When Should You Use Clean Architecture?

Use it when:

App will grow

Multiple developers are working

You want maintainable code

You care about long-term scalability

Avoid it for:

Small MVPs

Very short-term projects

Final Thoughts

Clean Architecture is not about writing more code.

It’s about writing organized code.

You don’t need 20 folders.
You just need:

Clear boundaries

Proper separation

Discipline

And once your app grows, you’ll be glad you structured it properly from day one.

LIVO Next-Level Flutter State Management

Pravin Kunnure — Mon, 23 Feb 2026 10:47:51 +0000

Flutter is great, but managing state can quickly become messy. You’ve probably used setState for small projects or Provider, Riverpod, or BLoC for bigger apps—but each comes with trade-offs.

⚠️**** Note: This story was originally about reactive_orm, which is now deprecated. Its evolution is now called LIVO. LIVO continues its reactive object-relationship state management approach with improved naming, documentation, and long-term support.

. What is LIVO?

Enter LIVO: a lightweight, reactive ORM-style state management library for Flutter.

It lets your UI react automatically when model properties change — no streams, ChangeNotifier, or boilerplate required.

. With LIVO, you get:

Object-wise and field-wise reactivity
Nested and shared models
Many → One and Many ↔ Many relationships
Minimal boilerplate, plain Dart models

. LIVO in action:

Object-wise: Update any field and rebuild the entire widget
Field-wise: Only rebuild widgets for selected fields
Many → One: Multiple models feeding a single observer
Many ↔ Many: Shared models reflected across multiple parents

. Getting Started:
Add LIVO to your project:
dependencies:
livo:

1️⃣ Creating a Reactive Model

_import 'package:livo/livo.dart';

class Task extends ReactiveModel {
String _title;
bool _completed = false;
String _status = "Idle";

Task({required String title}) : _title = title;

String get title => _title;
set title(String value) {
if (_title != value) {
_title = value;
notifyListeners(#title); // ✅ Symbol-based
}
}

bool get completed => _completed;
set completed(bool value) {
if (_completed != value) {
_completed = value;
notifyListeners(#completed);
}
}

String get status => status;
set status(String value) {
if (_status != value) {
_status = value;
notifyListeners(#status);
}
}
}

✅ This is just plain Dart. LIVO will handle notifying widgets when fields change.

2️⃣ Object-wise Reactivity

_final objectWise = Task(title: "Object-wise Reactivity");

ReactiveBuilder(
model: objectWise,
builder: (task) {
return ListTile(
title: Text(task.title),
subtitle: Text(task.status),
trailing: Checkbox(
value: task.completed,
onChanged: (v) => task.completed = v!,
),
);
},
);_

Here, checking the checkbox triggers a rebuild of the entire widget.

3️⃣ Field-wise Reactivity (Optimized)

Sometimes, you only want specific fields to trigger a rebuild:

_final fieldWise = Task(title: "Field-wise Reactivity");

ReactiveBuilder(
model: fieldWise,
fields: [#completed, #status],
builder: (task) {
return ListTile(
title: Text(task.title),
subtitle: Text(task.status),
trailing: Checkbox(
value: task.completed,
onChanged: (v) => task.completed = v!,
),
);
},
)
_
✅ Only changes to completed or status rebuild the widget. Other fields are ignored.

4️⃣ Many → One (Aggregation)

Combine multiple models into a single reactive observer:

_class Dashboard extends ReactiveModel {
final List sources;

Dashboard(this.sources) {
for (final task in sources) {
addNested(task); // listen to many
}
}
}

final manyA = Task(title: "Task A");
final manyB = Task(title: "Task B");
final dashboard = Dashboard([manyA, manyB]);

ReactiveBuilder(
model: dashboard,
builder: () => Column(
children: [
Text("A: ${manyA.completed}"),
Text("B: ${manyB.completed}"),
],
),
);

Updating manyA or manyB automatically rebuilds the dashboard widget.

5️⃣ Many ↔ Many (Shared Models)

Models can be shared across multiple parents, keeping the UI in sync everywhere:

_class Group extends ReactiveModel {
final String name;
final List tasks;

Group({required this.name, required this.tasks}) {
for (final task in tasks) addNested(task);
}
}

final group1 = Group(name: "Group 1", tasks: [objectWise, fieldWise]);
final group2 = Group(name: "Group 2", tasks: [fieldWise, manyA]);

ReactiveBuilder(
model: group1,
builder: (g) => Column(
children: g.tasks.map((t) => Text("• ${t.title} → ${t.completed}")).toList(),
),
);
_
✅ Updating a task reflects automatically across all groups that include it.
🔹 How LIVO Works

Models extend ReactiveModel
Field setters call notifyListeners(#field) whenever a value changes
ReactiveBuilder widgets listen to either the whole object or specific fields
Nested models propagate changes upward automatically
No streams. No manual wiring. Everything updates safely and efficiently.

🔹 Why LIVO

Clean Dart models with minimal boilerplate
Fine-grained reactivity for optimized performance
ORM-style mental model for easier app design
Works seamlessly for single fields, nested models, or shared models

🔗 Links

Pub Package: LIVO

GitHub Repository

💡 Tip for Readers
Start small: use object-wise for quick prototyping. As your app grows, switch to field-wise or nested models for efficiency.

LIVO makes Flutter state management intuitive and fun — without sacrificing performance.