DEV Community: Roshan Jung Kunwar

Flutter OTA Updates with Shorebird

Roshan Jung Kunwar — Sat, 19 Sep 2026 17:39:00 +0000

Flutter OTA Updates with Shorebird

Why We Needed OTA Updates

We pushed a build with a small logic error. It was a one-line fix.

By the time we noticed, the app was already crashing on our users' devices. Sentry was firing nonstop.

We fixed the code fast. But shipping the fix was slow. The new build took about 8 hours to go live on Android and 12 hours on iOS. The crashes kept happening the whole time.

That's when we knew we needed OTA updates. That's how we found Shorebird.

What is Shorebird?

Shorebird is a code push tool for Flutter. It sends Dart code updates (called patches) straight to your users' phones. No new store release. No store review.

Silent. Patches download in the background. Users don't have to do anything.
Fast. Patches skip store review, so they reach users far sooner than a normal release.
Simple for users. The patch applies the next time the app restarts.

Shorebird patches Dart code only. Native changes, like a new plugin or a new permission, still need a store release.

Getting Started

We run Shorebird in our production app, with two flavors: dev and prod. Here is the setup, step by step.

1. Create an Account

2. Install the CLI

curl --proto '=https' --tlsv1.2 https://raw.githubusercontent.com/shorebirdtech/install/main/install.sh -sSf | bash

Set-ExecutionPolicy RemoteSigned -scope CurrentUser
iwr -UseBasicParsing 'https://raw.githubusercontent.com/shorebirdtech/install/main/install.ps1' | iex

Shorebird CI was deprecated on August 8, 2026. Please switch to the open source package shorebird.

3. Verify the Setup

shorebird doctor

If it works, you'll see something like this:

[~]$ shorebird doctor
Shorebird 1.6.119 • git@github.com:shorebirdtech/shorebird.git
Flutter 3.47.1 • revision 91f8bd75076e9c740aa13cf67eb9ec1a093f68f5
Engine • revision 03e67977a7ff5893d96ac97f22c6a795530c0040

URL Reachability
✓ https://api.shorebird.dev OK (0.5s)
✓ https://console.shorebird.dev OK (1.2s)
✓ https://oauth2.googleapis.com OK (0.2s)
✓ https://storage.googleapis.com OK (0.1s)
✓ https://cdn.shorebird.cloud OK (96ms)

✓ Shorebird is up-to-date (3.2s)
  [!] A new version of shorebird is available! Run `shorebird upgrade` to upgrade.
✓ Xcode project does not override FLUTTER_ build settings (0ms)
1 issue detected.

A new version of shorebird is available!
Run shorebird upgrade to upgrade.
[~]$

That warning is fine. It only means a newer version is available.

4. Log In

shorebird login

This opens a browser window. Log in, then return to your terminal.

5. Add Shorebird to Your App

shorebird init

shorebird create my_shorebird_app
cd my_shorebird_app

6. Keep It Up to Date

shorebird upgrade

Configuring `shorebird.yaml`

After shorebird init or shorebird create, Shorebird adds a shorebird.yaml file to your project root.

# This file is used to configure the Shorebird updater used by your application.
# Learn more at https://shorebird.dev
# This file should be checked into version control.

# This is the unique identifier assigned to your app.
# It is used by your app to request the correct patches from Shorebird servers.
app_id: 864ab1b0-ba78-4b15-990a-a63cec35a41b
flavors:
  dev: 864ab1b0-ba78-4b15-990a-a63cec35a41b
  prod: 6b6e6631-4fbe-4645-8d9d-d5247656d975

A few things to know:

Each flavor gets its own app ID. This keeps dev and prod patches apart.
Your app_id is not a secret. Commit it and share it freely.
Docs: Initialize Shorebird

Releasing and Patching

Shorebird works in two steps: first a release, then patches on top of it.

1. Create a Release

You can't patch until you have a release. This is the build you upload to the Google Play Store or the Apple App Store.

shorebird release android --flavor dev
shorebird release android --flavor prod

shorebird release ios --flavor dev
shorebird release ios --flavor prod

2. Preview the Release

Run the release on a device or emulator before you ship it.

shorebird preview

3. Push a Patch

Fixed a bug in Dart code? Push a patch. It reaches every user on that release version. No store review.

shorebird patch android --flavor dev
shorebird patch android --flavor prod

shorebird patch ios --flavor dev
shorebird patch ios --flavor prod

Tracking Releases in the Console

Releases

Every release and patch shows up in the Shorebird Console. Pick your app to see its releases, and open one to see its patches.

