DEV Community: Dominik Roszkowski

Flutter: Using Android Intent via native interop with jnigen

Dominik Roszkowski — Fri, 19 Sep 2025 19:20:00 +0000

In this post I’ll show how to access some of the Android APIs directly in Dart/Flutter. The final result will be a plugin allowing to send some basic Intents to the Android system, like opening the e-mail client or selecting a contact.

We wanted to open user’s default e-mail client to send a properly formatted message, but the typical package:url_launcher approach of creating a mailto: was too flaky. Android allows to provide a specific intent of type ACTION_SENDTO that will query the system for the best app to handle it. I created bindings for this Intent call with jnigen and here’s a bit of overview.

Getting started

Create new Flutter plugin and modify the pubspec.yaml and jnigen.yaml to match the example in the jnigen repository. This will only work on Android, hence:

flutter create --template plugin --platforms android android_intent
cd android_intent/example
flutter build apk --release

After cleaning up the code and dependencies make sure to build your Android example app in release. You can also open it in Android Studio to check if everything is correct.

This setup assumes following package versions and works as of July 2025:

jnigen: ^0.14.0
jni: ^0.14.2

jnigen setup

The basic setup of jnigen plugin works fine for me although it results with over 20k generated lines of Dart code. To be able to access Android APIs you need to specify all the classes (and their dependencies e.g. android.net.Uri) that would normally be imported in Java/Kotlin code. The following jnigen.yaml file worked for me:

android_sdk_config:
  add_gradle_deps: true
  android_example: "example/"

source_path:
  - "android/src/main/java"
classes:
  - "android.content.Intent"
  - "android.content.Context"
  - "android.app.Activity"
  - "android.net.Uri"

output:
  dart:
    path: "lib/src/bindings.dart"
    structure: "single_file"

Once you run the jnigen code generator, you should be able to use the generated bindings directly in Dart code.

flutter pub run jnigen --config jnigen.yaml

Usage in Dart

To send a simple Intent to open the e-mail client, you can use the following Dart code:

void sendEmail() {
  try {
    final intent = Intent.new$2(Intent.ACTION_SENDTO);
    intent.setData(Uri.parse("mailto:".toJString()));

    intent.putExtra$21(
      Intent.EXTRA_EMAIL,
      JArray.of<JString>(JString.type, ["example@example.com".toJString()]),
    );
    intent.putExtra$8(Intent.EXTRA_SUBJECT, "Subject".toJString());
    intent.putExtra$8(Intent.EXTRA_TEXT, "Body text".toJString());
    intent.putExtra$21(
      Intent.EXTRA_CC,
      JArray.of<JString>(JString.type, ["cc@example.com".toJString()]),
    );
    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    Context contextInstance = Context.fromReference(Jni.getCachedApplicationContext());
    contextInstance.startActivity(intent);
  } catch (e) {
    print('Error opening email: $e');
  }
}

What is quite cool it follows 1:1 the code from the Android documentation:

fun composeEmail(addresses: Array<String>, subject: String) {
    val intent = Intent(Intent.ACTION_SENDTO).apply {
        data = Uri.parse("mailto:") // Only email apps handle this.
        putExtra(Intent.EXTRA_EMAIL, addresses)
        putExtra(Intent.EXTRA_SUBJECT, subject)
    }
    if (intent.resolveActivity(packageManager) != null) {
        startActivity(intent)
    }
}

Obviously there are several slightly annoying differences:

You have to cast Dart types to Jni types, e.g. toJString().
You have to use JArray.of<JString>() to create an array of strings
You have to use putExtra$21 and putExtra$8 methods as Dart does not support method overloading

On the flipside, the package:jni comes with few convenience methods:

Jni.getCachedApplicationContext() to get the application context which I can cast to Context and use it to start the intent.
not shown here Jni.getCurrentActivity()

Sending Intents with results

It isn’t directly possible to receive Intent results via Activity.onActivityResult(), so I had to come up with a workaround. The main inspiration was package:receive_intent, and my previous attempt of using proxy with a listener interface. There may be other ways in the future to achieve this – see this issue for details.

Anyway, to receive intent results like this, you need to override the onActivityResult of your main Activity.

const val REQUEST_SELECT_CONTACT = 1

fun selectContact() {
    val intent = Intent(Intent.ACTION_PICK).apply {
        type = ContactsContract.Contacts.CONTENT_TYPE
    }
    if (intent.resolveActivity(packageManager) != null) {
        startActivityForResult(intent, REQUEST_SELECT_CONTACT)
    }
}

override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent) {
    if (requestCode == REQUEST_SELECT_CONTACT && resultCode == RESULT_OK) {
        val contactUri: Uri = data.data
        // Do something with the selected contact at contactUri.
    }
}

FlutterPlugin comes with a ActivityAware interface that allows you to register a result listener via ActivityPluginBinding:

override fun onAttachedToActivity(binding: ActivityPluginBinding) {
    activity = WeakReference(binding.activity)
    binding.addActivityResultListener { res, req, intent ->
        Log.i("ARLP", "addActivityResultListener called with intent: $intent")
    }
}

So to make that work I had to implement a typical Flutter plugin class that would keep OnResultListener interface. This interface will later be implemented in Dart.

This also means that now my plugin includes a Kotlin class of its own so it needs to be registered in the pubspec.yaml file:

flutter:
  plugin:
    platforms:
      android:
        ffiPlugin: true
+ package: com.example.android_intent
+ pluginClass: ActivityResultListenerProxy

Next up I created a Kotlin class ActivityResultListenerProxy:

@Keep
class ActivityResultListenerProxy : FlutterPlugin, ActivityAware {
    private var activity: WeakReference<Activity>? = null;
    private var callback: OnResultListener? = null;

    public interface OnResultListener {
        fun onResult(requestCode: Int, resultCode: Int, result: String?)
    }

    @Keep
    public fun onResult(requestCode: Int, resultCode: Int, intent: Intent?) : Boolean {
        if (intent != null) {
            callback?.onResult(requestCode, resultCode, intent.dataString)
            return true
        } else {
            return false
        }
    }

    override fun onAttachedToActivity(binding: ActivityPluginBinding) {
        activity = WeakReference(binding.activity)
        binding.addActivityResultListener { res, req, intent ->
            Log.i("ARLP", "onAttachedToActivity called with intent: $intent")
            onResult(res, req, intent)
        }
    }

    override fun onDetachedFromActivityForConfigChanges() {
        activity?.clear()
        activity = null
    }

// other methods
}

One challange was to get hold of the plugin instance that would be created by Flutter. To make it work I made it a singleton and added a static companion object that would hold the instance. Plugin cannot be Kotlin’s object.

@Keep
class ActivityResultListenerProxy : FlutterPlugin, ActivityAware {
    private var callback: OnResultListener? = null;

    companion object {
        @Volatile
        private var instance: ActivityResultListenerProxy? = null

        fun getInstance(): ActivityResultListenerProxy {
            return instance ?: synchronized(this) {
                instance ?: ActivityResultListenerProxy().also { instance = it }
            }
        }
    }

    @Keep
    public fun setOnResultListener(listener: OnResultListener) {
        callback = listener
    }
// other methods
}

Then after updating my jnigen.yaml I was able to start intent with result.

android_sdk_config:
  add_gradle_deps: true
  android_example: "example/"

source_path:
  - "android/src/main/java"
classes:
  - "android.content.Intent"
  - "android.content.Context"
  - "android.app.Activity"
  - "android.net.Uri"
  - "android.provider.ContactsContract"
  - "com.example.android_intent.ActivityResultListenerProxy"

output:
  dart:
    path: "lib/src/bindings.dart"
    structure: "single_file"

This time I had to use Activity to start the intent and register the result listener.

void selectContact() {
  try {
    final intent = Intent.new$2(Intent.ACTION_PICK);
    intent.setType(ContactsContract$Contacts.CONTENT_TYPE);

    listener = ActivityResultListenerProxy.Companion.getInstance();
    listener!.setOnResultListener(
      ActivityResultListenerProxy$OnResultListener.implement(
        $ActivityResultListenerProxy$OnResultListener(
          onResult: (result, request, data) {
            print('ARLP Selected contact: $result, request: $request, data: $data');
          },
        ),
      ),
    );

    final activity = Activity.fromReference(Jni.getCurrentActivity());

    activity.startActivityForResult(intent, 1);
  } catch (e) {
    print('Error selecting contact: $e');
  }
}

