DEV Community: flutter

Building a Car Rental Booking Site: Availability Is the Hard Part

Ehsan Abedi — Wed, 28 Oct 2026 17:47:16 +0000

A car rental website looks simple from the outside: pick dates, pick a car, pay. Under the hood, almost every problem comes back to one question: is this car actually free for these dates? Get that wrong and you get double bookings, angry customers at the airport and a team that stops trusting the website.

I'm a freelance WordPress and Flutter developer in Famagusta, North Cyprus, where a lot of small rental companies still take bookings over WhatsApp. Here is how I approach a booking site for them, from a developer's point of view.

Model the fleet, not just "products"

The tempting shortcut is to treat each car as a WooCommerce product with stock. It breaks quickly, because rental stock is about time, not quantity. I usually model it like this:

Car group (e.g. "Economy automatic"): what the customer books, with photos, seats, luggage and transmission.
Vehicle: the physical car with its plate, linked to a group, which can be blocked for service.
Booking: vehicle, pick-up datetime, return datetime, locations, extras, status.

Customers book a group and the system assigns a free vehicle. That way one car in the workshop doesn't make the whole group "sold out" on the website.

The overlap query

Two bookings clash when one starts before the other ends and ends after the other starts. In SQL that is the classic interval check:

SELECT COUNT(*) FROM wp_rental_bookings
WHERE vehicle_id = %d
  AND status IN ('confirmed', 'pending')
  AND pickup_at < %s   -- requested return
  AND return_at > %s;  -- requested pick-up

Small details that matter:

Store datetimes in UTC and convert for display. Rental days cross midnight, and daylight saving changes will bite you otherwise.
Add a buffer after each return (cleaning, fuel, delivery time) before the car is free again.
Count pending bookings too, so two people paying at the same time can't both get the last car.

Prevent the race condition

Checking availability and inserting the booking are two steps. If two requests run between them, both pass the check. Wrap the check and the insert in a transaction and lock the vehicle row (SELECT ... FOR UPDATE on InnoDB), or hold a short reservation that expires if payment isn't completed in, say, 15 minutes. It's boring code, and it's the code that saves the business.

Prices are rules, not numbers

Rental pricing is rarely "price × days". There are seasonal rates, discounts for longer rentals, a minimum number of days, one-way fees and extras like a child seat or full insurance. I keep these as small, testable rules and calculate the total on the server, never only in JavaScript. The customer sees the full breakdown before confirming, which also reduces the "why is it more at the desk?" conversations.

Airport delivery and the booking form

Many visitors here land at Ercan Airport or arrive at the port in Kyrenia. Delivery locations, a delivery fee and a flight number field belong in the booking form itself. A booking that arrives with all the details means one message for the staff instead of five.

Speed and languages

Most people book on a phone, often on roaming data, so the search results page has to be light: real image sizes, WebP, lazy-loading below the fold, and no heavy slider. On a four-language WordPress site I improved homepage PageSpeed from 51 to 75 on mobile and 81 to 97 on desktop without touching the design, mostly through this kind of asset discipline. For languages I use WPML with real URLs per language and hreflang, so the German page can rank for German searches.

Where a Flutter app fits

The website is for customers. The part rental companies love is a small staff app: at pick-up and return the employee takes photos of the car, records fuel and mileage, and the customer signs on the screen. Built in Flutter, it runs on Android and iPhone and talks to the same WordPress database through the REST API, so bookings and check-ins stay in one place.

I wrote a client-facing version of this, for rental company owners rather than developers, here: Car Rental Website Design in North Cyprus.

How do you handle availability in booking systems: database locks, short reservations, or something else?

Özel Yazılım Geliştirme (Web & Mobil Kurumsal Çözümler): Production Architecture & Best Practices 2026 (28.10.2026)

Nuh Mehmet Demirkol — Wed, 28 Oct 2026 15:00:08 +0000

Özel Yazılım Geliştirme (Web & Mobil Kurumsal Çözümler)

Mobil uygulama ekosisteminde ölçeklenebilir ve sürdürülebilir bir sistem inşa etmek için doğru mimari ve mühendislik disiplini şarttır.

1. Mimari Prensipler ve Doğru Teknoloji

Clean Architecture katmanları ile iş mantığını ve UI katmanını birbirinden ayırmak bakım maliyetlerini %60 oranında azaltır. Flutter ile tek kod tabanından iOS ve Android için 120 FPS akıcılık elde edilir.

2. Garanti ve Kod Mülkiyeti

Her kurumsal projede %100 açık kaynak kod, Git deposu ve en az 1 yıllık teknik bakım garantisi sağlanmalıdır.

🚀 İletişim & Proje Teklifi

📌 İlgili Özel Sayfa: Özel Yazılım Geliştirme (Web & Mobil Kurumsal Çözümler)
🧮 Canlı Maliyet Hesaplama: Mobil Uygulama Maliyet Hesaplama
👨‍💻 Bilgisayar Mühendisi: Nuh Mehmet Demirkol
📞 WhatsApp: +90 507 823 68 11 | Ankara, Türkiye

Building DevFeed — Part 4: Shipping v1.0.1 with GitHub Actions and a Changelog

Yadnesh Teli — Wed, 28 Oct 2026 13:00:00 +0000

Series 2 of 2 — Part 4 of 4

Building DevFeed — Part 4: Shipping v1.0.1 with GitHub Actions and a Changelog

Series: Building DevFeed — A Proper Flutter MVVM App from Day One

DevFeed started as a practice project. At some point during development it stopped feeling like practice and started feeling like a real app. That shift happened when I set up the GitHub Actions release workflow and wrote the first changelog entry.

Treating a learning project like a real product — versioning it, writing release notes, automating the build — changes how you think about it.

Why bother with releases for a practice project

The low-stakes answer: Setting up a release workflow on a practice project is good practice for doing it on a real project. You make mistakes when there are no consequences.
The portfolio answer: A versioned changelog shows you think about the full software development lifecycle, not just writing features. It is a small signal that reads clearly to anyone reviewing your work.

The GitHub Actions workflow

I set up two workflows: one for changelog generation on push to main, and one for the release build when a version tag is pushed.

name: Release

on:
  push:
    tags:
      - 'v*'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.x'
      - run: flutter pub get
      - run: flutter build apk --release
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: build/app/outputs/flutter-apk/app-release.apk

Keeping action versions current

My first version used older action versions — actions/checkout@v2 and actions/upload-artifact@v3. GitHub started showing deprecation warnings. I updated all of them to v4 and added an environment variable for the Flutter version to make future updates a one-line change.

This is a small maintenance detail but it matters: deprecated action versions will eventually break your builds. Keeping CI/CD dependencies current is the same discipline as keeping pubspec.yaml current.

Writing the v1.0.1 changelog

The changelog covers the features from the initial commits: in-app WebView for article reading, sharing actions, the INTERNET permission fix, and the ConsumerStatefulWidget refactor.

Writing a changelog for a practice project taught me the value of conventional commits. When every commit starts with feat:, fix:, refactor:, or chore:, generating a changelog is easy. DevFeed's commit history followed conventional commits from the beginning — every commit is changelog-ready.

What done looks like for a learning project

DevFeed does not have user accounts, saved reading lists, or offline support. But it has a working feature set, a clean architecture, a release workflow, and versioned changelogs. It is done in the sense that matters for a learning project — polished enough to show, documented enough to explain, and structured enough to extend.

Wrapping up Series 2

Over four posts, DevFeed went from a full MVVM scaffold on the first commit to a shipped app at v1.0.1. No big refactors, because the architecture was right from the start. Tagging a new version automatically builds a release APK.

The contrast with the shopping app series is the whole point. Series 1 shows you what learning the hard way looks like. Series 2 shows you what applying those lessons looks like. You need both. You need to build the messy version before the clean version makes sense.

Thanks for following along.

I shipped my app to 178 countries in 10 languages. One person outside Korea installed it.

BT_Sun — Wed, 28 Oct 2026 11:29:51 +0000

I'm a solo developer from South Korea. I started coding about seven months ago. Writing in English is still difficult for me, so I use a translator and AI to help.

My app, Party Picker, has 21 party games. Friends use one phone to pick who buys coffee and things like that.

In my last post, I wrote that nobody outside Korea had installed it. Since then, one person has.

What I tried outside Korea

The app is available in 178 countries and regions on Google Play. It supports 10 languages, and the store page is in 10 languages too. I used AI for the translations.