Insights

The Insights tab shows how many people actually use your app.

DAU, WAU, MAU. Daily, weekly and monthly active users, with the change against the previous period.
Time range. Switch between 24h, 7d, 28d, 84d and 12m, or set a custom range.
Compare. Turn on "Previous 28 days" to draw the last period as a dotted line.

Insights count unique device launches. The same device launching twice counts once.

Conclusion

That one-line bug taught us something: writing the fix is the easy part. Getting it to your users is what hurts. With store reviews, a fix can take 8 to 12 hours to go live. In that time, every crash is a real person having a bad day.

Shorebird changed that for us. Setup took one sitting: install the CLI, run shorebird init, and you're ready. After that, the flow is short:

Release the build you send to the stores.
Preview it on a device.
Patch it when something breaks.

Our dev and prod flavors keep test patches away from real users. The Console shows what shipped, and Insights shows how many people are on it.

A few things to keep in mind:

Shorebird patches Dart code only. Native changes still need a store release.
Patches apply on the next app restart, not instantly.
Always try a patch on dev before you push it to prod.

Shorebird is not a replacement for good testing or a proper release process. It is a safety net. When something slips through, you can fix it in minutes instead of waiting a day.

If you ship a Flutter app to real users, set it up before you need it. We wish we had.

Author: https://www.roshankunwar.com.np/posts/ota-updates-in-flutter-with-shorebird-realtime-code-push-silent-updates

Preparing for Your Flutter Interview: A Complete Guide

Roshan Jung Kunwar — Fri, 20 Feb 2026 07:32:04 +0000

Flutter Interview Questions: Beginner to Advanced

🟢 Beginner

What is the difference between Stateless and Stateful Widgets?
What is the difference between final and const?
What is the difference between runtime constant and compile-time constant?
What does main() do vs runApp()?
What is context in Flutter?
What are null-aware operators in Dart?
What is assert() and when is it active?
What is async/await and how does asynchronous programming work in Dart?
What is the difference between a Future and a Stream?
What is the difference between EQUAL (=) and LIKE in a SQL query?
What are the different build modes in Flutter (Debug / Profile / Release)?
What does flutter run --verbose do?
What are Class Constructors in Dart? What types exist?
What is a typedef in Dart?
What is the difference between Expanded and Flexible?

🟡 Intermediate

What is the late keyword and when should you use it?
What are extension methods and when would you use them?
What are mixins and when should you use them?
What are Keys in Flutter? (ValueKey, ObjectKey, UniqueKey, GlobalKey)
What is InheritedWidget and how does it work?
What is setState() and how does it relate to markNeedsBuild()?
What is the Widget lifecycle in a StatefulWidget?
What are the three trees in Flutter? (Widget → Element → Render)
What is the difference between Slivers and regular Widgets?
What are Intrinsic Widgets and when should you use them?
What is a Singleton and why would you use one?
What is Dependency Injection (DI) and why is it useful?
What is the difference between abstract, interface, and sealed classes? When do you use each?
What is the difference between Bloc, Provider, and Riverpod?
What are Freezed and Equatable packages? What is value vs reference equality?
What is Tree Shaking and why does it matter?
Why split-per-ABI when building an Android APK?
What is MVVM vs MVC architecture?
What are SOLID principles and how do they apply to Flutter?
Functional vs class-based Widgets — which is recommended and why?

For full article visit on: https://www.roshankunwar.com.np/posts/preparing-flutter-interview-guide

Flutter Dio Interceptor for Caching API Responses

Roshan Jung Kunwar — Thu, 08 Jan 2026 06:02:11 +0000

Flutter Dio Interceptor for Caching API Responses

In modern mobile applications, providing a seamless user experience even with poor or no network connectivity is crucial. This article demonstrates how to implement a robust caching mechanism for API responses in Flutter using Dio interceptors, ensuring your app remains functional offline by serving cached data when network requests fail.

Mechanism

The caching interceptor works with a straightforward yet effective approach:

Persists GET responses: Only GET method responses are cached, as these typically represent data retrieval operations that are safe to cache
Network-first strategy: When network connectivity is available, the interceptor fetches fresh data from the API
Fallback to cache: If a network error occurs, the interceptor automatically falls back to previously cached responses
Automatic cache updates: Successful responses automatically update the cache for future offline access

Development

Creating the Custom Interceptor

To implement caching with Dio, we need to create a custom interceptor that implements the Interceptor interface and handles three key lifecycle methods: onRequest, onResponse, and onError.