I experimented a bit more with other Intents like selecting an image from camera and they all seemed feasible. It would take a bit more API design to make it work, but nonethelss it’s quite cool to use Android APIs directly in Dart code.

You can find the full source code in my native_interop repository.

Native interop with Kotlin/Java in Flutter

Dominik Roszkowski — Mon, 20 Jan 2025 10:00:00 +0000

Last year during the Fluttercon session about future of native interop I learned about this new tool called jnigen. It's became quite stable recently and I wanted to try it out again.

Some background

In the past I used Xamarin and back then it was quite natural to invoke platform APIs from C# through something called bindings. In other words classes like Activity, Context, NSUrl, UIView were accessible directly from C# without any additional glue code. It was also possible with a bit of work to expose most of the native libraries in a similar fashion. Sort of similar thing is also available in Kotlin Multiplatform where you can access import namespaces like platform.Foundation.NSUUID. They even do some experiments with using SwiftUI views in Compose.

Current state of native interop in Dart/Flutter

Some might say that number of ways to interact with the platform from Dart is getting out of hand, sometimes leading to people choosing not to use native APIs at all or switch between random wrappers from pub.dev.¹

When interacting with Java/Kotlin/Swift classes in Flutter you need to go via plugin that either includes some glue code using platform channels, or can use some type-safe approach like pigeon or protobuf. Most of the plugins are wrappers around platform-specific APIs e.g. to show notifications or access shared preferences. For some more advanced scenarios you may want to look into dart:ffi but the learning curve is quite steep for a typical mobile developer.

Even with the simplest method channel you have to write very similar code 3 times: in the platform interface, in the implementation for each platform, and then handling of it on the native side. In my case I just write it manually (+LLM) as it's typically faster than any of the code generation methods I tried before.

From what we know Flutter team is actively working on enabling automatic direct native interop, see the short video below for some recent updates from "Flutter in Production" event (Dec 2024):

jnigen

The promise of jnigen is to generate Dart bindings from arbitrary Kotlin/Java code. How does it work:

jnigen scans compiled JAR files or Java source code to generate a description of the API, then uses it to generate Dart bindings. The Dart bindings call the C bindings, which in-turn call the Java functions through JNI. Shared functionality and base classes are provided through the support library, package:jni.

It's a bit roundabout way, but it feels more understandable than what I remember from Xamarin bindings.

Simple example

Note: This is not meant to be a tutorial how to use jnigen, but rather an inspiration piece :)

A quite simple example can be found in the project repo where they call a suspend Kotlin function from Dart.

Given a simple Kotlin class:

import androidx.annotation.Keep
import kotlinx.coroutines.*

@Keep
class Example {
  public suspend fun thinkBeforeAnswering(): String {
    delay(1000L)
    return "42"
  }
}

after some code generation you can simply instantiate it and invoke the function with in async-await fashion:

final example = Example();
final answer = await example.thinkBeforeAnswering();
print(answer); // prints 42 after a while;

However, what is quite cool, you can also invoke functions synchronously. Given this Java class:


package com.example.in_app_java;

import android.app.Activity;
import android.widget.Toast;
import androidx.annotation.Keep;

@Keep
public abstract class AndroidUtils {
  public static void showToast(Activity mainActivity, CharSequence text, int duration) {
    mainActivity.runOnUiThread(() -> Toast.makeText(mainActivity, text, duration).show());
  }
}

A simplified invocation would look like this:

import 'package:jni/jni.dart';

final activity = JObject.fromReference(Jni.getCurrentActivity());
AndroidUtils.showToast(activity, message.toJString(), 0);

As you might have noticed you get some handy helpers to retrieve the current activity or context.

If you ask me, this is exactly what I was looking for.

Example with platform view

To play a bit more I wanted to rewrite some of actual production code from the app I'm working on to use jnigen instead of method channels. I've been using a fork of this pdf plugin² that not only is a classic Flutter plugin, but also includes a platform view.

After getting rid of the platform channel calls I had to figure out how to control the pdfView instance that is hosted in the platform view. The simplest way I found was to keep it in a static field that gets accessed through a god-like controller class. FlutterPDFView is slightly modified platform view implementation from the original plugin.

@Keep
public class PDFViewController {
    public void setPage(int page){
        if (FlutterPDFView.pdfView == null){
            return;
        }

        FlutterPDFView.pdfView.jumpTo(page);
    }
// ...
}

Having my PDFViewController that can access the plugin's platform view instance I generated the bindings with jnigen and was able to instantiate this class in Dart. What is super exciting is that when referencing the instance in Dart you get to see the exact same memory address as on the native side.

Note the same memory address when debugging PDFViewController class from Dart and Java

I needed a way to get notified about page changes from the native side. There's no support for generating bindings for streams or similar communication channels, so you have to pass a listener that can include a callback to get invoked.

After some back and forth I learned that you can generate bindings for Java interfaces that later get implemented in Dart. It blew my mind. In other words I get to create a Dart class that in runtime is implementing a Java interface. This lets me pass it to my previously instantiated class and use it on the Java side.

Given this Java interface:

@Keep
public interface PDFStatusListener {
    void onLoaded();
    void onPageChanged(int page, int total);
    void onError(String error);
    void onLinkRequested(String uri);
    void onDisposed();
}

You can instantiate the implementation of it in Dart:

final listener = pdf.PDFStatusListener.implement(
    pdf.$PDFStatusListener(
        onLoaded$async: true,
        onPageChanged$async: true,
        onError$async: true,
        onLinkRequested$async: true,
        onDisposed$async: true,
        onLoaded: () {
            print('PDF Loaded');
        },
        onPageChanged: (int? page, int? total) {
            print('PDF page: $page, total: $total');
        },
        onError: (JString? string) {
            print('PDF error: ${string?.toDartString()}');
        },
        onLinkRequested: (JString? string) {
            print("Link: ${string?.toDartString()}");
        },
        onDisposed: () {
            print('PDF disposed');
            example.release();
        },
    ),
);
example.setPdfStatusListener(listener);

Being able to pass an instance of class as listener allows me to convert it to any form I like whether it's a Dart stream or just a void callback. It still requires writing some wrappers and glue code, but somehow it feels more valuable than repetitive platform channels.

What about Swift

There's experimental bindings generator for Swift: swiftgen. I tried it only once, but will definitely try to reproduce the same example and perhaps share my findings here.

Hope you enjoyed this and perhaps you'll try it for yourself. Truth is, without Flutter developers getting interested, there's no real incentive to push forward.

Cheers!

Other resources:

Follow Hossein for most up-to-date news about native interop: https://x.com/YousefiDash
jnigen
swiftgen - may require branch change
The past, present, and future of native interop - Dart team talk about native interop e.g. JNIgen
Future of Dart panel
SwiftGen GH project

I've heard several time how people were switching between various audio player packages just because of some missing features or little bugs, notification plugins, camera implementations etc. I wish we wouldn't have to go through this "pick and choose" flow with fundamental capabilities like media playback or basic OS functionalities. ↩
I keep a private fork that uses different implementation on iOS and builds well with my app. ↩

What really grinds my gears in Flutter

Dominik Roszkowski — Sun, 31 Jul 2022 12:00:00 +0000

My latest post listing reasons why I enjoy Flutter so much was a bit of a puff piece, frankly. Flutter is definitely one of the most fulfilling technologies out there, but it’s not without its flaws. Let’s discuss some of the things that irritate me the most. We’ll start with the web issues.

This is my personal opinion, and even though I have worked with Flutter for quite some time, I may be wrong in some cases. Please let me know if something is incorrect or gets fixed in the future.

Web issues

Some of the experienced Flutter developers I personally know would not select Flutter as their primary tool for building a website. It’s a bit of a different discussion when it comes to a very specific set of apps that could as well be a desktop tool like Supernova, Rive, Superlist, or Rows. However, building big scale consumer-facing… portals entirely in Flutter may be out of question.

Don’t get me wrong. I use Flutter web regularly e.g. for my presentation companion apps. In my consulting work I participated in several Flutter web projects. It worked mostly fine, but the class of problems that need to be solved is vastly different from what a typical web developer faces on a daily basis.