I posted on Reddit and made English YouTube Shorts. I also translated the store pages and ran a Google Play promotion through promotional content in 177 countries.

None of these made a noticeable difference so far.

The numbers in Play Console

I checked Google Play Console on October 28. For the last 28 days, September 30 to October 27, it showed:

About 2,080 store impressions
8 device acquisitions
7 first opens
7 monthly active devices

The store listing report for the last 28 days showed 55 visitors. There were 11 install button clicks, or 20%.

The promotion ran from October 19 to 25 in 177 countries. Seven people saw it. Clicks and conversions still show "no data".

These numbers measure different things. But when I look at them, it feels like I got about 7 or 8 installs in the end. The app is available in many countries, but very few people are finding it.

One user in the Dominican Republic

The country report showed 6 installed users as of October 26: 5 in South Korea and 1 in the Dominican Republic.

I don't know who that person is. I don't know how they found the app either.

There was also 1 device acquisition from Ethiopia on October 12. But that metric counts both new and returning devices. I can't say it was a second person outside Korea, so I'm not adding it to the user count.

Do I need to do more on social media?

I keep wondering if Instagram, Threads, or TikTok needs to be the main way I promote this app to people outside Korea.

This app isn't my only work. I write this blog too, and I'm making three other games. One of them is getting ready for a Steam listing. So I have a lot to think about before adding social media to that work.

The Play promotion didn't bring in many people either. I don't know whether spending more time on social media would help, or how much time I should give it.

I don't have an answer yet.

I'll keep trying outside Korea too

I don't plan to wait until the app does well in Korea before working on other countries. I want to keep trying both.

AI has made the language barrier lower for me. The translations aren't perfect, but I can do more than I could on my own.

Comments on dev.to have helped too. A native Chinese speaker gave me suggestions, and I changed 32 Traditional Chinese strings. I also added a tip about right-to-left languages to my notes.

I can use that help to improve the app. That's part of why I want to keep trying, even with these small numbers.

If you released a small app globally, did social media actually bring you users? If you did it alone, what worked for you?

You can find Party Picker on Google Play.

Real-Time IoT Apps: What a Flutter Hydration Case Study Reveals About Development Partners

Manny Frank — Wed, 28 Oct 2026 10:58:19 +0000

Choosing an IoT development partner involves more than checking whether a team can connect devices. The application also needs to make incoming data understandable.

GeekyAnts’ Curovia case study offers a practical example: a Flutter hydration-monitoring app for football teams.

According to the case study, the application includes:

IoT integration for real-time data capture and analysis.
Team-level and individual-player hydration views.
Graphs, gauges, filters, and CSV export.
Screens implemented from Figma designs.

The main engineering challenge was visualization. The team reported that available Flutter components did not provide the customization needed for the project, so developers built bespoke widgets and modified existing pub packages.

That is a project-specific limitation, rather than evidence that Flutter lacks capable visualization tools.

Companies to evaluate for connected-product development

An unranked shortlist could include:

GeekyAnts: The Curovia example provides evidence of Flutter implementation, device-data integration, and custom visualization.
IBM Consulting: Its published IoT offering addresses connected-asset strategies and integration across IoT, AI, and asset management.
TCS: Its IoT engineering services cover designing and deploying connected solutions.

These are different engagement scopes, so company size or brand recognition alone will not establish suitability.

Questions worth asking before choosing a team

Can the proposed team demonstrate how its interface handles stale readings, disconnected devices, and missing data? Can users distinguish an individual reading from an aggregate? What happens when a visualization package needs modification?

Those are evaluation questions, not capabilities confirmed by the Curovia transcript.

The case study describes development as ongoing and does not specify the device protocol, refresh latency, or measured health outcomes.

The video explains the implementation and visualization work:
https://www.youtube.com/watch?v=FBWaoS4QXsw&utm_source=dis2026

For developers building connected applications, where has the greater challenge been: device integration, data handling, or visualization?