Storage Abstraction

First, let's define a storage abstraction layer that allows flexibility in choosing different storage mechanisms:

/// Simple key-value storage interface for caching
abstract class CacheStorage {
  Future<String?> get(String key);
  Future<void> set(String key, String value);
  Future<void> remove(String key);
}

/// Implementation using SharedPreferences (via AppPreference)
class CacheStorageImpl implements CacheStorage {
  CacheStorageImpl(this._pref);
  final AppPreference _pref;

  @override
  Future<String?> get(String key) async {
    return _pref.getString(key);
  }

  @override
  Future<void> set(String key, String value) async {
    await _pref.setString(key, value);
  }

  @override
  Future<void> remove(String key) async {
    await _pref.remove(key);
  }
}

This abstraction provides a clean interface for storage operations, making it easy to swap implementations (e.g., from SharedPreferences to Hive or secure storage) without changing the interceptor code.

The Cache Interceptor

Here's the complete implementation of the caching interceptor:

import 'dart:convert';
import 'package:dio/dio.dart';

class CacheInterceptor implements Interceptor {
  final CacheStorage storage;

  CacheInterceptor(this.storage);

  @override
  void onRequest(RequestOptions options, RequestInterceptorHandler handler) {
    // Pass through all requests without modification
    handler.next(options);
  }

  @override
  void onResponse(Response response, ResponseInterceptorHandler handler) {
    // Cache only GET responses
    if (response.requestOptions.method.toUpperCase() == 'GET') {
      _saveResponseToCache(response);
    }
    handler.next(response);
  }

  @override
  void onError(DioException err, ErrorInterceptorHandler handler) async {
    // Try to retrieve cached data for GET requests
    if (err.requestOptions.method.toUpperCase() == 'GET') {
      final cached = await _getCachedResponse(err.requestOptions);
      if (cached != null) {
        // Return cached response instead of error
        return handler.resolve(cached);
      }
    }

    // Show no internet modal for network errors
    if (_isNetworkError(err)) {
      await NoInternetModalWidget.show();
    }

    // Propagate the error if no cache available
    handler.next(err);
  }

  bool _isNetworkError(DioException err) {
    return err.type == DioExceptionType.connectionTimeout ||
        err.type == DioExceptionType.sendTimeout ||
        err.type == DioExceptionType.receiveTimeout ||
        err.type == DioExceptionType.connectionError;
  }

  Future<Response?> _getCachedResponse(RequestOptions options) async {
    try {
      final cacheKey = '${options.uri}';
      final cacheEntry = await storage.get(cacheKey);
      if (cacheEntry == null) return null;

      final Map<String, dynamic> decodedCache = jsonDecode(cacheEntry);

      return Response(
        requestOptions: options,
        data: decodedCache,
        statusCode: 200,
      );
    } catch (_) {
      return null;
    }
  }

  Future<void> _saveResponseToCache(Response response) async {
    final cacheKey = '${response.realUri}';
    final cacheEntry = jsonEncode(response.data);
    await storage.set(cacheKey, cacheEntry);
  }
}

How It Works

1. Request Phase (`onRequest`)

The interceptor doesn't modify outgoing requests, allowing them to proceed normally to the API endpoint.

2. Response Phase (`onResponse`)

When a successful response arrives, the interceptor checks if it's a GET request. If so, it saves the response to cache using the complete URI as the cache key:

final cacheKey = '${response.realUri}';

This ensures each unique endpoint has its own cached response, preventing data conflicts.

3. Error Handling Phase (`onError`)

This is where the magic happens. When a request fails, the interceptor:

Checks if the failed request was a GET method
Attempts to retrieve cached data using the request URI as the key
If cached data exists, resolves the error by returning the cached response using handler.resolve(cached)
If no cache exists, propagates the original error using handler.next(err)

The _getCachedResponse method safely handles JSON decoding and returns null if anything goes wrong, ensuring the app doesn't crash due to corrupted cache data.

Usage

Injecting the Interceptor into Dio

To use the cache interceptor, inject it when creating your Dio instance:

import 'package:dio/dio.dart';

class ApiClient {
  late final Dio dio;

  ApiClient(AppPreference appPreference) {
    dio = Dio(
      BaseOptions(
        baseUrl: 'https://api.example.com',
        connectTimeout: const Duration(seconds: 30),
        receiveTimeout: const Duration(seconds: 30),
      ),
    );

    // Create cache storage implementation
    final cacheStorage = CacheStorageImpl(appPreference);

    // Add the cache interceptor
    dio.interceptors.add(CacheInterceptor(cacheStorage));

    // Add other interceptors as needed (logging, auth, etc.)
    dio.interceptors.add(LogInterceptor(
      requestBody: true,
      responseBody: true,
    ));
  }
}