I suspect there’s still a long way before Flutter will feel and work equally well as classic web apps. Here are some of the most pressing issues I see right now.

Announcing my newsletter

To make it easier to never miss a new blog post, I decided to start a simple newsletter. It's called Occasional Flutter and I invite you to subscribe today!

Default behavior

Anytime you run a Flutter mobile app, you can quickly deduce this from the little things like scrolling with two fingers make it go twice as fast or rotation of the app looks a little bit off compared to a native one.

Similarly, there are things that are odd in Flutter web apps. I immediately notice that keyboard shortcuts or focus behavior are just a little bit different from what I would expect. It can be tweaked to work similarly as in a simple HTML document with Actions and Intents, but developers rarely remember to handle focus changes, space or tab behavior, cursor decoration etc. [As an exercise open any Flutter web app and press space, then open Twitter and do it again]

Some other issues worth noting are lack of proper text selection (which hopefully will be fixed with this change), not being able to find words with the browser find box, and more subtle challenges like bundle size or mobile performance.

I feel like I need to emphasize that some of the issues mentioned here are not framework bugs, but rather consequences of mobile developers building web apps. As such we tend to make mistakes not understanding how the web form factor differs from a single window mobile universum.

Tough choice

When deploying a Flutter web app you’re faced with a choice. You can either run the app with the HTML renderer or CanvasKit. By default on mobile the former option is used, whereas desktop defaults to CanvasKit. For basic usage it’s fine, but in practice the mobile experience will usually be worse. There’s no easy way to measure this without performance overlay. I noticed some of the best-known Flutter web apps just avoid running on mobile at all.

Several problems from the previous section are much more perceivable on smaller form factors, which for a client may be extremely unfortunate. Some say^{[1], [2]}, that nowadays users spend most of their online time (and thus money) via smartphones. There’s a new generation of people growing up now that mobile is their primary tool to access most of the online services. It sounds obvious but delivering subpar quality and performance is out of the question for most of the startups and disruptors on the market.

Every quarter the Flutter team organizes a survey to collect feedback like this one. They publish results on medium. Make sure to take part in the next one, whenever you see a prompt in your IDE.

Scrolling and physics

Over the last couple of months this part has gotten significantly better, but it’s still interesting to see how different the scrolling behavior is in Flutter apps compared to ordinary webpages or desktop apps. I wish I would understand the technical details more, but in essence, Flutter is emulating scrolling from scratch. This means it has to handle different scroll physics implementations per platform, various input devices, and things like scrollbar on its own. There were attempts by the community to make it nicer, as well as several issues reporting spotted discrepancies.

In this animation made in Rive I tried to visualize my interpretation of how the scrolling differs in Flutter compared to typical websites. As the scrolling is emulated, it’s Flutter’s responsibility to render elements outside of the viewport once they enter it. Therefore, the browser is not able to leverage existing techniques for preloading images or rendering text (forgive me this slight anthropomorphization of browser and Flutter 😉),

See animation here

Elements like this one add up to make the general feeling of the Flutter web app slightly different than what we’re used to. It’s awesome to have such freedom when building a mobile app toolkit, but it can add a lot of work when deploying a simple webpage.

General feeling

As an example for this chapter, head over to a pretty well-executed website of Matt Carroll. It looks all right, it’s relatively heavy on the graphics, and - what’s important - it’s a typical landing page that’s a few times longer than its width. Let’s list some quirks (I hope you don’t mind Matt). On mobile, you can scroll it twice as fast with two fingers. If you pause JS execution it won’t scroll anymore. The scrollbars are not provided by the browser but painted with Flutter, so they appear only when you move your mouse near the edge. You cannot select any text. You cannot enter funny faces 🤪 to send them to Matt with a macOS emoji picker. And if you leave the website open for a couple of minutes, something else happens…

GPU load

When building the Flutter web app with CanvasKit it will get rendered mostly by the GPU ^{[citation needed]}. In some cases (like the animations-heavy landing page) leaving the app open for 5-10 minutes will make your GPU hot enough that fans need to kick in. It was especially painful when using i9 MacBook Pro with its thermal limitations, but even on new M1 laptops it happens when I leave a Flutter web open. I need to point out that it may be very specific to my workflow with dozens of Chrome tabs open and several memory-heavy apps like Slack or VS Code running in the foreground. Moreover, it can be optimized and some high-quality apps like Supernova nail it, but I decided to mention it anyway.

Reinventing the wheel

People often say “don’t reinvent the wheel”. However, if not for reinventing the wheel, we wouldn’t be able to ride on the Moon. Some of the things that the Flutter team had to reinvent allow for unprecedented flexibility and performance, but at the same time make it difficult to leverage existing APIs (e.g. undo).

I imagine it’s a difficult spot to be in for the Flutter team. The decision to make a leap into the web ecosystem meant that they have to solve a completely different set of problems than in Android and iOS realms alone. For me, the distance between mobile and web seems larger than for instance between mobile and desktop. This is why my greatest excitement in 2019 was the announcement of alpha support for macOS.

Desktop issues

When discussing desktop issues, we need to face a similar truth as in the case of the web. Flutter in its foundations was meant to be run on small handheld devices 🌌. Expanding it to cover big screens where multitasking and window management is crucial means there’s a lot to build from scratch. Just take a look what kind of details need to be taken into account to correctly handle the scrollbar on macOS.

The rise of Electron’s popularity and the examples of exceptional desktop apps built with JS/TS show that there’s still huge potential for Flutter despite its past. There are several examples of apps that deliver amazing quality and experience even though the desktop ecosystem in Flutter is just getting started.

We already have a decent support for keyboard shortcuts or deployment to stores. I can’t wait for multi window support to become something built-in. We’re getting closer to rendering platform views inside Flutter on desktop. More and more progress is made on desktop foundations such as menu bars, flavors, navigation, or input devices.

Sometimes I just wonder what if in 2018 the first leap into the unknown was towards the desktop, not the web.

Shaders and jank issue

This has been on my mind since I run my first iOS app in release. The first remarks of iOS jank issue are as old as the Flutter itself. Every couple of weeks I’ve been checking the progress on the automatic shader warm-up effort and was super excited to check out the new impeller runtime. However, some odd problems show up from time to time despite various improvements over the last 2 years.

For those who read about it for the first time here’s a quick recap.

When [the animation] shader is first used, it needs to be compiled on the device. The compilation could cost up to a few hundred milliseconds whereas a smooth frame needs to be drawn within 16 milliseconds for a 60 fps (frame-per-second) display. Therefore, a compilation could cause tens of frames to be missed, and drop the fps from 60 to 6. This is compilation jank. After the compilation is complete, the animation should be smooth.

To fix this we can precompile shaders either via automated widget tests or just manually running the app to collect the shaders before the release. Then the generated shader files can be bundled into the final build. The size increase is relatively small while the performance gains can be amazing, especially if your app relies on animations a lot. The major problem with this approach is that it needs to be redone for every new build.

Summary

Similarly to my previous more optimistic post, this list could go on much longer. I don’t want to undermine Flutter in any way, but at the same time I feel like we shouldn’t avoid speaking about some obvious problems we encounter daily. Flutter is a wonderful piece of tech, it’s no longer in its infancy. It’s a production-grade ecosystem that many companies and individuals use to build world-class experiences. It’s just a pity there are still some fundamental issues that seem to never go away…

Announcing my newsletter

To make it easier to never miss a new blog post, I decided to start a simple newsletter. It's called Occasional Flutter and I invite you to subscribe today!

Occasional Flutter

N things I love about Flutter

Dominik Roszkowski — Tue, 19 Jul 2022 14:31:33 +0000

Topics like this one may seem trivial, but frankly after using Flutter for over 4 years it's easy to forget why this tool makes me so satisfied. Thus, I decided to document some of the most spoiling things about Flutter. Maybe next time I'll write about problems I can't stand 😉

This post was originally published on my personal blog.

Hot reload

This is the obvious one, but every time I have to use a compiled language without this kind of instant feedback loop, I really wish instant code reload would become a new norm in any language. Recently, I gave dart_frog a try and the ability to instantly reload the implementation of the server code felt like magic.