Why your Flutter JSON model crashes at runtime (and how to generate one that doesn't)

Chanpenh Yorn — Wed, 28 Oct 2026 09:37:50 +0000

You write a model, the first API response parses fine, and a week later a crash report says:

type 'int' is not a subtype of type 'double' in type cast

Nothing in your code changed. The data did. Here are the three type errors I see most often with jsonDecode, why they happen, and how to write (or generate) models that survive real responses.

1. `int` vs `double`

Dart's jsonDecode reads the number type from the text. 1.0 is a double, 1 is an int:

import 'dart:convert';

void main() {
  final a = jsonDecode('{"price": 1.0}') as Map<String, dynamic>;
  print(a['price'].runtimeType); // double

  final b = jsonDecode('{"price": 1}') as Map<String, dynamic>;
  final price = b['price'] as double;
  // type 'int' is not a subtype of type 'double' in type cast
}

Many backends drop the .0 for whole numbers, so a price of 3.0 arrives as 3. The safe cast for any field that is "a number with decimals" is:

final price = (json['price'] as num).toDouble();

2. `List<dynamic>` vs `List<String>`

jsonDecode has no idea what your list should contain, so every JSON array becomes List<dynamic>:

final json = jsonDecode('{"tags": ["a", "b"]}') as Map<String, dynamic>;
final tags = json['tags'] as List<String>;
// type 'List<dynamic>' is not a subtype of type 'List<String>' in type cast

Cast each item instead of the list:

final tags = (json['tags'] as List<dynamic>).map((e) => e as String).toList();

Lists of objects work the same way, with fromJson on each item:

final items = (json['items'] as List<dynamic>)
    .map((e) => Item.fromJson(e as Map<String, dynamic>))
    .toList();

3. The key that is only sometimes there

You build the model from one sample response. In that sample every item has a note. In production some items don't, and json['note'] as String throws because the value is null. Any key that can be missing or null needs a nullable type, String?, and a non-required constructor parameter.

The fix is to look at more than one sample. If a key is missing from any item, or null in any item, it's nullable.

A model that handles all three

Given this sample, where the second item has a note and the first doesn't:

{
  "id": 7,
  "price": 1.0,
  "tags": ["new"],
  "items": [
    { "sku": "A1", "qty": 2 },
    { "sku": "B2", "qty": 1, "note": "gift" }
  ]
}

a model that survives real responses looks like this:

class Order {
  final int id;
  final double price;
  final List<String> tags;
  final List<Item> items;

  const Order({
    required this.id,
    required this.price,
    required this.tags,
    required this.items,
  });

  factory Order.fromJson(Map<String, dynamic> json) => Order(
        id: json['id'] as int,
        price: (json['price'] as num).toDouble(),
        tags: (json['tags'] as List<dynamic>).map((e) => e as String).toList(),
        items: (json['items'] as List<dynamic>).map((e) => Item.fromJson(e as Map<String, dynamic>)).toList(),
      );

  Map<String, dynamic> toJson() => {
        'id': id,
        'price': price,
        'tags': tags,
        'items': items.map((e) => e.toJson()).toList(),
      };
}

class Item {
  final String sku;
  final int qty;
  final String? note;

  const Item({
    required this.sku,
    required this.qty,
    this.note,
  });

  factory Item.fromJson(Map<String, dynamic> json) => Item(
        sku: json['sku'] as String,
        qty: json['qty'] as int,
        note: json['note'] as String?,
      );

  Map<String, dynamic> toJson() => {
        'sku': sku,
        'qty': qty,
        'note': note,
      };
}

Decoding {"id": 8, "price": 3, "tags": [], "items": [{"sku": "C3", "qty": 1}]} with it gives price = 3.0 and note = null, with no exceptions.

Generating it

I wrote that model by hand far too many times, so I built a free JSON to Dart generator (disclosure: it's my project). The model above is its actual output for the sample. It:

runs entirely in the browser, so API responses are never uploaded,
reads number types from the raw text, so 1.0 stays a double (JavaScript's JSON.parse would turn it into 1),
merges the keys of every item in an array and makes keys that are missing or null in some items nullable,
outputs plain Dart (no packages), json_serializable or freezed,
can repair a map printed by print() / debugPrint (like {id: 1, name: Ada}) into JSON first.

It does not guess DateTime or enums; dates stay String, so convert those by hand.

If you're debugging one of these errors right now, the guide Flutter JSON Errors: "is not a subtype" Explained covers more of them, including '_Map<String, dynamic>' is not a subtype of type ....

Özel Yazılım Yaptırmak İstiyorum (Şirketlere Özel Otomasyon): Production Architecture & Best Practices 2026

Nuh Mehmet Demirkol — Wed, 28 Oct 2026 08:00:07 +0000

Özel Yazılım Yaptırmak İstiyorum (Şirketlere Özel Otomasyon)

Mobil uygulama ekosisteminde ölçeklenebilir ve sürdürülebilir bir sistem inşa etmek için doğru mimari ve mühendislik disiplini şarttır.

1. Mimari Prensipler ve Doğru Teknoloji

2. Garanti ve Kod Mülkiyeti

Her kurumsal projede %100 açık kaynak kod, Git deposu ve en az 1 yıllık teknik bakım garantisi sağlanmalıdır.

🚀 İletişim & Proje Teklifi

📌 İlgili Özel Sayfa: Özel Yazılım Yaptırmak İstiyorum (Şirketlere Özel Otomasyon)
🧮 Canlı Maliyet Hesaplama: Mobil Uygulama Maliyet Hesaplama
👨‍💻 Bilgisayar Mühendisi: Nuh Mehmet Demirkol
📞 WhatsApp: +90 507 823 68 11 | Ankara, Türkiye

Shipping a Marketplace App to iOS and Android From One Codebase: An Engineering Checklist

Journeyhorizon — Wed, 28 Oct 2026 07:06:37 +0000

Most "native vs cross-platform" threads turn into framework fights. For marketplace apps, the framework is the least interesting part of the decision. The questions that actually move your timeline and budget are these: how many platforms you must hit on day one, how far your UI drifts from stock components, which integrations you can't live without, and how users will find the app at all.

This post turns those questions into a checklist you can run before flutter create or npx create-expo-app. It's based on a longer guide on multi-platform mobile app development for marketplaces from the team at Journeyhorizon, a marketplace development agency.

Why "both platforms on day one" is the default for marketplaces

A marketplace has two sides, and you rarely control which phone either side carries. Android holds roughly 70% of global market share, yet iOS matches or leads in many developed markets and among high-value users. If your sellers mostly carry Android and your buyers mostly carry iPhones (or the other way round), shipping one platform first means half of your market walks into an empty room.

That's why the "launch on one, learn, then port" plan rarely survives contact with a real marketplace roadmap. The economics point the same way: building two separate native apps can cost 30–40% more than a single cross-platform build, and a shared codebase lets one team ship to both stores instead of coordinating two teams or two sequential projects. Time-to-market matters too, because a competitor that lands on both stores first gets to the users first.

Before going further, write down the answers to this:

[ ] Which side of the marketplace is on which platform?
[ ] Can we launch with only one side served? (usually: no)
[ ] Does a competitor already cover both stores?

If the answers push you toward both platforms, the next question is how much code you can realistically share.

Reusability vs customisation: the real trade-off

Frameworks advertise big numbers. Flutter and React Native typically claim 70–90% code sharing. Kotlin Multiplatform takes a different route: it shares business logic but keeps a native UI on each side. Ionic is the comfortable option for teams coming from the web.

The catch is that the sharing percentage is not really a property of the framework. It's a property of your product. Every time you ask for a screen that feels distinctly iOS on an iPhone and distinctly Android on a Pixel, or for heavy custom animation, the shared portion shrinks.

A rough way to place your app:

Product type	Customisation need	What to expect
Booking, local services, resale, SaaS-style tools	Low to moderate	High code sharing
Fashion, design and other highly visual catalogues	High	Lower sharing; plan custom work
AR product previews or deep device features	Very high	Plan platform-specific modules

The architecture that ages well is a foundation that ships fast and accepts extensions: custom plugins and platform-specific features layered on top without forcing a full rewrite. Sharetribe is one example of that pattern on the marketplace side, giving you a proven core you extend rather than replace.

Audit your integrations before you pick a framework

Marketplace apps are integration-heavy. A typical list looks like this:

payments and payouts
shipping labels
push notifications
analytics
fraud detection
CRM sync
industry-specific services for your vertical

Ecosystem depth varies by framework. React Native has the largest library ecosystem. Flutter's is growing but smaller. Kotlin Multiplatform's plugin architecture is still maturing. None of this disqualifies a framework, but it changes your estimate.

A simple exercise: make a table with each required integration, then mark it "official SDK", "maintained community package" or "we build it". Anything in the third column is scope, and scope belongs in the plan, not in a surprise sprint three weeks before launch.

integration        | flutter   | react-native | decision
-------------------|-----------|--------------|---------
payments           | ?         | ?            |
push               | ?         | ?            |
fraud detection    | ?         | ?            |
<niche vertical>   | ?         | ?            |

Fill the question marks with what you actually verify, not what you remember from an old blog post. If you're building on Sharetribe, much of this foundation is already in place and custom integrations can be commissioned on top. A standalone app means more hands-on integration work, or a partner who has done it before.

Discoverability is part of the architecture

This is the part engineers tend to skip. A well-built app nobody finds is still a failed launch. App store optimisation, user acquisition, SEO, content and brand authority matter as much as frame rates.

Growth strategy should influence technical choices from the start:

SEO-driven acquisition means you need crawlable web surfaces: structured data and category pages that can rank, not only a mobile binary.
Word-of-mouth growth shifts weight toward in-app referral mechanics, deep links and share flows.

Treat these as requirements in sprint one, not marketing tasks for month six. Organic growth that is planned early is what makes scaling sustainable instead of expensive.

Where AI and custom features fit

Shipping a decent cross-platform app is now the baseline. Differentiation is moving to AI-driven personalisation, recommendations, fraud detection, intelligent search, automation and custom workflows.

Cross-platform frameworks handle calls to AI APIs, such as a recommendation engine or an image recognition service, without much friction. Things get harder when you want custom AI experiences or models trained on your own product data; those usually need specialised development or platform-specific optimisation. Budget for that separately from "build the app".

A decision matrix you can paste into your ADR

IF  first mobile product AND need iOS + Android
    -> proven framework (Flutter or React Native)
IF  already running on Sharetribe
    -> start from mobile templates built for multi-platform
IF  platform-specific UX OR advanced integrations required
    -> budget custom work on top of the framework
IF  growth/discoverability is critical
    -> partner that covers both app development and digital growth

The goal isn't the trendiest stack. It's one that launches quickly, reaches both platforms and scales without a rewrite.

Timeline sanity check

Multi-platform development is typically 20–40% faster than separate native builds. Ballpark ranges from the source guide:

simple marketplace MVP with a solid team: 8–12 weeks
full-featured platform with custom integrations: 16–24 weeks

If an estimate lands far below these, ask what was left out of scope.

Quick FAQ for the team channel

Is multi-platform right for every marketplace? Most benefit, especially early on. Listings, messaging, ratings and payments work well cross-platform. Highly visual products, or those needing advanced native features, need custom development on top.

Multi-platform vs cross-platform: same thing? They're often used interchangeably. Strictly, multi-platform spans iOS, Android, web and desktop, while cross-platform usually means iOS plus Android. Modern frameworks can handle both.

Can we plug in third-party services? Payment gateways, analytics and push notifications are standard. Niche integrations may need custom development.

Takeaway

Run the checklist before the framework debate: platforms per marketplace side, customisation level, integration audit, growth channel and AI ambitions. Once those are written down, the framework usually picks itself.

If you'd rather work with a team that has shipped this before, Journeyhorizon offers Flutter mobile app development for marketplaces that pairs the build with a growth plan.

Flutter Push Notifications Not Received in Background or When App Is Killed: Fixes

Notify sphere — Wed, 28 Oct 2026 06:37:22 +0000

Your Flutter app gets push notifications while it's open, but nothing shows up once it's in the background or closed. This is one of the most common Firebase Cloud Messaging problems, and it almost always comes down to a handful of causes. Here they are, from most to least likely.

Quick checklist

The background handler is a top-level function with @pragma('vm:entry-point').
FirebaseMessaging.onBackgroundMessage() is registered before runApp().
The message has a notification block, or is data-only with high priority (Android) and content-available (iOS).
Notification permission is granted (Android 13+ and iOS both ask).
On iOS: Push Notifications and Background Modes → Remote notifications are enabled, and the APNs key is uploaded to Firebase.
You're testing on a real device in a release or profile build, and the app wasn't force-stopped.

1. Set up the background handler correctly

When your app isn't in the foreground, firebase_messaging runs your handler in a separate Dart isolate. That only works if Flutter can find the function by itself, so it has to be a top-level function (not inside a class) and marked as an entry point. Otherwise tree shaking in release builds can remove it, and messages silently do nothing.

import 'package:firebase_core/firebase_core.dart';
import 'package:firebase_messaging/firebase_messaging.dart';
import 'package:flutter/material.dart';

// Must be a top-level function, not a class method or closure
@pragma('vm:entry-point')
Future<void> firebaseMessagingBackgroundHandler(RemoteMessage message) async {
  // Runs in its own isolate, so initialise Firebase again here
  await Firebase.initializeApp();
  debugPrint('Background message: ${message.messageId}');
}

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp();

  // Register before runApp()
  FirebaseMessaging.onBackgroundMessage(firebaseMessagingBackgroundHandler);

  runApp(const MyApp());
}

Because the handler runs in its own isolate, it can't touch your widgets, providers or in-memory state. If you use other Firebase services inside it, call Firebase.initializeApp() there too.

2. Send the right kind of message

FCM has two kinds of messages, and they behave very differently in the background:

Notification messages (with a notification block) are displayed by the operating system itself when your app is in the background or closed. Your Dart code doesn't have to run for the user to see them. This is what you want for anything user-facing.
Data-only messages (just a data block) display nothing on their own. They wake your background handler, and only if the platform agrees to deliver them.

For a notification the user must see, send something like this through the FCM HTTP v1 API:

{
  "message": {
    "token": "DEVICE_FCM_TOKEN",
    "notification": {
      "title": "Your order is out for delivery",
      "body": "Arriving in about 20 minutes"
    },
    "data": { "orderId": "4821" },
    "android": {
      "priority": "high",
      "notification": { "channel_id": "high_importance" }
    },
    "apns": {
      "headers": { "apns-priority": "10" },
      "payload": { "aps": { "sound": "default" } }
    }
  }
}

If you really need a silent data-only message, mark it high priority on Android and as a background push on iOS:

{
  "message": {
    "token": "DEVICE_FCM_TOKEN",
    "data": { "type": "sync", "orderId": "4821" },
    "android": { "priority": "high" },
    "apns": {
      "headers": { "apns-push-type": "background", "apns-priority": "5" },
      "payload": { "aps": { "content-available": 1 } }
    }
  }
}

You can build and check both payloads with our free FCM payload builder, which also gives you the cURL command.

3. Ask for notification permission

Since Android 13, apps need the POST_NOTIFICATIONS runtime permission, and iOS has always needed one. Without it, messages are delivered to the device but never shown. Ask once, at a sensible moment:

final settings = await FirebaseMessaging.instance.requestPermission(
  alert: true,
  badge: true,
  sound: true,
);
debugPrint('Permission: ${settings.authorizationStatus}');

If the status comes back as denied, the system won't show the dialog again, so point the user to the app's notification settings instead.

4. Android: battery savers and force stop

If notifications arrive on a Pixel but not on some Xiaomi, Oppo, Vivo, Realme, OnePlus or Samsung phones, the phone's battery optimisation is likely stopping your app in the background. Things to check:

Force stop from Settings blocks every FCM message until the user opens the app again. A normal swipe from recents shouldn't, but some brands treat it like a force stop.
Use high priority for time-sensitive messages. Normal priority can be delayed while the phone is in Doze mode.
Create a notification channel with high importance and send its channel_id, or the notification may arrive silently without a heads-up banner.
For testing, set the app's battery usage to Unrestricted and turn on Autostart where the phone has it. You can't do this for your users, but it confirms the cause.

5. iOS: capabilities, APNs and how the app was closed

In Xcode, under Signing & Capabilities, add Push Notifications and Background Modes with Remote notifications ticked.
Upload your APNs authentication key in the Firebase console (Project settings → Cloud Messaging). Without it, nothing reaches iOS at all. The Firebase iOS push guide walks through it.
Background data messages are throttled by iOS and aren't delivered at all if the user swiped the app away. Notification messages are still shown in that case.
If you see apns-token-not-set, the device never got an APNs token. See how to fix the APNs token error.

6. Test the right way

Debug builds behave differently from what your users run. When you stop the app from your IDE, the process is killed in a way that real users never do, and background messages may not arrive. Test background and terminated states on a real device with flutter run --release (or a profile build), close the app the way a user would, then send a message.

To handle taps, use FirebaseMessaging.onMessageOpenedApp for a tap while the app is in the background, and FirebaseMessaging.instance.getInitialMessage() for a tap that launched the app from closed.

Want this handled for you?

The notifySphere Flutter SDK handles token registration and wires your background handler in at startup, and it tracks delivery and opens for every notification, so you can see whether a message reached the phone or was dropped on the way. It's free up to 1,000 monthly active users. Compare it with other options on our OneSignal alternatives page.

Frequently asked questions

Why do Flutter notifications work in the foreground but not in the background?

Usually one of four things: the background handler isn't a top-level function marked @pragma('vm:entry-point'), it's registered after runApp(), the message is data-only without high priority, or the phone's battery saver is stopping your app. Fix them in that order.

Why does onBackgroundMessage not get called on iOS?

For a data-only message, iOS needs content-available: 1 in the aps payload and the Background Modes capability with Remote notifications enabled. Even then iOS throttles background messages and won't deliver them if the user swiped the app away. For anything the user must see, send a notification payload instead.

Do push notifications arrive if the user force-stops or swipes away the app?

On Android, force stop from Settings blocks all FCM messages until the user opens the app again; a normal swipe from recents does not, except on some phone brands with aggressive battery savers. On iOS, notification messages are still shown after a swipe, but background data messages are not delivered.

Can I update the UI from onBackgroundMessage?

No. The background handler runs in a separate isolate with no access to your widgets or app state. Save what you need (for example with shared_preferences) and read it when the app opens, or use onMessageOpenedApp and getInitialMessage to react to taps.

Why are notifications not showing when the app is open?

That's expected. In the foreground, Android doesn't display FCM notifications on its own, so you show them yourself with flutter_local_notifications. On iOS, call setForegroundNotificationPresentationOptions(alert: true, badge: true, sound: true).

Originally published on the notifySphere blog. notifySphere is push notifications, WhatsApp Business API, deep linking, and in-app support in one SDK — free up to 1,000 users.

App Development Guide: Steps, Tools, and Success Tips

Rohit Voice — Wed, 28 Oct 2026 05:07:06 +0000

Introduction

Application Development is the process of creating applications for mobile phones, desktops, or the web. This process incorporates design, development, testing, and deployment, all aimed at providing functional and engaging experiences for users.
In the present day and age, where the first thing people do in the morning is check their phones for notifications, apps become essential for driving business forward.

Helps shorten time to market
Drives user engagement
Provides additional revenue sources
Improves company reputation

App Development Overview

Quick look at what is entailed in the process of app development, from conception to ongoing management after the launch.

App Development Phases

Phases common to every project that is successful.

Proof of Value for App Development

Numbers that demonstrate the importance of good app development.
Illustration: Retail company develops a mobile app through which consumers can shop, get rewards, and special offers tailored just for them.

App Category	Typical Platforms	Development Complexity
Native Mobile	iOS, Android	High
Hybrid Mobile	Both (using frameworks)	Medium
Progressive Web App	Any browser	Low

Important Summary Points

App Development creates practical and user-friendly software applications.
It drives growth, engagement, and competitiveness.
Important phases in the process include planning, designing, coding, testing, and launching.
The choice of platform affects budget, efficiency, and sustainability.

What Does App Development Consist of?

App development is the creation of an application from a concept through designing, programming, testing, and release. This will help to achieve all the necessary tasks and make sure that the application is working well for users.
Getting familiar with the main elements of the development process, the team can properly distribute their resources.

Requirement analysis and collection
UI/UX design and prototyping
Development on chosen technology stack
Testing, debugging and QA
Release to the app store and support

Requirements & Design: Understanding the needs of the end-users and designing wireframes – the basis of the project.
Development & Testing: Programming the application in order to be sure that it performs well and is safe for the users.
Deployment & Maintenance: Putting an app online and updating it constantly.

Development Approach	Best For	Pros	Cons
Native Development	High performance	Best UX, full device access	Requires separate codebases
Cross‑Platform (React Native/Flutter)	Faster time‑to‑market	Single codebase, cost‑effective	Slight performance trade‑off
Progressive Web Apps	Light‑weight access	No install required	Limited device features

Key Concepts for Summary

The development process of an application consists of designing, programming, testing, and launching.
Appropriate requirements and design prevent any extra work.
Multisystem solutions might accelerate the process without affecting its result.
Constant support will ensure security and satisfaction of customers.

Importance of App Development in Today’s World

In the era of high expectations for digital services, app development plays a vital role in ensuring business success. Companies that invest in their app development notice improved interactions with users and higher revenues.
This does not only help to increase sales but contributes to building brand trust and creating customer loyalty.

More engaged and loyal users
Higher conversion rates and increased revenue
Improved visibility and credibility of the brand
Insights gained from data analytics to improve products

UX: The good design of the app ensures intuitive navigation, quick loading, and responsiveness of the interfaces.
Business benefits: Mobile applications provide new sales opportunities, optimization of processes and ongoing revenue generation.
Technical benefits: Thanks to modern development tools, the process can be iterative, scalable and innovative.

Metric	Typical Impact	How Apps Contribute
User Engagement	+30% daily active users	Push notifications & personalized content
Conversion Rate	+15% sales lift	Seamless checkout & recommendations
Customer Retention	+20% repeat purchases	Loyalty programs & exclusive offers

Summary Key Points

The apps are absolutely necessary to satisfy current consumer demands.
They affect income, engagement, and reputation of brands.
It is vital to invest in UX and business strategies to maximize ROI.
The data gathered through apps enables constant improvements.

How App Development works The process of app development can consist of many stages to turn your app from conception to launch. By following a good process you lower the risk and increase your chance of success.

Discovery & Requirements
Design & Prototyping
Development & Integration
Testing & QA
Deployment & Post Launch
Requirements & Design Conducting interviews with stakeholders along with market research.
Development & Testing Coding, API Integrations and Testing.
Deployment & Maintenance Deploying your app to the app stores and maintenance based on feedback from users.

Phase	Typical Duration	Key Activities
Discovery	1‑2 weeks	Interviews, market analysis
Design	1‑2 weeks	Wireframes, UI mockups
Development	4‑8 weeks	Coding, integration
Testing	1‑2 weeks	Unit, UI, beta testing
Deployment	1 week	Store submission, launch

Key points to take away:

Every project will be a well-defined, structured process.
Agile methodologies allow you to quickly make changes and constantly improve.
Testing your product early on saves you from having to spend more money on fixing issues later on.
Ongoing support after launch makes sure your product is successful in the long term.
A flowchart showing each stage of the life-cycle when building an App.
From discovery to design, development, testing, deployment. Each with icons to highlight what stage it is.

How to successfully implement your app

A well-planned strategy and choosing the right tools will help your team follow an effective roadmap and ensure you avoid any issues.
Splitting your app into smaller steps means even complicated apps will be easy to implement.

Define your goals and how you’ll build your MVP
Choose which platform and technology you want to use
Set up your development environment and version control
Build out your key features -Test your app thoroughly and get feedback from your users.

Define your goals and plan your MVP: Think of the problem your user has and define what the minimum features required are to solve it.
Choose your technology and platform: Decide whether to go with a Native solution or Cross-Platform solution based on performance, budget and time.
Code your app and iterate: Clean code can be written, the necessary APIs integrated and incremental releases can be made based on testing.
For example a travel agency may create a trip planning app using Flutter which is a cross-platform solution meaning they can use the same code across both iOS and Android.

Tool Category	Popular Options	Key Features
IDEs	Android Studio, Xcode, Visual Studio Code	Code editing, debugging, UI design
Version Control	Git, GitHub	Collaborative coding, history tracking
CI/CD	Jenkins, GitHub Actions	Automated testing & deployment
Testing	Espresso, XCTest, Detox	Automated UI testing across devices

Key Takeaways

Start with a clear MVP to test if your idea will work in the market.
Choosing the correct tech stack can help speed up your product while ensuring it is fast and doesn’t cost too much.
Iteratively developing your product ensures it works for your users.
Strong testing ensures your product is reliable.

Benefits of Modern App Development

When modern app development is used, you are able to build high quality products using advanced frameworks, cloud and agile processes. This also gives many benefits which can improve your overall business.
Businesses that take advantage of this will often experience quicker growth.

Improved user engagement
Scalable solutions
Cost efficient
Faster development times
Improved User Engagement Users will engage more with your app thanks to a personalised interface, in-app notifications and smooth interactions.

Scalable: Apps will scale thanks to cloud based back ends and micro-services.
Cost Efficient: Code can be reused meaning lower development costs.
Faster development: Using CI/CD processes means developments can happen quicker.
For example, a news publisher has developed an app that sends out breaking news alerts. This has increased reader numbers.

Benefit	Real‑World Impact	Implementation Tip
Higher Engagement	+35% daily active users	Use behavior analytics to personalize content
Scalable Architecture	Supports 1M+ users	Adopt cloud services like AWS or Firebase
Reduced Costs	20% lower total development budget	Leverage cross‑platform frameworks
Quick Releases	Weekly updates without downtime	Implement CI/CD pipelines

Key points
Modern tools create a better and more engaging experience for users

Architectures are scalable
Saves costs (reusable code)
Fast delivery to keep your app competitive

Challenges & Ways to Overcome

Despite having advanced tools at your disposal, developing an application can present several challenges including security vulnerabilities, performance issues and regular updates. If you identify potential challenges within your project early you can create solutions to help overcome them.
By being proactive with your approach you reduce your risk and will have a smooth journey to launch.

Security Vulnerabilities
Performance Issues
Keeping up with constant OS and frameworks updates
Managing Development Costs

Security Vulnerabilities: Use end-to-end encryption, regular security checks and ensure you follow data privacy rules.
Performance Issues: Optimise your code, use efficient APIs and test thoroughly across devices.
Keeping up with Updates: Use modular design and continuous integration to keep up with new OS versions and SDK releases.
For example a banking application will use end-to-end encryption and perform regular security checks every quarter to keep users financial data secure and build trust.

Challenge	Common Pitfall	Effective Solution
Security	Inadequate data encryption	Use industry‑standard encryption & regular audits
Performance	Inefficient code causing slow load times	Profile and optimize critical paths, leverage native modules
Updates	Lagging behind new OS features	Adopt modular codebase and automated testing

Main points to remember

Proactive security protection helps protect user data and keep your brand safe.
Optimise performance to provide user's with a smooth experience. Keep up to date with updates to keep your app current.
Ensure you're using optimal resources to help keep costs at bay.

Tools, Technologies & Best Practice
Using the correct tools as well as following best practice will ensure an efficient and quality application. This includes using integrated development environments, CI/CD pipelines etc.
Keeping up to date with new technologies will ensure your team creates

innovative & reliable applications.
Integrated Development Environments
Code editors, debuggers & UI Designers.
Version Control & CI/CD Using Git & GitHub allows you to work on code collaboratively. CI/CD will automatically test & build your application.
Testing Frameworks
Automated UI testing across various devices can be done using tools such as Espresso, XCTest & Detox.
Cloud Services & APIs Cloud services allow you to scale your application and APIs can be used to add 3rd party features such as payment & analytics. For example a SaaS company may use Docker containers & GitHub Actions to automate building, testing & deploying updates, this drastically reduces manual work & errors.

Category	Recommended Tools	Why They Matter
IDEs	Android Studio, Xcode, VS Code	Unified coding, debugging, UI design
Version Control	Git, GitHub	Track changes, enable teamwork
CI/CD	Jenkins, GitHub Actions	Automated testing & deployment
Testing	Espresso, XCTest, Detox	Reliable cross‑device testing
Cloud	AWS, Firebase, Azure	Scalable hosting & services

Key Summary Points

Modern IDEs streamline the development workflow.
Version control and CI/CD ensure reliability and speed.
Comprehensive testing tools guarantee quality across devices.
Cloud services provide the scalability needed for growing user bases.

Conclusion

Developing an app is an exciting field full of creativity and technical skill. Understanding what goes into developing an app, using the correct tools and overcoming any challenges will help you create an engaging app that increases revenues.
Creating an app can be an iterative process, but by following best practice, keeping up with new trends and letting data guide you, you can

create an app that will engage your users.
Set clear goals and have a strong MVP strategy.
Use modern framework to speed up development and reduce costs.
Focus on security, performance and feedback from users.
Use automation and cloud to scale.

Step	Action	Impact
1	Define MVP & goals	Validates market fit early
2	Choose tech stack	Balances speed, cost, performance
3	Implement CI/CD	Reduces errors, speeds releases
4	Gather user feedback	Drives continuous improvement
5	Scale with cloud services	Supports growth without downtime

Flutter Deep Linking: App Links Guide

Muhammad Uzair — Wed, 28 Oct 2026 03:01:35 +0000

A link to a product page should open the product page, not a browser tab asking the user to install an app they already have. That gap is where deep linking earns its keep: a shared link, a marketing email, a QR code, or a push notification lands the user on exactly the right screen, logged in, with the back stack intact.

Flutter makes the in-app half easy. The part that trips developers up is verification: proving to Android and iOS that your app is allowed to handle your domain. This guide covers the whole chain — Android App Links, iOS Universal Links, custom schemes as a fallback, and the Dart code that turns an incoming URL into a route — with every file you need.

The three kinds of links

Type	How it opens	When to use it
Custom scheme (myapp://products/42)	Always shows a chooser if several apps claim it	Internal links, development, fallback
Android App Link (https://example.com/products/42)	Opens your app directly, no chooser	Production links on Android
iOS Universal Link (https://example.com/products/42)	Opens your app directly, no chooser	Production links on iOS

The rule of thumb: ship verified HTTPS links for anything a user can tap, and keep a custom scheme only as a fallback for environments where you do not control a domain. Verified links also survive the case where the app is not installed — they simply open the website — while a custom scheme shows an error.

Android: App Links

Android verification has two halves: the app declares the domains it wants, and the domain publishes a file confirming the app.

1. Declare the intent filter

In android/app/src/main/AndroidManifest.xml, add an intent filter to the main activity. The android:autoVerify="true" attribute is the key detail: it tells Android to check the domain at install time, and on Android 12 and later a link is only treated as verified when this check passes.

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="https" android:host="example.com" />
</intent-filter>

Use one intent filter per host, and keep the path open: verification applies to the whole host, and you decide which paths the app handles in Dart.

2. Publish assetlinks.json

Serve this file at https://example.com/.well-known/assetlinks.json over HTTPS, with content type application/json, no redirects, and no authentication gate:

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.shop",
      "sha256_cert_fingerprints": [
        "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
      ]
    }
  }
]

The fingerprint must match the key that signed the build. List both fingerprints if you test debug and release builds against the same domain — a debug build signed with the debug key will not verify against a file that only lists the release fingerprint. Get a fingerprint with:

keytool -list -v -keystore android/app/release.keystore -alias upload

For the debug key, the keystore is ~/.android/debug.keystore with alias androiddebugkey and password android.

3. Confirm verification

Android re-checks verification at install time, so after changing the file, uninstall and reinstall the app rather than just relaunching it. You can also check the system state with:

adb shell pm get-app-links com.example.shop

If the domain shows as unverified, check the file path first, then the fingerprint, then the content type — those three cover nearly every failure.

iOS: Universal Links

iOS verification mirrors Android: a capability in the app, and a file on the domain.

1. Add the Associated Domains capability

In Xcode, open the Runner target, go to Signing and Capabilities, add Associated Domains, and add one entry per domain:

applinks:example.com

Do not add a scheme here, and do not add a path: the domain entry covers the whole host, and path filtering happens in the association file.

2. Publish apple-app-site-association

Serve this file at https://example.com/.well-known/apple-app-site-association over HTTPS, with content type application/json, and no .json extension on the URL:

{
  "applinks": {
    "details": [
      {
        "appIDs": ["TEAMID.com.example.shop"],
        "components": [
          { "#": "no_universal_links", "comment": "Matches a page that should stay in the browser" },
          { "/": "/products/*" },
          { "/": "/orders/*" }
        ]
      }
    ]
  }
}

The app ID is your Team ID followed by the bundle ID, and you can find the Team ID in your Apple Developer account under Membership. The components list is evaluated in order, so put exclusions before the patterns they override. A path that matches no component falls back to the browser, which is exactly what you want for pages like login or legal content.

3. Confirm on device

iOS fetches the association file when the app is installed, and it caches aggressively. As on Android, uninstall and reinstall after changing the file. Test on a real device or simulator with:

xcrun simctl openurl booted https://example.com/products/42

If the link opens Safari instead of the app, check the file URL first (the missing-extension detail catches people), then the app ID, then whether the device actually reinstalled the app after the file changed.

Custom schemes as a fallback

A custom scheme needs no domain and no verification file, which makes it useful for development and for links that never leave your own app. Declare it in the manifest alongside the HTTPS filter, and in ios/Runner/Info.plist:

<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>myshop</string>
        </array>
    </dict>
</array>

Treat custom schemes as untrusted input: any app on the device can claim the same scheme, so never put tokens or sensitive data in a custom-scheme link, and never let one trigger a privileged action without a logged-in session check.

Handling links in Dart

The app_links package gives you both halves of the problem: the link that launched the app, and the stream of links that arrive while it runs. The stream alone is not enough — it only fires when the app is already alive, so a cold start would silently drop the link.

import 'package:app_links/app_links.dart';
import 'package:flutter/material.dart';
import 'package:go_router/go_router.dart';

final _router = GoRouter(
  routes: [
    GoRoute(path: '/', builder: (_, _) => const HomeScreen()),
    GoRoute(
      path: '/products/:id',
      builder: (_, state) => ProductScreen(id: state.pathParameters['id']!),
    ),
    GoRoute(
      path: '/orders/:id',
      builder: (_, state) => OrderScreen(id: state.pathParameters['id']!),
    ),
  ],
);

Future<void> initDeepLinks() async {
  final appLinks = AppLinks();

  // Cold start: the link that launched the app, if any.
  final initialLink = await appLinks.getInitialLink();
  if (initialLink != null) {
    _handleLink(initialLink);
  }

  // Warm state: links that arrive while the app is running.
  appLinks.uriLinkStream.listen(_handleLink);
}

void _handleLink(Uri uri) {
  // Route from the path only, so the destination survives a cold start.
  _router.go(uri.path);
}

Two details matter here. First, route from uri.path, not from extra state or a cached object, because a cold-started app has no previous session to read from. Second, guard routes that need login the same way you guard normal navigation — for example with the redirect pattern covered in Flutter go_router: The Navigation Guide — so a shared link to a private screen lands on login first and then continues to the destination.

Links from push notifications follow the same path: when a notification tap carries a URL, feed it through the same handler instead of building a second routing system. The notification setup itself is covered in Flutter Firebase Push Notifications Guide.

Testing checklist

Android, cold start: kill the app, then run adb shell am start -a android.intent.action.VIEW -d "https://example.com/products/42" and confirm the product screen opens, not the browser.
Android, warm state: with the app open on another screen, run the same command and confirm it navigates in place.
iOS: paste the link into Notes and tap it, or use xcrun simctl openurl, and confirm the app opens without a Safari intermediate page.
App not installed: tap the link on a clean device and confirm the website opens, since the HTTPS link degrades gracefully.
After any change to either verification file: uninstall and reinstall the app before retesting, because both platforms cache verification at install time.
Edge cases: a link to an excluded path should open the browser, a link with an unknown product ID should show a not-found screen inside the app rather than crashing, and a link tapped while logged out should route through login first.

Troubleshooting

Symptom	Most likely cause	Fix
Android opens the browser	Verification failed	Check the assetlinks.json path, HTTPS, content type, and SHA-256 fingerprint, then reinstall
Android shows an app chooser	autoVerify missing or failed	Add android:autoVerify="true" and confirm verification with adb
iOS opens Safari	Association file problem	Check the well-known URL without a .json extension, the app ID, and reinstall
iOS opens the app for excluded paths	Component order	Put exclusions before the wildcard patterns they override
Link works warm but not cold	Only the stream is handled	Add getInitialLink handling at startup
Link opens the wrong screen	Routing from extra state	Route from uri.path so cold starts resolve the same way

Pre-launch checklist

Before you ship deep links, confirm the whole chain once: intent filter with autoVerify, assetlinks.json live over HTTPS with both fingerprints, Associated Domains capability, apple-app-site-association live without a file extension, cold-start and warm handling in Dart, login guards on private routes, and a graceful website fallback when the app is absent. Deep links are infrastructure, not a feature — when they work, nobody notices them, and that silence is the point.

Get in touch and let's talk about your project.

Originally published at uzairxdev.online

How to Build Interactive AI Mascots for React, Flutter & SaaS Apps with Rive (2027 Guide)

Praneeth Kawya Thathsara — Wed, 28 Oct 2026 01:22:57 +0000

From static chatbot icons to real-time AI companions: a practical guide to Rive state machines, data binding, talking avatars, and developer-ready character animation.

Building an AI-powered application in 2027?

You might already have an LLM, a chat interface, voice recognition, text-to-speech, and a working frontend.

But what happens visually when your AI is listening, thinking, or speaking?

For many applications, the answer is still a loading spinner, a static avatar, or three animated dots.

What if your AI assistant could actually react to your application's state?

Imagine a character that:

Waves when a user opens the app.
Listens when the microphone activates.
Thinks while your AI processes a response.
Speaks using animated mouth shapes.
Changes facial expressions based on context.
Celebrates when a user completes a task.
Returns naturally to idle when the interaction ends.

You can build this kind of experience using Rive, its state machines, and runtime data binding.

In this guide, I'll explain how interactive Rive mascots work, how developers can structure their application logic, and what to consider before integrating one into a production app.

I'm Praneeth Kawya Thathsara, a Rive animator and interactive motion designer specializing in custom character systems for AI applications, SaaS products, React, Flutter, and React Native.

I help developers turn character designs into reusable interactive animation systems.

Need a custom mascot for your app?

Visit RiveAnimator.com or send me a quick WhatsApp message.

I'm currently offering 20% off eligible new custom Rive animation projects with code MEDIUM20.

1. Why Interactive Characters Are Different From Traditional Animations

Traditional animations usually follow a predefined timeline.

For example, a GIF might show a character waving continuously.

That works for decorative motion.

But an AI assistant needs to react to application events.

Consider this interaction:

User opens app
    ↓
Mascot welcomes user
    ↓
User activates microphone
    ↓
Mascot starts listening
    ↓
Speech recognition finishes
    ↓
AI begins processing
    ↓
Mascot starts thinking
    ↓
AI response becomes available
    ↓
Mascot starts speaking
    ↓
Audio playback finishes
    ↓
Mascot returns to idle

These are not simply animations played in sequence.

They're application-driven character behaviors.

The application determines what should happen, and the animation system responds.

This separation is important because it allows the same character to work with different AI models, APIs, and frontend frameworks.

2. Why Rive Is Useful for Interactive App Mascots

Rive is an interactive animation platform with a visual editor, state machines, data binding, and runtimes for web and mobile applications.

Unlike a traditional exported video, a Rive character can respond to application-controlled properties.

For example, a character might expose:

Property	Type	Purpose
`isListening`	Boolean	Activate listening behavior
`isThinking`	Boolean	Activate thinking behavior
`isSpeaking`	Boolean	Activate speaking behavior
`emotion`	Number	Select facial expression
`mouthShape`	Number	Select speech mouth shape
`lookX`	Number	Control horizontal gaze
`lookY`	Number	Control vertical gaze
`celebrate`	Trigger	Play a one-shot celebration

These are example properties, not universal Rive inputs.

The actual contract depends on how the character is designed.

State machines vs. data binding

This distinction matters in 2027.

Rive supports state machine logic, while modern runtimes increasingly emphasize ViewModels and data binding for connecting application data to animations.

For new data-driven characters, I recommend planning the ViewModel contract early.

For existing projects, direct state machine inputs may still be appropriate, depending on the runtime and version.

The important principle remains the same:

Your application owns the product state. Rive owns the character's visual behavior.

3. Designing a Reliable AI Assistant State System

One of the biggest challenges in interactive mascot development isn't drawing the character.

It's deciding what happens when multiple application events occur.

Imagine your app reports:

const assistantState = {
  isListening: true,
  isThinking: true,
  isSpeaking: false,
};

Should the character listen or think?

Without a defined priority system, the animation can behave unpredictably.

A simple approach is to establish clear priorities.

function getCharacterMode(state) {
  if (state.isSpeaking) return "speaking";
  if (state.isThinking) return "thinking";
  if (state.isListening) return "listening";

  return "idle";
}

In this example:

Speaking > Thinking > Listening > Idle

This is a conceptual application-state example, not a Rive runtime API.

The resulting mode can be connected to the character through its documented Rive data-binding properties.

For more complex applications, a single mutually exclusive mode can be preferable to several competing booleans.

Why priority matters

Without predictable transitions, you can encounter:

Multiple animations competing for control.
Characters stuck in a speaking state.
Repeated triggers restarting animations.
Interrupted celebrations.
Expressions not restoring correctly.
Unexpected behavior during rapid API updates.

A well-designed character should handle these situations before production deployment.

4. Integrating an Interactive Rive Mascot Into React

React applications are a common use case for interactive character systems.

The first step is loading a .riv file and rendering the character.

For example, a basic setup using the current React runtime can look like this:

npm install @rive-app/react-webgl2

import { useRive } from "@rive-app/react-webgl2";

export default function AssistantMascot() {
  const { RiveComponent } = useRive({
    src: "/mascot.riv",
    stateMachine: "Assistant",
    autoplay: true,
  });

  return (
    <div style={{ width: 320, height: 320 }}>
      <RiveComponent />
    </div>
  );
}

This example assumes your .riv file contains a state machine named Assistant.

For a production AI character, the next step is connecting the application's state to a Rive ViewModel.

For example:

// Conceptual application state
const aiState = {
  mode: "listening",
  emotion: 0,
  mouthShape: 0,
};

Your runtime integration maps those values to the appropriate Rive properties.

The exact binding code depends on the runtime version and the ViewModel defined inside your Rive file.

Refer to the official Rive documentation for the current runtime APIs.

Important developer consideration

Don't build your application around undocumented animation input names.

Before integration, request a contract that defines:

Rive file name
Artboard name
State machine name
ViewModel name
Property names and types
Default values
Supported number ranges
Trigger behavior
Completion events
Reset and interruption rules

This small step can prevent significant integration problems later.

5. Building Rive Mascots for Flutter and React Native

The same overall approach works for mobile applications.

Your application manages business logic, while the Rive runtime displays and controls the character.

Flutter

Flutter developers can use the official rive package.

flutter pub add rive

For current integrations, review the latest Flutter runtime documentation, including:

Loading Rive files
State machine playback
ViewModels
Data binding
Runtime lifecycle management
Asset loading and caching

React Native

React Native applications can use the official Rive runtime.

A typical integration involves loading a .riv asset, creating or accessing the appropriate ViewModel instance, and binding application properties to the character.

The exact implementation depends on your React Native and Rive runtime versions.

For new projects, confirm compatibility before choosing the integration approach.

Performance considerations

Whether you're building for React, Flutter, or React Native, test the character on real target devices.

Pay attention to:

Animation complexity
Mesh and vector detail
Number of active animations
Memory usage
Asset loading behavior
Reduced-motion preferences
Runtime initialization and cleanup

A character that looks smooth inside an editor still needs proper testing in the application.

Need a Production-Ready Rive Mascot for Your App?

If you're a developer building an AI assistant, SaaS product, or mobile application, I can help with the character animation system.

I create custom interactive Rive mascots with:

Reusable character rigging
Developer-friendly state machines
AI listening, thinking, and speaking animations
Facial expressions and eye controls
Lip-sync-ready mouth shapes
App-driven animation properties
Integration documentation
React, Flutter, and React Native handoff support

Wondering how much a custom mascot would cost for your app?

Just ask Praneeth.

Website: riveanimator.com

Email: riveanimator@gmail.com

WhatsApp: Send a quick project inquiry

Special offer: 20% off eligible new custom Rive projects with code MEDIUM20.

You don't need to have a completed character design to request an estimate.

6. Adding Real-Time Lip Sync to an AI Talking Avatar

A talking avatar requires more than a simple mouth-open animation.

For more natural speech animation, the character can support multiple mouth shapes corresponding to different speech sounds.

These shapes are often called visemes.

For example:

Viseme	Visual behavior
Neutral	Resting mouth
A	Open mouth
E	Wide mouth
O	Rounded mouth
M/B/P	Closed lips
F/V	Lower lip and upper teeth

The exact number of visemes depends on the project.

Your speech system can generate or provide timing information, while the application updates the character's mouth-shape property.

Conceptually:

function updateAvatarSpeech(viseme) {
  const mouthShape = visemeToMouthShape(viseme);

  // Update the bound Rive mouthShape property
  // using your runtime's ViewModel API.
}

The Rive character renders the visual mouth shape.

Your application remains responsible for audio playback, timing, and speech synchronization.

What about emotional expressions?

Speech animation and facial emotion should ideally be designed as separate concerns.

For example, a character may need to speak while smiling.

Or blink while listening.

Or look toward a user while thinking.

A reusable rig can support independent facial controls so that these behaviors don't unnecessarily conflict.

7. Gamified Mascots: Beyond AI Chat Applications

Interactive Rive characters are also useful for applications that depend on user progress.

Examples include:

Fitness apps: Characters can react to workouts, progress milestones, and completed goals.

Habit trackers: Mascots can celebrate streaks and visually acknowledge task completion.

Language-learning apps: Animated companions can encourage learners and react to lesson progress.

Productivity apps: Characters can respond to completed tasks, achievements, and focus sessions.

Educational apps: Mascots can provide visual feedback during interactive lessons.

Example: Level-based character evolution

Imagine an application with ten progression levels.

The character could expose a property such as:

const mascotProgress = {
  level: 7,
  progress: 0.75,
  mood: "happy",
};

Your app updates these values as the user progresses.

The character might gradually change its glow, energy, posture, or decorative effects.

Milestone levels could activate additional visual changes.

For complex progression systems, it is important to define how animations behave when the user levels up during another action.

Should the evolution animation interrupt the current state?

Should it finish before returning to the previous state?

Should the latest requested action take priority?

These are product and animation architecture decisions that should be made before development.

8. Common Mistakes When Building Interactive App Mascots

Mistake 1: Treating every action as a separate video

This can make real-time transitions difficult to manage.

A reusable Rive rig and state machine can provide a more integrated solution.

Mistake 2: Ignoring rapid state changes

AI applications can change state quickly.

Your animation should handle repeated triggers, interrupted actions, and unexpected updates.

Mistake 3: Mixing facial controls with body animations

If facial expressions are unnecessarily tied to body movement, developers lose flexibility.

Independent controls can make the character more reusable.

Mistake 4: Not documenting the integration contract

Developers shouldn't need to reverse-engineer a .riv file to understand its inputs.

Mistake 5: Forgetting reduced-motion behavior

Some users prefer less motion.

Applications should consider the platform's reduced-motion settings and provide an appropriate fallback experience.

Mistake 6: Designing only for large screens

An expressive character that looks great at 500 pixels might become unreadable at 48 pixels.

Character silhouettes, eyes, expressions, and fine details should be evaluated at the actual sizes used in the application.

9. How Much Does a Custom Interactive Rive Mascot Cost?

The cost depends on what the character needs to do.

A simple animated mascot is different from a fully interactive AI avatar with multiple states, facial controls, and lip-sync.

Here are my example starting prices for larger custom projects:

Service	Starting Price	20% Offer
Interactive AI Companion	$2,500	$2,000
AI Talking Avatar System	$3,500	$2,800
Gamified Mascot System	$5,000	$4,000

These are indicative starting prices, not fixed quotations.

Smaller projects can be estimated separately.

The final price depends on:

Character illustration complexity
Number of animations and states
Facial rigging requirements
Lip-sync complexity
State machine architecture
Integration support
Delivery timeline
Revision requirements

Offer code: MEDIUM20

The 20% introductory discount applies to eligible new projects, subject to the agreed scope and availability.

10. What I Deliver to Developers

My goal isn't simply to create a character that looks good in an animation preview.

It's to deliver a character system that can be integrated into a real application.

Depending on the agreed scope, deliverables can include:

Deliverable	Purpose
`.riv` file	Interactive animation asset
Editable source	Future character modifications
State machine	Animation behavior and transitions
ViewModel contract	Application-controlled properties
Input documentation	Integration reference
Completion events	One-shot action handling
Testing guide	Behavior validation
Integration example	Developer handoff

I also consider state priorities, reset behavior, and animation interruptions during development.

These details matter when the mascot becomes part of a production application.

11. Should You Build the Mascot Yourself or Hire a Rive Specialist?

If you only need a simple loading animation or a basic hover effect, building it yourself may be practical.

But if your application needs:

A custom character design
Multiple interactive states
Advanced rigging
Independent facial expressions
Lip-sync-ready animation
Reliable state transitions
Progress-based evolution
Developer-ready integration

Working with a specialist can help reduce the time spent on character production and animation architecture.

Your development team can focus on the application while the animation system is built around the agreed integration requirements.

Final Thoughts: Give Your AI App a Character That Actually Responds

AI products are becoming increasingly capable.

But great application experiences aren't only about what the AI can do.

They're also about how the product communicates with its users.

An interactive mascot can help communicate listening, thinking, speaking, progress, and success in a more expressive way.

With Rive, these behaviors can become part of your application's actual interaction system rather than a collection of disconnected animations.

The most important principle is simple:

Build a character that responds to your app, not just an animation that plays inside it.

Building an AI App? Ask Praneeth for a Custom Mascot Quote

I'm Praneeth Kawya Thathsara, a Rive animator and interactive motion designer creating production-ready interactive characters for developers and product teams.

I work on:

Interactive AI companions
AI talking avatars
SaaS product mascots
Gamified app characters
Fitness and educational mascots
React, Flutter, and React Native animation systems

How much would a custom mascot cost for your app?

Send me a quick message with your app idea. I'll help you estimate the animation scope and pricing.

Website: riveanimator.com

Email: riveanimator@gmail.com

WhatsApp: Ask Praneeth for a quick quote

Save 20% on eligible new projects with code MEDIUM20.

Let's bring your app character to life.

Written by Praneeth Kawya Thathsara — Rive Animator & Interactive Motion Designer.

DEV Community: flutter

Building a Car Rental Booking Site: Availability Is the Hard Part

Model the fleet, not just "products"

The overlap query

Prevent the race condition

Prices are rules, not numbers

Airport delivery and the booking form

Speed and languages

Where a Flutter app fits

Özel Yazılım Geliştirme (Web & Mobil Kurumsal Çözümler): Production Architecture & Best Practices 2026 (28.10.2026)

Özel Yazılım Geliştirme (Web & Mobil Kurumsal Çözümler)

1. Mimari Prensipler ve Doğru Teknoloji

2. Garanti ve Kod Mülkiyeti

🚀 İletişim & Proje Teklifi

Building DevFeed — Part 4: Shipping v1.0.1 with GitHub Actions and a Changelog

Building DevFeed — Part 4: Shipping v1.0.1 with GitHub Actions and a Changelog

Why bother with releases for a practice project

The GitHub Actions workflow

Keeping action versions current

Writing the v1.0.1 changelog

What done looks like for a learning project

Wrapping up Series 2

I shipped my app to 178 countries in 10 languages. One person outside Korea installed it.

What I tried outside Korea

The numbers in Play Console

One user in the Dominican Republic

Do I need to do more on social media?

I'll keep trying outside Korea too

Real-Time IoT Apps: What a Flutter Hydration Case Study Reveals About Development Partners

Why your Flutter JSON model crashes at runtime (and how to generate one that doesn't)

1. int vs double

2. List<dynamic> vs List<String>

3. The key that is only sometimes there

A model that handles all three

Generating it

Özel Yazılım Yaptırmak İstiyorum (Şirketlere Özel Otomasyon): Production Architecture & Best Practices 2026

Özel Yazılım Yaptırmak İstiyorum (Şirketlere Özel Otomasyon)

1. Mimari Prensipler ve Doğru Teknoloji

2. Garanti ve Kod Mülkiyeti

🚀 İletişim & Proje Teklifi

Shipping a Marketplace App to iOS and Android From One Codebase: An Engineering Checklist

Why "both platforms on day one" is the default for marketplaces

Reusability vs customisation: the real trade-off

Audit your integrations before you pick a framework

Discoverability is part of the architecture

Where AI and custom features fit

A decision matrix you can paste into your ADR

Timeline sanity check

Quick FAQ for the team channel

Takeaway

Flutter Push Notifications Not Received in Background or When App Is Killed: Fixes

Quick checklist

1. Set up the background handler correctly

2. Send the right kind of message

3. Ask for notification permission

4. Android: battery savers and force stop

5. iOS: capabilities, APNs and how the app was closed

6. Test the right way

Want this handled for you?

Frequently asked questions

Why do Flutter notifications work in the foreground but not in the background?

Why does onBackgroundMessage not get called on iOS?

Do push notifications arrive if the user force-stops or swipes away the app?

Can I update the UI from onBackgroundMessage?

Why are notifications not showing when the app is open?

App Development Guide: Steps, Tools, and Success Tips

Introduction

App Development Overview

App Development Phases

Proof of Value for App Development

What Does App Development Consist of?

Importance of App Development in Today’s World

Key points to take away:

How to successfully implement your app

Benefits of Modern App Development

Challenges & Ways to Overcome

Conclusion

Flutter Deep Linking: App Links Guide

The three kinds of links

Android: App Links

1. `int` vs `double`

2. `List<dynamic>` vs `List<String>`