Example API Call

Once configured, your API calls work normally, with caching happening transparently:

class ProductRepository {
  final ApiClient apiClient;

  ProductRepository(this.apiClient);

  Future<List<Product>> getProducts() async {
    try {
      final response = await apiClient.dio.get('/products');
      return (response.data as List)
          .map((json) => Product.fromJson(json))
          .toList();
    } catch (e) {
      // Handle error or rethrow
      rethrow;
    }
  }
}

When network is available, this fetches fresh data and caches it. When offline, it returns the cached response without throwing an error.

Key Benefits

<h3>🔄 Transparent Caching</h3>
<p>No changes required to existing API calls - caching works automatically</p>



<h3>📴 Offline Resilience</h3>
<p>Automatic fallback to cached data during network failures</p>



<h3>🎯 Clean Architecture</h3>
<p>Separation of concerns through storage abstraction</p>



<h3>🔌 Easy Integration</h3>
<p>Simple integration with dependency injection patterns</p>

Advanced Enhancements

Consider extending this implementation with the following features:

Cache Expiration

Add timestamps to determine cache freshness:

Future<void> _saveResponseToCache(Response response) async {
  final cacheKey = '${response.realUri}';
  final cacheData = {
    'data': response.data,
    'timestamp': DateTime.now().millisecondsSinceEpoch,
  };
  final cacheEntry = jsonEncode(cacheData);
  await storage.set(cacheKey, cacheEntry);
}

Cache Size Management

Implement LRU (Least Recently Used) cache eviction:

class CacheManager {
  final int maxCacheSize;
  final CacheStorage storage;

  Future<void> evictOldestCache() async {
    // Implementation for removing oldest cached entries
  }
}

Per-Endpoint Cache Strategies

Configure different caching behaviors for different endpoints:

class CacheConfig {
  final Duration? ttl;
  final bool enabled;

  CacheConfig({this.ttl, this.enabled = true});
}

// Usage
final cacheConfig = {
  '/products': CacheConfig(ttl: Duration(hours: 1)),
  '/user/profile': CacheConfig(enabled: false),
};

Conclusion

Implementing a caching interceptor for Dio provides significant benefits for Flutter applications. This approach offers a robust offline-first experience where users can continue accessing previously loaded content even without internet connectivity.

The storage abstraction pattern ensures flexibility and maintainability, while the interceptor seamlessly handles the complexity of cache management without cluttering your business logic. The network-first strategy ensures users always get fresh data when possible while maintaining functionality during connectivity issues.

This interceptor provides a solid foundation for building resilient Flutter applications that gracefully handle network instability while maintaining excellent user experience. Start with this basic implementation and extend it based on your specific application requirements.

Found this article helpful? Share it with your fellow Flutter developers!

Happy Coding!

Find full article on:
https://www.roshankunwar.com.np/posts/flutter-dio-interceptor-for-caching-api-responses

DEV Community: Roshan Jung Kunwar

Flutter OTA Updates with Shorebird

Flutter OTA Updates with Shorebird

Why We Needed OTA Updates

What is Shorebird?

Getting Started

1. Create an Account

2. Install the CLI

3. Verify the Setup

4. Log In

5. Add Shorebird to Your App

6. Keep It Up to Date

Configuring shorebird.yaml

Releasing and Patching

1. Create a Release

2. Preview the Release

3. Push a Patch

Tracking Releases in the Console

Releases

Insights

Conclusion

Preparing for Your Flutter Interview: A Complete Guide

Flutter Interview Questions: Beginner to Advanced

🟢 Beginner

🟡 Intermediate

Flutter Dio Interceptor for Caching API Responses

Flutter Dio Interceptor for Caching API Responses

Mechanism

Development

Creating the Custom Interceptor

Storage Abstraction

The Cache Interceptor

How It Works

1. Request Phase (onRequest)

2. Response Phase (onResponse)

3. Error Handling Phase (onError)

Usage

Injecting the Interceptor into Dio

Example API Call

Key Benefits

Advanced Enhancements

Cache Expiration

Cache Size Management

Per-Endpoint Cache Strategies

Conclusion

Configuring `shorebird.yaml`

1. Request Phase (`onRequest`)

2. Response Phase (`onResponse`)

3. Error Handling Phase (`onError`)