Open Source

Flutter and Dart are open source projects. It means you can browse and inspire from the freely accessible library of almost infinite knowledge. The IDE's ability to access the code by just inspecting it is a cherry on top.

Naturally, the open source SDK code written by over a 1000 contributors is not going to be the same as client-facing production app code. You're not going to copy and paste the framework code and built the app out of that. However, anytime you need to figure out how to write an atypical test, build a new library of widgets, or design new API used by thousands of users the Flutter ecosystem and codebase are places to go.

The open source attitude affects not only the framework code. As a developer I clearly see how it affects the community and newcomers to share all the things they build and learn every day.

Multi-Platform

Since the very beginning of my work as developer I always wanted to build for every device. I started with things like ASP.NET, Xamarin, Android, Ionic, or WPF. And they were really amazing tools. However, it was the Flutter that actually allowed me to not feel limited by the tech stack I use.

There are definitely things that will be astronomically difficult to build with Flutter, especially on web or if the SDK does not support it yet. The recent discussion on Twitter about Flutter Web sums it up nicely. And many of you already know my personal hesitation about this use case. However, it's all the other platforms that make me enthusiastic about the future of Flutter.

Work done by Canonical with their Desktop Installer, Sonos with the setup sequence, foldable support by Microsoft's Andrei Diaconu, Raspberry PI support and e-ink POC by Simon Lightfoot. The list could go on and on.

To make it even better, the bulk of my day to day development work for mobile I can do by running a lightweight desktop app. If I need to build a simple utility app to use on macOS, most of the APIs is there and I can just reuse my mobile dev skills. If I need to dig deeper, there's another groundbreaking thing about Flutter:

Unobstructed access to the underlying platform

This may not be super obvious but the more you build apps that need some platform-specific functionality, the more you appreciate modular design of a Flutter project. Each platform is just another wrapper that can be freely configured as if it were a standard macOS/Windows/Android/iOS/Linux... app.

There are of course some specific setup steps (e.g. in Xcode build phases) that are required to run it as a Flutter app, but for the most part you can do whatever you need with your native project. This is extremely convenient compared to e.g. Xamarin where (I guess) at the cost of being able to use native APIs in C#, they had to hide/bundle the native project inside of the Xamarin app.

Having access to a native project means that you can utilize your other skills and resources to help you with release, customization or building more features.

Especially the federated plugin architecture makes multi and cross-platform cooperation easier. In a bigger team you may find groups of experts in their own areas that alone would have a hard time building solutions in the opposite ecosystem. Imagine implementing a camera app on Android as iOS developer. With Flutter you can split the efforts with a thin layer of common "consumer-friendly" API and have the best of all worlds.

Summary

This list is definitely not complete. There are more features like thriving community of tutors and learners, high quality open source libraries (just to mention flutter_bloc and riverpod), Discord server where Flutter maintainers work in the open, and many more. However, as in every technology there are also some pain points. We'll try to discuss them next time 😉

Flutter Animated Logo with CustomPainter

Dominik Roszkowski — Tue, 05 May 2020 10:20:00 +0000

FlutterLogo is a really handy widget. But what if we want to have it animated like in some of the Flutter team videos? We can try to do it with Rive, but let’s challenge ourselves and do it in pure Dart.

You can check out the final result in the #FlutterPen below:

If you want, you can also read this post on my website.

Contents

Introduction
Implementing complex animations by breaking them down
- Staggered animation
Drawing the logo
- Drawing a path
Rotations
- Rotation around arbitrary axis
Clipping paths in Flutter
Summary
Links

Introduction

Let’s figure out what are the main components of Flutter logo. The letter F consists of 3 beams (2 light blue parallel and 1 dark perpendicular). There’s also a subtle shadow beneath the middle beam dropping onto the leg of the letter. It’s relatively easy to draw the shapes with Paths. We can use the original FlutterLogo widget as a reference.

In order to check how the original FlutterLogo is implemented let’s go to the flutter_logo.dart file in material library. We can immediately see that it’s using AnimatedContainer’s decoration to draw logo with CustomPainter. In my proof of concept I decided that I won’t use decoration to simplify the animation process.

The most useful part is available in _paintLogo method of _FlutterLogoPainter. It stores coordinates of the FlutterLogo that we’re going to use to draw our version of Flutter logo. Most of them will remain unchanged but we will draw the middle beam a bit differently.

In original logo this part is a rotated square painted with Colors.blue[400], whereas in our case it’s going to be a result of overlaying Colors.blue[400].withOpacity(0.8) onto Colors.blue[900]. Take a look how it looks like during the middle beam rotation.

There are some other small changes in the design but I won’t focus on them as most of them are really subtle (e.g. one shadow gradient instead of two as in the original design).

Right now we more or less know how to draw the Flutter logo. We’re going to use CustomPainter and we’ll base our Paths on the original design and colors. But how are we going to animate it?

Implementing complex animations by breaking them down

Whenever we try to implement some complex animations in Flutter it’s worth to apply Marcin Szalek’s principle of breaking down complex animations into series of basic ones. Let’s take a look at the original Flutter logo animation available in the official assets.

Here we can see several things happening at the same time or in a sequence:

Middle beam revealing from bottom
Middle beam rotating around the lower leg with some perspective change
Middle beam flipping around its longer axis when rotated by 90 degrees (this was a surprise!)
Shadow animating/revealing as the middle beam is approaching the canvas plane
Lower leg revealing from top
Top of lower leg following the leg with a slight delay
Top beam revealing from bottom
Top beam and middle beam falling down onto a canvas (slight size change)

It’s almost impossible to keep track of all of these animations in your head so we need to extract them and write down all the timing parameters. Fortunately you can use some tools to split GIFs into separate frames and analyze them manually. On macOS you can just open the GIF in default Preview app to see all the frames one by one.

Now the only thing to do is to take a piece of paper and write down each frame numbers of each part. Easy, isn’t it? (You can check out my parameters in the source code)

Staggered animation

After meticulous analysis of the animation we can start preparing some tweens to provide them to the CustomPainter. After creating all of them it may be a good idea to extract it to separate class (e.g. FlutterLogoController) because right now it may be hard to separate code related to animation from widgets’ code.

I assumed that the logo animation will occupy 60% of the whole AnimationController. It will be equivalent to the 140 frames of the GIF above. For instance the top beam clip is one of the last animations. We can describe the clip position by a single variable.

By using Interval as curve for CurvedAnimation we can select only the desired interval (frames 100-140). Let’s use Curves.easeOutCubic to make its dynamics similar to the original animation.

//frames 100-140
topBeamClip = Tween<double>(begin: 1.0, end: 0.0).animate(
  CurvedAnimation(
    parent: animationController,
    curve: Interval(
      100 / tf * animLimit,
      140 / tf * animLimit,
      curve: Curves.easeOutCubic,
    ),
  ),
);

Now just repeat this for all the parameters of the animation like opacity, rotation, clipping…

Having all the necessary timing and size parameters let’s try to draw the logo.

Drawing the logo

We’re going to use a single CustomPainter. In Flutter it’s extremely easy to start drawing custom shapes and paths. Just create new class that extends CustomPainter and overwrite two methods: paint(Canvas canvas, Size size) and shouldRepaint(CustomPainter oldDelegate). We want CustomPainter to redraw animation on each frame so let’s return true from shouldRepaint.

class AnimatedLogoPainter extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size) {
    // here we will draw our logo
  }

  @override
  bool shouldRepaint(CustomPainter oldDelegate) {
    return true;
  }
}

First let’s position and scale our canvas so that the logo is always in the center. From the original source code we know that logo’s coordinate space is 166x202 px. The logo should be translated by a margin so that it’s centered in x axis (this distance is (202.0 - 166.0) / 2.0).

void paint(Canvas canvas, Size size) {
  final rect = Rect.fromLTWH(0, 0, size.width, size.height);
  // Coordinate space is 166x202 px
  // so we transform canvas and place it in the middle
  canvas.save();
  canvas.translate(rect.left, rect.top);
  canvas.scale(rect.width / 202.0, rect.height / 202.0);
  // Next, offset it some more so that the 166 horizontal pixels are centered
  // in that square (as opposed to being on the left side of it). This means
  // that if we draw in the rectangle from 0,0 to 166,202, we are drawing in
  // the center of the given rect.
  canvas.translate((202.0 - 166.0) / 2.0, 0.0);
  // ...
  canvas.restore();
}

Notice that I’m using canvas.save() method that saves the current canvas operations until the corresponding canvas.restore(). It’s useful if you want to apply several operations (e.g. translation, rotation, clipping) to a selected part/layer of the painting; Each canvas.save() must have closing canvas.restore() method. You can nest them to apply operations to subparts of your canvas and in general I recommend to save a snapshot before drawing each new part of the image. This allows to mentally “separate” operations done to given path or shape.

Drawing a path

In this article let’s just focus on one part of the Flutter logo. You can always check out the source code to see how all of the parts were implemented.

Let’s see how the middle beam was drawn. It’s the most interesting part and we’ll see how it was animated later in the article.

final lightPaint = Paint()..color = Colors.blue[400].withOpacity(0.8);
final Path middleBeam = Path()
  ..moveTo(156.2, 94.0)
  ..lineTo(100.4, 94.0)
  ..lineTo(51.6, 142.8)
  ..lineTo(79.5, 170.7);

canvas.drawPath(middleBeam, lightPaint);
canvas.restore();

We used known coordinates to draw a path and then painted it with lightPaint that by default is filling the bounded area with defined color. The path is closed automatically.

Rotations

The most complicated part of the Flutter logo animation was rotation of the middle beam. It’s not a simple rotation by x or y axis. Firstly, the middle beam is approaching from the bottom left. Then while the top edge is touching the bottom (dark) leg, the rotations around this edge starts. When the beam is perpendicular to the canvas plane there’s an orientation flip. Take a look at the diagram below.

When researching ways to rotate objects on Flutter canvas I couldn’t find a way to easily manipulate it around arbitrary axis. Perhaps it’s possible by combining several transformations (e.g. firstly rotating canvas by 45 degrees and then by one of the primary axes), but I tried to figure out the exact Matrix transformation that is necessary to achieve these rotations.

Rotation around arbitrary axis

I found several math equations that allow to rotate given point around arbitrary axis. The best explanation along with the source code in Java I found on Glenn Murray’s page. Glenn published its Java implementation on Apache license so I decided to port one of the rotation methods to Dart. It was fairly easy to port and the packaged version is available on pub.dev.

In the animation below you can see the small difference if we don’t rotate the beam around its axis when the beam is perpendicular to the canvas.

With the rotation library it’s relatively easy to flip the object. The axis of rotation is [-1.0, 1.0, 0.0] and the object is rotated around point [93.45, 128.85, 0.0] which is in the middle of beam edge. We use the rotation matrix values to transform canvas with canvas.transform(). The beamRotation parameter is value of Tween being used to rotate the beam around its edge.

if (beamRotation > math.pi / 2) {
  // flip the middle beam when on the left side (i.e. rotation angle larger that 90 degrees)
  final rot2 = RotationMatrix(93.45, 128.85, 0.0, -1, 1, 0.0, math.pi);
  final mtx2 = rot2.getMatrix();
  canvas.transform(mtx2);
}

Now let’s focus on rotating the middle beam around its edge. The code for that is even simpler but makes a lot of difference:

final rot = RotationMatrix(79.5, 170.7, 0.0, 1, 1, 0.0, beamRotation);
final mtx = rot.getMatrix();
canvas.transform(mtx);

Now the axis is [1.0, 1.0, 0.0] and the rotation point is [79.5, 170.7, 0.0] which is one of the corners that stay in the sample place during the rotation. We supply the beamRotation parameters which changes from Pi to 0 during the animation:

//frames 63-102, modified
beamRotation = Tween<double>(begin: math.pi, end: 0).animate(
  CurvedAnimation(
    parent: animationController,
    curve: Interval(
      63 / tf * animLimit, //tf is total animation frame count
      110 / tf * animLimit, //animLimit is interval of the animation taken by this tween
      curve: Curves.easeInOutQuad,
    ),
  ),
);

Let’s see how the animation would look like without this rotation. Strange, isn’t it?

In the animation above you can also notice all the other small changes applied to the middle beam during its animation. The top corners are offset additionally to fake the perspective change and the whole element is scaled a bit when the animation finishes.

Clipping paths in Flutter

Very important part of the Flutter logo animation is clipping. The movement is much more dynamic thanks to approaching and revealing animations of the 3 beams.

I used several clipping paths and rectangles that are animated with separate tweens. In the CodePen you can enable drawing the clipping paths in the options menu. Take a look at the gif below and see 3 of them (red, green and yellow).

Each of them corresponds to different element (layer) of the logo. The object is drawn only if it’s within the bounds of the clipping path.

One important remark is that if you want to clip the object with custom path, you have to call canvas.clipPath() before drawing the path. In the snippet below you can see how the middle path was clipped with clippingPath. Note that there are variables used that change based on the animation progress (distance, xDistance). Take a look at the source code for more information.

canvas.save();

final Path middleBeam = Path()
  ..moveTo(
      156.2 + topCornerPerspectiveOffset, 94.0 - topCornerPerspectiveOffset)
  ..lineTo(100.4 + bottomCornerPerspectiveOffset,
      94.0 - topCornerPerspectiveOffset)
  ..lineTo(51.6, 142.8)
  ..lineTo(79.5, 170.7);

final clippingPath = Path()
  ..moveTo(79.5 + distance + margin, 170.7 - distance + margin)
  ..lineTo(107.4 + xDistance + margin + alongMargin,
      142.8 - xDistance + margin - alongMargin)
  ..lineTo(79.5 + xDistance - margin + alongMargin,
      114.9 - xDistance - margin - alongMargin)
  ..lineTo(51.6 + distance - margin, 142.8 - distance - margin);

canvas.clipPath(clippingPath);
canvas.drawPath(middleBeam, lightPaint);
canvas.restore();

Take note that I added some manual adjustments for fake perspective with topCornerPerspectiveOffset and bottomCornerPerspectiveOffset. This was done by eye-balling the correct behavior of the shape when falling down onto canvas.

Summary

After several days I was more or less satisfied with the result. There are still some spots that could be improved and the general code quality could be better (e.g. extracting animations to separate custom controller, not recalculating some invariant animation properties on each frame).

If you reached this part of the article I would like to thank you and suggest that you try similar challenge for yourself. Announcement of CodePen support for Flutter opened new range of creative possibilities that previously were available only for people with own websites. After couple of weeks we can see dozens of awesome Flutter designs being published. Maybe yours will be next?

Planning to release new mobile app? Here are some hints before you click PUBLISH.

Dominik Roszkowski — Tue, 31 Mar 2020 10:24:02 +0000

Here are some of my thoughts after publishing few apps both to AppStore and Google Play over several last months. If you're at the beginning of your developer journey, then it's the guide for you.

The list is taken and redacted from my tweet.

1️⃣ First of all, if you're new developer and it's your first app prepare yourself for a long wait. First review for a new account may be longer both for iOS and Android. On Google Play your app may stay in the "extended review" for couple of days.

2️⃣ Remember to secure the keystore you're using to sign the Android app. You won't be able to use different one after you upload the first release. People really often lose them in unexplained circumstances 🤯

3️⃣ Add some crash reporting to your app. It may be Crashlytics or any other reliable tool. Depending on the popularity you'll see dozens of crashes on some weird devices in the first days. Some of them may be called e.g. Batmobile 🦇(these are bots) but other may be really popular devices.

4️⃣ Consider to automate creation of your screenshots. Maybe implement some mock repository to always get the same data? Or use UI tests and run them on several devices? Depending on the complexity at some point you will detest recreating screenshots manually.

5️⃣ Depending on your attitude to privacy consider adding some kind of analytics. The store dashboards are enough at the beginning, but sooner or later you will want to understand your users better. Some of the state of the art are Firebase Analytics, Mixpanel, CleverTap, Flurry...

6️⃣ The first 50-100 users of your app may be bots e.g. from Google Play pre-launch report or apk aggregators. At some point you may want to disable pre-launch report because of its impact on analytics.

7️⃣ Prepare the privacy policy. If you are complete newbie try to understand what your privacy policy should cover. There are some automated tools to help you create the one for your app. Create separate e-mail alias or account just for this app.

8️⃣ Think about versioning scheme of your app. I highly recommend to use tags in your git repository to have clear understanding of what's in a given release. Maybe start a changelog?

Show the app version label in your app to make error reporting easier.

9️⃣ Remove unused fonts and other assets from your app. Create adaptive icon on Android if you haven't done it yet.

🔟 Think if you need some kind of non-intrusive force update mechanism. In case of some nasty bug you'll be able to upgrade your users faster.

1️⃣1️⃣ Consider a polite way of requesting user rating. Maybe show a snackbar after 5 consecutive launches? Or ask for review after successful process? Or at least add a button in your settings. You will be over the moon through the first 10-20 reviews 😄

🏁 And finally tell your friends and family about your new app. It's hard to reach first 20-50 users and they will definitely help you.

Good luck with your adventure 🎉. Feel free to share your advices if you have some!

You can also read this as a Twitter thread.

Convenient internationalization of Flutter apps

Dominik Roszkowski — Tue, 25 Feb 2020 08:00:00 +0000

There are many ways to have multiple languages in your app in Flutter. Some folks use canonical Flutter arb files. Other use some json equivalents or statically typed constant resources like r_flutter. In this post I’m going to show you the way I find the most convenient to setup and use.

See the short video version:

There's also original post on my blog if you prefer.

Foreword

While researching the i18n[^1] topic I found several different ways of adding multiple languages support in Flutter:

Canonical Flutter way with manual configuration
Using json files and custom localization delegate
Recent semi-automatic proposal of downloading arb files with some custom scripts
Generating constant resources with r_flutter package
Some other fairly popular localization techniques:
- flutter_translate
- easy_localization
- ez_localization
- dynamic auto_localization
- and perhaps several others

As you can see there’s no single best way to handle this right now. All of them share some common steps, though. Together with our colleagues we also have been using a custom localization solution with some bash scripts to fetch and convert localization json files. Unfortunately this causes delays when onboarding new people and starting new projects.

My goal was to find a solution that:

is relatively quick to setup in new project (either is single time manual setup or fully automatic),
supports {placeholders} and preferably plural forms,
would be nice to rely on arb files which are native to Flutter.

After few days of hacking I think I found something that I can share with you.

General overview

Simply speaking my solution is as follows:

Use some tool to translate your app (POEditor, Localizely, Loco, CrowdIn…).
- Not all of them support exporting arb files. In that case export json and convert it to arb with arb-converter-cli[^2]
Fetch translation files from API directly in VS Code (and convert them to arb if necessary)
Automatically generate translation classes with Flutter Intl extension
Be happy with statically typed translations with plurals and placeholder support

This approach requires some configuration steps once but later is mostly automatic due to VS Code extension and tasks in VS Code.

Translation services and arb files

Only few translation services support arb files out of the box. This is the list I came up with:

Localizely - arb supported ✔️
Crowdin - arb supported ✔️ but a bit tricky (e.g. names not changed automatically and source file has to be arb too)
POEditor - not supported, but json can be converted to arb without plural support ✔️
Loco - arb supported, but without placeholders and genders ✔️
Lingohub - not supported
Weblate - not supported
Transifex - not supported
Pootle - not supported

There are also some standalone editors like this web-based (without plurals support) and BabelEdit which is a desktop editor.

In my case the most convenient to use was POEditor, but the json file couldn’t be easily converted to arb[^1]. Thus, I stayed with Localizely for now. Both have free plans that should be enough for smaller apps.

VS Code/Android Studio extension - Flutter Intl

One of the best tools to streamline internationalization of Flutter apps is Flutter Intl extension (also available for Android Studio). It generates the boilerplate getters for translation keys. It will also generate special methods if translation term has placeholder or plural version. Unfortunately, it’s closed source.

The setup is pretty straightforward and I recommend you to read the README.

In short, if you have enabled Flutter Intl extension, then you just put your arb files in l10n directory and the extension generates Dart files for you. The extension automatically updates available locales and generates localization delegate. Then you can reference translation terms in you widgets via:

Text(
    S.of(context).page_home_counter(_counter),
    // 'You have pushed the button {count} times',
),

And if you take a look at the source of the generated method you’ll see typical Flutter intl package handling:

String page_home_counter(dynamic count) {
    return Intl.plural(
        count,
        one: 'You have pushed the button once',
        other: 'You have pushed the button $count times',
        name: 'page_home_counter',
        desc: '',
        args: [count],
    );
}

Fetching translation updates with VS Code

VS Code allows to set custom tasks which are arbitrary shell commands. That’s what I wanted to utilize to semi-automatically fetch translation files from Localizaly or POEditor API. I prepared simple bash script to download arb files from Localizely and json files from POEditor. You can take a look at the tasks.json file in this gist if you want to use them from VS Code. The script is available here.

Wrap up

I hope this short tutorial helped you to improve your internationalization workflow. The arb files are very powerful, but at the same time almost no translation services support it. There is one issue in the Flutter GitHub project that holds the discussion about the simplified i18n process. I really recommend you to read it.

The app code and download script are available in the project repository.

[1^]: i18n stands for internationalization which is just adding multiple languages to the app, whereas l12n stands for localization which is adapting your app to given locale/culture/region (e.g. different layout or navigation).

[2^]: Unfortunately json conversion works for very simple terms without plural version but works OK with placeholders.

Using custom curve in Flutter Hero animations

Dominik Roszkowski — Sat, 21 Sep 2019 23:00:00 +0000

Sometimes the default Hero behavior is not enough and you’d like to add some custom taste to it. One of the simple ways to do it is to customize curve of the transition animation.

In this post you’ll see a sample that allows to use any custom curve to animate bounds of the Hero. In my case it was a bit faster expansion in vertical axis.

Contents

Hero properties
What is createRectTween
How to change the default implementation

Hero properties

Hero class has several convenient properties that allow to customize its behavior. These are:

flightShuttleBuilder that allows to wrap or change entire Hero animation by e.g. adding rotation or fade transition
placeholderBuilder that gives us possibility to show Widget in place previously occupied by the animated widget
createRectTween which is a function that determines the bounds of the Hero during animation - that’s what we want to customize today

What is createRectTween

This property takes a CreateRectTween function which is simply a typedef for Tween<Rect> Function(Rect begin, Rect end).

It means that it interpolates two Rects between begin and end state. By default a RectTween(begin: begin, end: end) is used in Hero. It uses its lerp method which aside from few asserts only interpolates Rect coordinates in linear manner:

static Rect lerp(Rect a, Rect b, double t) {
  assert(t != null);
  if (a == null && b == null)
    return null;
  if (a == null)
    return Rect.fromLTRB(b.left * t, b.top * t, b.right * t, b.bottom * t);
  if (b == null) {
    final double k = 1.0 - t;
    return Rect.fromLTRB(a.left * k, a.top * k, a.right * k, a.bottom * k);
  }
  return Rect.fromLTRB(
    lerpDouble(a.left, b.left, t),
    lerpDouble(a.top, b.top, t),
    lerpDouble(a.right, b.right, t),
    lerpDouble(a.bottom, b.bottom, t),
  );
}

The method lerpDouble is where the interpolation takes place:

double lerpDouble(num a, num b, double t) {
    if (a == null && b == null) return null;
    a ??= 0.0;
    b ??= 0.0;
    return a + (b - a) * t;
}

How to change the default implementation

When defining your Hero you should return a custom createRectTween function like this:

Hero(
    tag: index,
    createRectTween: (begin, end) {
        return CustomRectTween(a: begin, b: end);
    },
    child: Poster(),
),

And finally CustomRectTween has to extend RectTween and to have overwritten lerp method.

The parameter t is animation clock value between 0.0 and 1.0. Each Curve can be used to interpolate any given value between 0.0 and 1.0 on the curve. I use my custom cubic curve in this example.

class CustomRectTween extends RectTween {
  CustomRectTween({this.a, this.b}) : super(begin: a, end: b);
  final Rect a;
  final Rect b;

  @override
  Rect lerp(double t) {
    Curves.elasticOut.transform(t);
    //any curve can be applied here e.g. Curve.elasticOut.transform(t);
    final verticalDist = Cubic(0.72, 0.15, 0.5, 1.23).transform(t);

    final top = lerpDouble(a.top, b.top, t) * (1 - verticalDist);
    return Rect.fromLTRB(
      lerpDouble(a.left, b.left, t),
      top,
      lerpDouble(a.right, b.right, t),
      lerpDouble(a.bottom, b.bottom, t),
    );
  }

  double lerpDouble(num a, num b, double t) {
    if (a == null && b == null) return null;
    a ??= 0.0;
    b ??= 0.0;
    return a + (b - a) * t;
  }
}

It’s important to note that I wanted to change only top coordinate of the Hero’s Rect, so when calculating the value I use (1 - verticalDist) (thus inverting the curve).

I hope you’ll find it useful and try to experiment with Hero widget on your own.

I highly recommend the post Mastering Hero Animations in Flutter by Chema Molins from Flutter Community.

Flavors in Flutter with Fastlane - yet another guide

Dominik Roszkowski — Mon, 15 Jul 2019 19:48:57 +0000

It's a good practice to build separate apps for development, test and production environment. In case of mobile apps a good way to have separate configurations is usage of flavors.

In this tutorial you will learn how to prepare ordinary Flutter project to have 3 different flavors (dev, test and production) and how to handle build, signing and deployment with fastlane.

TL;DR Just go to the repository where all the flavors are already configured.

You can also read the tutorial without large gifs on my blog.

Basics

The concept of flavors is taken from Android apps and can be applied to iOS in various ways (more on this later). By incorporating flavors in your project you can build your app with different configuration options, styles or feature sets. In commercial projects it's a standard way of distributing apps.

There are several great articles on build flavors just to mention:

Creating flavors of a Flutter app (Flutter & Android setup) by Natalie Masse Hooper,
Flavoring Flutter by Salvatore Giordano,
Flutter Ready to Go (flavors, connectivity and more) by Julio Henrique Bitencourt.

In this article I'll show a similar but a subtly different approach and focus mostly on iOS part. Presented way works really well for me and my colleagues. It's been battle tested with several apps already and is getting better with each new project.

For instance our test builds have AppCenter distribution packages to automate updates and additional logging included, dev builds have very verbose logging, and production apps come without unnecessary diagnostics but with production logging configuration.

Flutter comes with built-in flavor support but default project is not prepared to handle them. All it takes to define flavors is to add and edit few files. There are multiple ways to achieve this and with each new project you'll have a chance to improve your approach. Especially on iOS there are multiple ways to provide different bundle ids or configuration parameters.

Fastlane

In my daily job I use fastlane to automate apps deployment to QA and app stores. In this article I will show how to use flavors with fastlane but in general you can handle flavors manually or in typical CI environment like Codemagic or Bitrise.

Fastlane allows you to define specific lanes for each app in code like deploy_to_appcenter or deploy_to_store. A set of files can describe signing, build and deployment phases. Those can be reproduced both on developer's computer, but also on CI/CD platform. Fastlane allows to automate provisioning and signing of iOS apps as well as screenshot capture or updating the description in store. This gives us a very convenient and reproducible way of distributing our app.

There is no native support of Flutter apps in fastlane but we can define fastlane configuration for Android and iOS projects and treat them as typical native apps.

Flavors in Dart

Preparation

In this article I use Flutter v1.7.8+hotfix.3 and demo app is created with Kotlin, AndroidX, and Swift support by:

It's a good practice to create new projects with Kotlin and Swift support. AndroidX is a future of Android development so while starting new project you should definitely have it enabled. You will benefit from Swift later in your project when you'll have to write some platform specific code.

How to configure Flutter project

In order to take the advantage of flavors in Flutter app you should define 3 separate main files¹ that will handle all the configuration details different for each scheme. The easiest way is to rename main.dart to main_common.dart and create:

main_dev.dart
main_tst.dart
main_prod.dart

In each of them you can define respective configuration and later just start execution of the app from a common function.



import 'dart:async';

import 'package:flutter_flavors/app_config.dart';
import 'package:flutter_flavors/main_common.dart';

Future<void> main() async { // async can be useful if you fetch from disk or network
  // do flavor specific configuration here e.g. API endpoints
  final config = AppConfig('tst');

  mainCommon(config);
}

The AppConfig class is a used to store some basic configuration options like name or API endpoints.

In main_common.dart you should replace the 3rd line with:



void mainCommon(AppConfig config) => runApp(MyApp(config));

This step of the configuration you can investigate in commit a4c7ef8e.

How to build or run Flutter project

Typically you would run following commands to build flavored app:

Ordinary apk: flutter build apk --release -t lib/main_tst.dart --build-name=1.0.0 --build-number=1 --flavor tst

App bundle: flutter build appbundle --target-platform android-arm,android-arm64 --release -t lib/main_tst.dart --build-name=1.0.0 --build-number=1 --flavor tst

iOS: flutter build ios --release --no-codesign -t lib/main_tst.dart --build-name=1.0.0 --build-number=1 --flavor tst

Some important things to notice here:

we define build numbers (1) and build names (1.0.0)
we use tst flavor
we skip codesign for iOS (we'll sign our app with fastlane)
we'll sign our android app later

In order to run the app with desired flavor in VS Code you can define your own launch.json configuration. Below you may find a sample I use in my apps. You may copy it to the configuration file that opens when you click the cog wheel on debug pad in VS Code.



{
    "version": "0.2.0",
    "configurations": [
      {
        "name": "Flutter Dev",
        "request": "launch",
        "type": "dart",
        "flutterMode": "debug",
        "program": "lib/main_dev.dart",
        "args": [
          "--flavor",
          "dev"
        ]
      },
      {
        "name": "Flutter Dev Release",
        "request": "launch",
        "type": "dart",
        "flutterMode": "release",
        "program": "lib/main_dev.dart",
        "args": [
          "--flavor",
          "dev"
        ]
      },
      {
        "name": "Flutter Profile",
        "request": "launch",
        "type": "dart",
        "flutterMode": "profile",
        "program": "lib/main_dev.dart",
        "args": [
          "--flavor",
          "dev"
        ]
      },
      {
        "name": "Flutter Test",
        "request": "launch",
        "type": "dart",
        "flutterMode": "release",
        "program": "lib/main_tst.dart",
        "args": [
          "--flavor",
          "tst"
        ]
      },
      {
        "name": "Flutter Prod",
        "request": "launch",
        "type": "dart",
        "flutterMode": "release",
        "program": "lib/main_prod.dart",
        "args": [
          "--flavor",
          "prod"
        ]
      },
    ]
  }

At this point these commands would fail because we haven't defined flavors in Android and iOS apps yet.

Flavors on Android

Defining flavors on Android is really straightforward. The only file to be changed is build.gradle in app directory.

Just add the following lines after buildTypes node and before closing bracket:



    flavorDimensions "flavor-type"

    productFlavors {
        dev {
            dimension "flavor-type"
            applicationIdSuffix ".dev"
            versionNameSuffix "-dev"
            manifestPlaceholders = [appName: "Flavor DEV"]
        }
        tst {
            dimension "flavor-type"
            applicationIdSuffix ".test"
            versionNameSuffix "-test"
            manifestPlaceholders = [appName: "Flavor TST"]
        }
        prod {
            dimension "flavor-type"
            manifestPlaceholders = [appName: "Flavor"]
        }
    }

You can take a look at the exact diff here in commit cef5fbff.

Some important notes here:

we have different app ids for each flavor: com.flutter.flutter_flavor.dev, com.flutter.flutter_flavor.test, and com.flutter.flutter_flavor - this way you can install all 3 apps on a single device, have separate google-services.json files and distinct the app in some logging service or Firebase
we set different app names
we set different version name suffixes e.g. 1.0.0 becomes 1.0.0-test

Flavors on Android allow us to define separate resources for each of them. E.g. you can have a special icon for QA builds or different strings resources.
What you need to do to provide new icon is just create mipmap-... folders with icons in app/src/tst directory. The same works for any other resources and schemes.



app
| - src
   | - debug (default)
   | - main (default)
   | - profile (default)
   | - tst (add this with desired subdirectories)

At this point you should be able to build 3 separate flavors of the app for Android.

Flavors on iOS

Typically, in iOS apps you can base flavors on build schemes. In order to configure this you'll need macOS and Xcode. To start you should open ios/Runner.xcworkspace in Xcode.

Creating schemes

Default scheme for Flutter apps is Runner. We'll define additional 3 schemes named exactly as the previously defined flavors i.e. dev, tst and prod. You should go to Product > Scheme > Manage schemes and add them via + button. Make sure the schemes are marked as Shared.

See the mp4/webm

Then you should add 3 xconfig files to Flutter directory next to Debug, Release and Generated. Right click on Flutter directory on left pad in Xcode and select New File. Select Configuration Settings File and add dev.xconfig, tst.xconfig and prod.xconfig. Make sure they're in Flutter directory as seen on the screenshot below.

These files allow you to define custom variables that can be used later during build or in Info.plist file. We'll define our custom app bundle ids here.

My typical dev.xconfig files look like follows:



#include "Generated.xcconfig"
BUNDLE_ID_SUFFIX=.dev
PRODUCT_BUNDLE_IDENTIFIER=com.flutter.flutterflavors.dev
FLUTTER_TARGET=lib/main_dev.dart
APP_NAME=Flavor DEV

and tst.xconfig (note .test suffix, not .tst²):



#include "Generated.xcconfig"
BUNDLE_ID_SUFFIX=.test
PRODUCT_BUNDLE_IDENTIFIER=com.flutter.flutterflavors.test
FLUTTER_TARGET=lib/main_tst.dart
APP_NAME=Flavor TST

Extending configuration

At this point you should copy and paste some build configurations and assign them to the respective scheme. There will be a lot of clicking and typing now so be patient.

Go to project settings in Xcode, select Runner and then Debug in Configurations section. Press Enter to rename it to Debug-dev. Then duplicate it and call it Debug-tst, and another with Debug-prod. Repeat the procedure for Release and Profile configurations. Then assign previously created schemes to respective configurations. You should end up with following layout:

This should allow you to build your app with different bundle id per flavor. To make sure you can go to Build Settings of Runner target and look for Product Bundle Identifier position.

There is still one problem to be solved. When building the app Flutter takes into account the product bundle identifier visible in General tab of the target properties. So even with tst flavor you'll see following output in console:

Take a look at the wrong bundle id for Release-tst scheme.

Fortunately, if we defined a PRODUCT_BUNDLE_IDENTIFIER variable in our tst.xconfig file this will be overwritten during the build so that generating and signing the .test bundle id will be possible.

Archiving

Finally, we should update each build scheme with correct build configuration.

Go to Product > Schemes > Manage Schemes, select dev and click Edit. Now for each of the processes (Run, Test, Profile, Analyze, Archive) change the build configuration to -dev one. Repeat the process for tst and prod schemes.

Signing iOS app with fastlane

In order to sign and provision your app you'll need Apple developer account and fastlane configured. I recommend creating a separate 'service' account for fastlane only with separate certificate. Create 3 application identifiers in Apple Developer portal e.g. com.flutter.flutterflavors, com.flutter.flutterflavors.test, and com.flutter.flutterflavors.dev.

Go to ios folder in your console and initialize fastlane with manual mode (option 4.). In fastlane folder create Matchfile file next to Fastfile and Appfile.

My typical Matchfile looks like this:



# you should store your provisioning profiles and certs in repository
# this repository is encrypted with MATCH_PASSWORD env variable
git_url(ENV["FASTLANE_GIT"])
storage_mode("git")
username(ENV["FASTLANE_USERNAME"])
team_id(ENV["FASTLANE_TEAM"])
# this is useful on CI/CD if you build test and production app 
# flavors with the same steps configuration
app_identifier(ENV["APP_NAME"])
type("development")

After creating application ids and adding the files you should be able to generate provisioning profiles. Execute following commands and type desired bundle id when prompted:



bundle exec fastlane match development
bundle exec fastlane match adhoc
bundle exec fastlane match release

This whole iOS step can be observed in commit 162d2015.

Rebuilding and signing with fastlane

Unfortunately, it is necessary to rebuild iOS app to archive it and sign before deploying to testers or AppStore³. With custom flavors it is necessary to provide provisioning profile match map manually. I couldn't make the fastlane to detect all profiles automatically. If anyone knows better way to do this, then please share!

My typical Fastfile for QA/test builds looks as follows⁴:



# update_fastlane

default_platform(:ios)

platform :ios do
  desc "Submit a new build to AppCenter"
  lane :test do
    # add_badge(dark: true)
    register_devices(
        devices_file: "fastlane/devices.txt",
        team_id: ENV["FASTLANE_TEAM"],
        username: ENV["FASTLANE_USERNAME"]
    )
    match(
      type: "adhoc",
      force_for_new_devices: true,
    )
    automatic_code_signing(
      use_automatic_signing: false
    )
    update_project_provisioning(
      profile: ENV["sigh_com.flutter.flutterflavors.test_adhoc_profile-path"],
      build_configuration: "Release-tst",
      code_signing_identity: "iPhone Distribution"
    )
    build_app(
      scheme: "tst",
      configuration: "Release-tst",
      xcargs: "-allowProvisioningUpdates",
      export_options: {
        signingStyle: "manual",
        method: "ad-hoc",
        provisioningProfiles: {
          "com.flutter.flutterflavors.test": "match AdHoc com.flutter.flutterflavors.test",
        }
      },
      output_name: "Runner.ipa"
    )
    # upload to AppCenter or anywhere else
  end

  desc "Deploy a new version to the AppStore"
  lane :prod do

  end
end

To build the app with fastlane you should execute just:



bundle exec fastlane ios test

At this point you may encounter a very nasty error that fastlane tries to build com.flutter.flutterflavors.dev instead of com.flutter.flutterflavors.test:

The simplest solution that took me hours to find was just to delete bundle id from General tab in Xcode.

See the mp4/webm

Now you should be able to have you .ipa archive ready to submit to AppCenter, Beta or directly to your testers.

Take a look at the commit a3c5512a to look through all the changes related to fastlane.

Summary

After reading this article you should be able to configure Flutter flavors on your own. There are almost limitless possibilities related to flavors, schemes and configurations. For instance you can have separate Google Services files or Facebook ids for each flavor. You can enable or disable some features for test builds. You can even create multiple apps from single code base.

I hope you learned something with me. See you soon in the next blog post 🖖.

Of course you can define as many flavors as you wish, 3 flavors are a good compromise ↩
On Android you can't define test flavor so we named it tst, but we wanted .test suffix to make it more obvious for QA. You can go with test names and files all the way if you prefer it. ↩
This may be changed in future Flutter versions ↩
I use several plugins to fastlane like badge or appcenter. I really recommend you to check them out. ↩

DEV Community: Dominik Roszkowski

Flutter: Using Android Intent via native interop with jnigen

Getting started

jnigen setup

Usage in Dart

Sending Intents with results

Native interop with Kotlin/Java in Flutter

Some background

Current state of native interop in Dart/Flutter

jnigen

Simple example

Example with platform view

What about Swift

What really grinds my gears in Flutter

Web issues

Default behavior

Tough choice

Scrolling and physics

General feeling

GPU load

Reinventing the wheel

Desktop issues

Shaders and jank issue

Summary

N things I love about Flutter

Hot reload

Open Source

Multi-Platform

Unobstructed access to the underlying platform

Summary

Flutter Animated Logo with CustomPainter

Introduction

Implementing complex animations by breaking them down

Staggered animation

Drawing the logo

Drawing a path

Rotations

Rotation around arbitrary axis

Clipping paths in Flutter

Summary

Links

Planning to release new mobile app? Here are some hints before you click PUBLISH.

Convenient internationalization of Flutter apps

Foreword

General overview

Translation services and arb files

VS Code/Android Studio extension - Flutter Intl

Fetching translation updates with VS Code

Wrap up

Using custom curve in Flutter Hero animations

Hero properties

What is createRectTween

How to change the default implementation

Flavors in Flutter with Fastlane - yet another guide

Basics

Fastlane

Flavors in Dart

Preparation

How to configure Flutter project

How to build or run Flutter project

Flavors on Android

Flavors on iOS

Creating schemes

Extending configuration

Archiving

Signing iOS app with fastlane

Rebuilding and signing with fastlane

Summary