There were some breaking changes between jni 0.14/0.15 and 1.0.0, so if you were using jni and jnigen in the past, you may face some extra work when upgrading. This article was written after I got annoyed with the AI agent incorrect output when working on the migration.

Migration to jni@1.0.0

I found that the quickest way to do it was to comment out all my native integration code first, just to rebuild the Android project and regenerate bindings afterwards.

Some APIs have changed (back) to more reasonable names, e.g., toDartString() is now toString(), or methods for setting properties became setters (_service.onReplyListener(_listener!); is now _service.onReplyListener = _listener!;). There are also some annoying changes like constructor overrides changing numbers, e.g., Intent.new$2 can now be Intent.new$12…

Moreover, the new recommended way to define bindings configuration is no longer a yaml file, but rather a simple Dart script. I quite enjoy this new approach, as it hides the magic behind the code generation, and you can just add some pre- and post-processing logic to the generated code. It seems that the convention will be to put these into the tool/ directory and run them with dart run tool/jnigen.dart or dart run tool/swiftgen.dart.

You can see example migration commits for simple Flutter apps:

• from 0.15 to 1.0.0 here.
• from 0.14 to 1.0.0 here

Below I share some of the lessons I learned while working with jnigen and swiftgen in last few years. In the last few months I managed to update some of my packages:

• screen_brightness_monitor
• play_in_app_update
• uikit_bindings
• android_intent
• foreground_service_interop

jnigen (Android)

Quick recap:

• You can use jnigen to generate Dart bindings for both explicit and compiled Java/Kotlin code.
• Before generating the bindings you need to build the Android app at least once.¹
• You can include both project-specific classes, as well as Android SDK types.
• There are some built-in helpers for common Android utilities, which now have been migrated to package:jni_flutter.

Generator script (tool/jnigen.dart)

Example generator script for a plugin with two classes and one callback interface (callback pattern explained in the next section):

import 'dart:io';
import 'package:jnigen/jnigen.dart';

void main(List<String> args) {
  final packageRoot = Platform.script.resolve('../');
  generateJniBindings(Config(
    outputConfig: OutputConfig(
      dartConfig: DartCodeOutputConfig(
        path: packageRoot.resolve('lib/src/my_plugin.g.dart'),
        structure: OutputStructure.singleFile,
      ),
    ),
    androidSdkConfig: AndroidSdkConfig(
      addGradleDeps: true,
      androidExample: 'example',     // Points to example app for Gradle resolution
    ),
    sourcePath: [packageRoot.resolve('android/src/main/java/')],
    classes: [
      'com.example.MyCallback',       // List ALL classes to bind
      'com.example.MyPlugin',
    ],
  ));
}

Callbacks: use Kotlin interfaces

If you want to receive data back from native code to Dart, the approach I found is to define a callback interface. Then on the Dart side you can wrap it with more user-friendly API like StreamController. Often, it’s sufficient to just expose the callback directly.

Define a dedicated Kotlin interface. jnigen generates a type-safe implement() method and $Mixin:

// Generates BrightnessCallback.implement($BrightnessCallback(...))
@Keep
interface BrightnessCallback {
    @Keep
    fun onBrightnessChanged(brightness: Int)
}

Then in Dart:

final callback = BrightnessCallback.implement(
  $BrightnessCallback(
    onBrightnessChanged: (brightness) { /* ... */ },
    onBrightnessChanged$async: true,  // Non-blocking (listener pattern)
  ),
);
native.startObserving(callback);

Getting access to Context and Activity - package:jni_flutter

There are some small changes to accessing Android Context (androidApplicationContext) and current Activity. It’s now part of the package:jni_flutter. Moreover, to get the current Activity, you need to pass the current engineId.

final engineId = PlatformDispatcher.instance.engineId;
if (engineId == null) {
  print('Error: Engine ID is null');
  return;
}

final activity = androidActivity(engineId);
if (activity == null) {
  print('Error: Activity is null');
  return;
}
activity.as(a.Activity.type).startActivityForResult(intent, 1);

Casting

To cast JObject onto a desired type, use as() with the generated type:

final brightnessMonitor = native.getBrightnessMonitor();
final brightness = brightnessMonitor.as(ScreenBrightnessMonitor.type).brightness;

Arrays

It’s a bit cumbersome, but once you know, you know:

final array = JArray.of<JString>(JString.type, ["cc@example.com".toJString()]);

The $async: true Flag

I found that I’m basically always using async: true for callbacks. There’s some dedicated threading documentation, but not sure how up-to-date it is.

Annotate with @Keep

ProGuard/R8 strips unreferenced classes. Annotate every class, interface, property, and method that jnigen binds:

@Keep
class ScreenBrightnessMonitor(private val context: Context) {
    @get:Keep          // For Kotlin properties, use @get:Keep
    val brightness: Int
        get() = /* ... */

    @Keep
    fun startObserving(callback: BrightnessCallback) { /* ... */ }
}

Issues while regenerating bindings

Sometimes, despite changing Kotlin code and rebuilding with gradle, the jnigen generator may throw errors like Unexpected end of input (at character 1). In my case, the workaround is to rerun the Gradle build without cache.

cd android
./gradlew :your_plugin_name:assembleDebug --no-daemon --console=plain --refresh-dependencies --rerun-tasks
cd ..
dart run tool/jnigen.dart

Memory management

When using jni bindings, you have to remember about native Java objects that are getting referenced on each instantiation.

The overall assumption is that you don’t have to manually manage them. Once all references (in both Java and Dart) to an object are gone, Java’s garbage collector (GC) can reclaim it. Similarly, JObjects attach a native finalizer to their global references. Therefore, when the Dart GC collects them, the underlying Java reference is released.

However, sometimes you may want to control the lifecycle of objects more explicitly. Read more on reference management in the dedicated documentation. To manually release a JNI global reference, call .release() on the Dart side:

void dispose() {
  native.stopObserving();
  callback?.release();
  native.release();
}

swiftgen (iOS)

Swiftgen is still not stable, but I’ve had some success using it so far. The Swift code needs to be compatible with Objective-C, and swiftgen handles the bridging to Dart via swift2objc and ffigen.

I have published package:screen_brightness_monitor that uses swiftgen for iOS bindings.

Generator script (tool/swiftgen.dart)

Similarly to jnigen, I recommend using a Dart script for configuration. Here’s an example for a plugin with one class and one callback protocol:

import 'dart:io';
import 'package:ffigen/ffigen.dart' as fg;
import 'package:logging/logging.dart';
import 'package:swiftgen/swiftgen.dart';

Future<void> main() async {
  final logger = Logger('swiftgen');
  logger.onRecord.listen((record) {
    stderr.writeln('${record.level.name}: ${record.message}');
  });

  final packageRoot = Platform.script.resolve('../');

  // Resolve SDK path/version manually:
  final sdkPath = (await Process.run('xcrun', [
    '--sdk', 'iphoneos', '--show-sdk-path',
  ])).stdout.toString().trim();
  final sdkVersion = (await Process.run('xcrun', [
    '--sdk', 'iphoneos', '--show-sdk-version',
  ])).stdout.toString().trim();

  await SwiftGenerator(
    target: Target(
      triple: 'arm64-apple-ios$sdkVersion',
      sdk: Uri.directory(sdkPath),
    ),
    inputs: [
      ObjCCompatibleSwiftFileInput(
        files: [
          packageRoot.resolve('ios/Classes/MyWidget.swift'),
        ],
      ),
    ],
    output: Output(
      module: 'my_plugin',
      dartFile: packageRoot.resolve('lib/src/my_plugin_ios.g.dart'),
      objectiveCFile: packageRoot.resolve('ios/Classes/my_plugin.m'),
    ),
    ffigen: FfiGeneratorOptions(
      objectiveC: fg.ObjectiveC(
        interfaces: fg.Interfaces(
          include: (decl) => decl.originalName == 'MyWidget',
        ),
        protocols: fg.Protocols(
          include: (decl) => decl.originalName == 'MyCallback',
        ),
      ),
    ),
  ).generate(logger: logger);
}

ObjCCompatibleSwiftFileInput vs SwiftFileInput

• SwiftFileInput: For pure Swift code. swift2objc wraps it in ObjC-compatible wrappers.
• ObjCCompatibleSwiftFileInput: For Swift code that’s already @objc annotated. Skips the wrapping step – simpler, fewer surprises. Prefer this when you control the Swift code.

Writing ObjC-compatible Swift

All types exposed to Dart must be @objc annotated and inherit from NSObject (for classes):

// Protocol — callback interface
@objc public protocol BrightnessCallback {
    @objc func onBrightnessChanged(_ brightness: Int)
}

// Class — must inherit NSObject
@objc public class ScreenBrightnessMonitor: NSObject {
    @objc public override init() { super.init() }

    @objc public var brightness: Int { /* ... */ }

    @objc public func startObserving(callback: BrightnessCallback) { /* ... */ }
    @objc public func stopObserving() { /* ... */ }
}

Rules:

• Classes must inherit NSObject (direct or indirect).
• Use @objc public on everything ffigen should see.
• Overriding init() requires override + calling super.init().
• Only ObjC-compatible types work: Int, String, Bool, NSObject subclasses, protocols. No Swift structs, enums with associated values, or generics.

ffigen include filters

By default, ffigen generates bindings for everything in the ObjC header. Use include filters to limit output to your types only:

ffigen: FfiGeneratorOptions(
  objectiveC: fg.ObjectiveC(
    interfaces: fg.Interfaces(
      include: (decl) => decl.originalName == 'ScreenBrightnessMonitor',
    ),
    protocols: fg.Protocols(
      include: (decl) => decl.originalName == 'BrightnessCallback',
    ),
  ),
),

Without filters, you’ll get bindings for NSObject, NSString, etc. – hundreds of unnecessary lines.

Implementing ObjC protocols in Dart

swiftgen/ffigen generates three flavors for each protocol:

For observer/notification patterns, use implementAsListener:

final callback = BrightnessCallback$Builder.implementAsListener(
  onBrightnessChanged_: (brightness) {
    controller.add(brightness);
  },
);
native.startObservingWithCallback(callback);

SDK version workaround

When building my package, I found that Target.iOSArm64Latest() may crash with FormatException if swift2objc’s _parseVersion regex can’t parse your Xcode SDK version string. The workaround is to resolve the SDK path and version manually via xcrun and construct the Target directly (see generator script above). Perhaps I did something wrong?

Generated files

swiftgen produces two files:

1. Dart bindings (lib/src/..._ios.g.dart) – extension types wrapping ObjC objects
2. ObjC bindings (ios/Classes/....m) – C functions that ffigen’s Dart code calls via dart:ffi

Both must be committed. The .m file must be in a location picked up by the podspec (Classes/**/*).

ObjC method names (iOS)

Swift func startObserving(callback:) becomes startObservingWithCallback: in ObjC (and thus in the Dart binding). Check the generated .g.dart for actual method names.

Podspec source_files

Must include both the Swift source and the generated .m file. Classes/**/* covers both.

Cross-platform Dart wrapper

Neither jnigen nor swiftgen will generate a single API for both platforms (as opposed to package:pigeon). Below I share a simple pattern I used in my plugin to expose a common API to users.

Abstract class + factory constructor

Define an abstract class with a factory constructor that instantiates the correct platform implementation at runtime:

// lib/src/brightness_monitor.dart
import 'dart:io' show Platform;
import 'brightness_monitor_android.dart';
import 'brightness_monitor_ios.dart';

abstract class BrightnessMonitor {
  factory BrightnessMonitor() {
    if (Platform.isAndroid) return BrightnessMonitorAndroid();
    if (Platform.isIOS) return BrightnessMonitorIos();
    throw UnsupportedError('Unsupported platform');
  }

  int get brightness;
  Stream<int> get onBrightnessChanged;
  void dispose();
}

Each platform file imports only its own generated bindings, so platform-specific dart:ffi symbols don’t conflict.

Keep a Dart-side reference to callbacks

Even with a strong Swift reference, store the callback object in a field (_callback) on the Dart side too. If it’s only a local variable in _startObserving(), the Dart GC can collect the closure backing the protocol proxy, breaking the callback silently. Clean it up in _stopObserving():

BrightnessCallback? _callback;

void _startObserving() {
  _callback = BrightnessCallback$Builder.implementAsListener(
    onBrightnessChanged_: (b) { _controller?.add(b); },
  );
  _native.startObservingWithCallback(_callback!);
}

void _stopObserving() {
  _native.stopObserving();
  _callback = null;
}

Android vs iOS API comparison

Final words

I’ve been using jni, jnigen, ffi, and swiftgen for over a year now. The setup experience requires some effort, but once you have the bindings ready, it’s pretty smooth sailing². I wish the docs included more examples, though. I hope this short article will help others get started faster and give future AI models a bit more native-interop content in their corpus.

Here’s what I built:

• starting and binding to a foreground service from Flutter
• requesting and checking for notification permissions directly from Dart
• sending messages from Flutter to foreground service
• receiving messages from foreground service notification as if it was a messaging app

I first started with more traditional approach of having a plugin class that proxied calls to the foreground service, but after some chats with my friend we realized we can skip this step and bind directly to the service from Flutter.

Let’s recap some useful helpers included in jni:

• Jni.androidApplicationContext - needed to start the service and send messages to it
• jni.Jni.androidActivity(engineId) and PlatformDispatcher.instance.engineId - needed to request notification permissions

jnigen configuration 2026

Currently the best way to configure jnigen is to use Dart script like following:

import 'dart:io';

import 'package:jnigen/jnigen.dart';

void main(List<String> args) {
  final packageRoot = Platform.script.resolve('../');
  generateJniBindings(
    Config(
      outputConfig: OutputConfig(
        dartConfig: DartCodeOutputConfig(
          path: packageRoot.resolve(
            'lib/src/foreground_service_interop_plugin.g.dart',
          ),
          structure: OutputStructure.singleFile,
        ),
      ),
      androidSdkConfig: AndroidSdkConfig(
        addGradleDeps: true,
        androidExample: 'example',
      ),
      sourcePath: [packageRoot.resolve('android/src/main/java')],
      classes: [
        'com.example.foreground_service_interop_plugin.ExampleForegroundService',
        'com.example.foreground_service_interop_plugin.ReplyListenerProxy',
        'android.content.ServiceConnection',
        'android.content.Intent',
        'android.content.Context',
        'android.app.Activity',
        'androidx.core.content.ContextCompat',
        'androidx.core.app.ActivityCompat',
      ],
    ),
  );
}

On each native change you have to rebuild the example app with flutter build apk and then run this script to regenerate bindings via dart tool/jnigen.dart.

Permissions

Before you can spawn a foreground service, you need to request POST_NOTIFICATIONS permission on Android 13+.

For that we have to bind androidx.core.content.ContextCompat and androidx.core.app.ActivityCompat. Then the permissions can be requested and checked synchronously:

void requestPermission() {
    final engineId = PlatformDispatcher.instance.engineId;
    if (engineId == null) {
        print('Engine ID is null, cannot request permission');
        return;
    }
    // This is how you cast the Android Activity from JNI
    final activity = jni.Jni.androidActivity(engineId)?.as(native.Activity.type);
    if (activity == null) {
        print('Activity is null, cannot request permission');
        return;
    }

    native.ActivityCompat.requestPermissions(
        activity,
        jni.JArray.of(jni.JString.type, ['android.permission.POST_NOTIFICATIONS'.toJString(),]),
        0,
    );

    // set timer to poll for permissions (up to 30 seconds)
    Timer.periodic(const Duration(seconds: 1), (timer) {
        final granted = checkPermission();
        if (granted) {
            setState(() {
                hasPermission = true;
            });
            timer.cancel();
        } else {
            print('Permission not granted yet, checking again...');
        }
    });
}

bool checkPermission() {
    final context = jni.Jni.androidApplicationContext.as(native.Context.type);

    final result = native.ContextCompat.checkSelfPermission(
        context,
        'android.permission.POST_NOTIFICATIONS'.toJString(),
    );
    return result == 0;
}

Starting and binding to foreground service

Having the permissions granted, we can start the foreground service and bind to it directly from Flutter. We’ll need to bind android.content.Context and android.content.Intent for that.

void startAndBind() {
    final context = jni.Jni.androidApplicationContext.as(native.Context.type);
    final intent = native.Intent.new$1(
        context,
        native.ExampleForegroundService.type.jClass,
    );
    context.bindService$1(
        intent,
        serviceConnection,
        native.Context$BindServiceFlags.of(native.Context.BIND_AUTO_CREATE),
    );

    setState(() {});
}

When connecting to service a android.content.ServiceConnection is needed. We are going to implement it in a familiar way by passing implementation proxy object.

@override
void initState() {
    super.initState();

    serviceConnection = native.ServiceConnection.implement(
        native.$ServiceConnection(
        onServiceConnected: (componentName, iBinder) {
            localBinder = iBinder?.as(native.ExampleForegroundService$LocalBinder.type);
            service = localBinder?.getService();

            // Converting proxy callback to stream subscription
            repliesSubscription = service?.replyStream.replies.listen((reply) {
                setState(() {
                    messages.add((DateTime.now(), 'Service', reply));
                });
            });

            setState(() {});
        },
        onServiceDisconnected: (componentName) {
            service = null;
            localBinder = null;
            repliesSubscription?.cancel();
            setState(() {});
        },
        onBindingDied: (componentName) {
            //
        },
        onNullBinding: (componentName) {
            //
        },
        ),
    );
}

This time instead of using callbacks via proxy, I created a wrapper to convert from them to stream (service?.replyStream.replies). You can check out the implementation here. This makes the API much more Dart-like in my opinion.

Sending and receiving messages

Once we have access to the service, we can invoke receiveMessage method to update the notification message. Messages from the notification are received via the replyStream as shown in the previous code snippet.

void sendMessage() {
  if (service != null) {
    final msg = 'Hello from Flutter at ${DateTime.now()}';
    messages.add((DateTime.now(), 'Flutter', msg));
    service?.receiveMessage(msg.toJString());
  }
  setState(() {});
}

Final thoughts

It’s really cool, what possibilities are now open with jni and jnigen. Step-by-step, it was possible to access Android’s foreground service API directly from Dart without any method channels or plugin classes. The API is pretty clean and Dart-like, especially with some wrapper classes to convert callbacks to streams.

Click here for the full source code.

Final tips:

1. It is very important to cast JObject using as(ClassName.type) extension method rather than Dart’s as keyword.
2. On each change to the native code, make sure to run flutter build apk in the example code and then regenerate bindings with dart tool/jnigen.dart.

Thoughts about LLMs and jnigen.

From my experience, current AI models are not really up to date with jnigen possibilities. So here’s my little contribution - let LLMs feed on this data and use my way to access native code in Flutter ;)

Repository

package: play_in_app_update.

It is a thin layer over Play Core native libs generated with jnigen, so you call the same API you would in Kotlin, just from Dart. Works on Android 5.0+ (SDK 21) and supports both update types. See jnigen.dart for details how it’s been generated.

Example app includes a simple UI to trigger updates and shows how to listen to update state changes. You can check the README for testing and usage instructions.

Besides low-level access to the API that lets you use Android’s docs as if they were written for Dart, there’s also a more Flutter-friendly high-level API that uses Dart idioms (see wrapper.dart and corresponding example code).

If you end up shipping it in production and notice any rough edges, feel free to create issue.

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.

Last year a first preview of macros support arrived and we all got quite excited. For me the most fun were improvements to equatable and json serialization. It looked promising and since then we were basically waiting for more updates.

The explanation we are given in the post paints a picture of much more complicated situation than might be expected. Seems like the rippling effect of the macros feedback loop would degrade the overall developer experience by slowing down the analysis and compilation times significantly — in a way that the Dart team could not find solutions for. I am known to complain about slow analyzer a lot (mostly due to big monorepo projects using hundreds of barrel files etc.) and even with recent pub workspace update it’s not really the smoothest ride. Hence, for me if the macros would make my work slower, I don’t think I’d be the most avid user of them.

Seems like the common code generation with build_runner is going to stay with us for much longer. I hope that at least some form of more convenient serialization is going to arrive — you can check recent RFP from Kilian Schulte (discussion post) that tries to solve this in a more generalized way than just focusing on json serialization only.

In the meantime stay safe!

The concept of simulation is present in Flutter, but I’ve always found it a bit tricky to implement. I tried it few times, but eventually would switch to either custom calculations or basic curves.

Normally when building this kind of pseudo-3d movement you wouldn’t use typical tweens and curves, as they lack inertia. With flutter_physics you can follow the same approach as with any animation, but just replace the controller with PhysicsController or TweenAnimationBuilder with PhysicsBuilder. In the example above the card starts to move more naturally and just feels better to the eye and finger.

One area where I feel the physics-based animation would be beneficial is bottom sheet movement. I think most of the implementations, including the Flutter bottom sheets, don’t feel as nice as some of the provided by iOS. I’d love to change it and will experimented with using flutter_physics for sheets animations.

Here’s the behavior with ordinary Flutter AnimationController:

And here after just replacing the controller with PhysicsController (via adapter - source code below):

If you want to try something refreshing, play with the flutter_physics and maybe share some feedback about how you approach animations with John Ryan here on the Flutter Forum.

Source code

import 'package:flutter/material.dart';
import 'package:flutter_physics/flutter_physics.dart';

class AnimationsControllerAdapter implements AnimationController {
  AnimationsControllerAdapter(this.physicsController);

  final PhysicsController physicsController;

  @override
  Duration? get duration => physicsController.duration;

  @override
  set duration(Duration? value) {
    physicsController.duration = value;
  }

  @override
  Duration? get reverseDuration => physicsController.reverseDuration;

  @override
  set reverseDuration(Duration? value) {
    physicsController.reverseDuration = value;
  }

  @override
  double get value => physicsController.value;

  @override
  set value(double value) {
    physicsController.value = value;
  }

  @override
  void addListener(VoidCallback listener) {
    physicsController.addListener(listener);
  }

  @override
  void addStatusListener(AnimationStatusListener listener) {
    physicsController.addStatusListener(listener);
  }

  @override
  TickerFuture animateBack(double target,
      {Duration? duration, Curve curve = Curves.linear}) {
    return physicsController.animateTo(
      target,
      duration: duration,
      physics: curve,
    );
  }

  @override
  TickerFuture animateTo(double target,
      {Duration? duration, Curve curve = Curves.linear}) {
    return physicsController.animateTo(
      target,
      duration: duration,
      physics: curve,
    );
  }

  @override
  TickerFuture animateWith(Simulation simulation) {
    return physicsController.animateWith(simulation);
  }

  @override
  AnimationBehavior get animationBehavior =>
      physicsController.animationBehavior;

  @override
  void clearListeners() {
    physicsController.clearListeners();
  }

  @override
  void clearStatusListeners() {
    physicsController.clearStatusListeners();
  }

  @override
  String? get debugLabel => physicsController.debugLabel;

  @override
  void didRegisterListener() {
    // TODO: implement didRegisterListener
  }

  @override
  void didUnregisterListener() {
    physicsController.didUnregisterListener();
  }

  @override
  void dispose() {
    physicsController.dispose();
  }

  @override
  Animation<U> drive<U>(Animatable<U> child) {
    return physicsController.drive(child);
  }

  @override
  TickerFuture fling(
      {double velocity = 1.0,
      SpringDescription? springDescription,
      AnimationBehavior? animationBehavior}) {
    return physicsController.fling(
      velocity: velocity,
      springDescription: springDescription,
      animationBehavior: animationBehavior,
    );
  }

  @override
  TickerFuture forward({double? from}) {
    return physicsController.forward(from: from);
  }

  @override
  bool get isAnimating => physicsController.isAnimating;

  @override
  bool get isCompleted => physicsController.isCompleted;

  @override
  bool get isDismissed => physicsController.isDismissed;

  @override
  bool get isForwardOrCompleted => physicsController.isForwardOrCompleted;

  @override
  Duration? get lastElapsedDuration => physicsController.lastElapsedDuration;

  @override
  double get lowerBound => physicsController.lowerBound;

  @override
  void notifyListeners() {
    physicsController.notifyListeners();
  }

  @override
  void notifyStatusListeners(AnimationStatus status) {
    physicsController.notifyStatusListeners(status);
  }

  @override
  void removeListener(VoidCallback listener) {
    physicsController.removeListener(listener);
  }

  @override
  void removeStatusListener(AnimationStatusListener listener) {
    physicsController.removeStatusListener(listener);
  }

  @override
  TickerFuture repeat(
      {double? min,
      double? max,
      bool reverse = false,
      Duration? period,
      int? count}) {
    return physicsController.repeat(
      min: min,
      max: max,
      reverse: reverse,
      period: period,
      count: count,
    );
  }

  @override
  void reset() {
    physicsController.reset();
  }

  @override
  void resync(TickerProvider vsync) {
    physicsController.resync(vsync);
  }

  @override
  TickerFuture reverse({double? from}) {
    return physicsController.reverse(from: from);
  }

  @override
  AnimationStatus get status => physicsController.status;

  @override
  void stop({bool canceled = true}) {
    physicsController.stop(canceled: canceled);
  }

  @override
  String toStringDetails() {
    return physicsController.toStringDetails();
  }

  @override
  TickerFuture toggle({double? from}) {
    throw UnimplementedError('toggle is not implemented yet');
  }

  @override
  double get upperBound => physicsController.upperBound;

  @override
  double get velocity => physicsController.velocity;

  @override
  Animation<double> get view => physicsController.view;
}

class BottomSheetPage extends StatefulWidget {
  const BottomSheetPage({super.key});

  @override
  State<BottomSheetPage> createState() => _BottomSheetPageState();
}

class _BottomSheetPageState extends State<BottomSheetPage>
    with TickerProviderStateMixin {
  late PhysicsController controller;

  @override
  void initState() {
    controller = PhysicsController(vsync: this);
    super.initState();
  }

  @override
  void dispose() {
    controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: ElevatedButton(
          onPressed: () {
            showModalBottomSheet(
              context: context,
              transitionAnimationController:
                  AnimationsControllerAdapter(controller),
              builder: (context) {
                return Container(
                  height: 200,
                  color: Colors.blueGrey,
                  child: Center(
                    child: Column(
                      mainAxisAlignment: MainAxisAlignment.center,
                      mainAxisSize: MainAxisSize.min,
                      children: <Widget>[
                        const Text('Modal BottomSheet'),
                        ElevatedButton(
                          child: const Text('Close BottomSheet'),
                          onPressed: () => Navigator.pop(context),
                        ),
                      ],
                    ),
                  ),
                );
              },
            );
          },
          child: Text('Show bottom sheet'),
        ),
      ),
    );
  }
}

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.

See also my new article on using Android APIs from Dart.

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.

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

Not sure how about you, but lately I’ve been getting impression that Flutter ecosystem has been affected by some pessimistic or defeatist claims, sometimes even overshadowing other good news or experiments. Thankfully, coming again to a big event makes you realize that online chatter is not the whole picture.

If you’re not in the twitters and reddits of the web, here’s a quick recap of the most impactful voices either commenting or responding to claims that Flutter can be killed by Google:

• Joint blog note from Directors of Android and Flutter on selecting the toolkit for mobile apps, note that Jetpack Compose Multiplatform is not mentioned
• How big is the Flutter team by Hixie, who’s no longer at Google, but still actively contributing
• Layoffs at Google affecting Flutter - viral post that put focus on Flutter
• Response from Michael Thomsen, Flutter PM, where he tries to cut the discussion

Same as many of you I sometimes get a bit of FUD, but in the long run, I see how the general trajectory of the framework and ecosystem maintains stable. To support this, let’s recap some of the exiting news and showcases from this year’s Fluttercon.

Platform Views and the big thread merging

The Flutter TL John McCutchan had a quite insightful talk about Platform Views on Android. It was refreshing to see the team admitting to mistakes in the current implementation, as well as proposing a long-term plan of fixing that. The only issue is that these fixes will only be enabled by the upcoming Android SDKs (34 and 35) which means that we’ll have to deal with current limitations for another year or two. Aside from that they confirmed that there’s a plan on merging platform and Flutter UI thread, which sparked a lot of discussion e.g. around native interop (things like method channels, ffi, JNI).

Folks from the Dart team have shown the jnigen tool that enables calling Java and Kotlin code directly from Dart, avoiding message passing through method channels. In short you could potentially invoke Kotlin plugin functions through simple Dart interface like in this example:

void showNotification(String title, String text) {
  i = i + 1;
  var jTitle = JString.fromString(title);
  var jText = JString.fromString(text);
  Notifications.showNotification(activity, i, jTitle, jText);
  jTitle.release();
  jText.release();
}

Some experiments are in progress to bring similar syntax to Swift through ObjC.

Personally, I find this to be a really solid response to Kotlin Multiplatform expect and actual declarations.

Visuals, animations, shaders

As it often happens, the most impressive talks are the ones that play with visuals. I got impressed by Raouf Rahiche’s take on fragment shaders, reminding me of last year’s shader talk by Renan Araujo (missed you!).

Btw check out the new project bringing some amazing shaders straight to Flutter: fluttershaders.com

Compose

I went to couple of Compose and Compose Multiplatform talks just to see what makes the Android devs excited. Seems like Compose is doing well, although I can’t get rid of the uncanny feeling that it’s taking best from Flutter while keeping entire Android toolchain weight to deal with. Worth keeping an eye on Jetbrains efforts on Multiplatform as they are facing quite similar challenges as Flutter, while being able to avoid some of the dead ends that Flutter had to face (e.g. with multi window support, native interop).

Social battery charged

During my talk I asked folks what are the types of the apps that they work on and the response from over 200 people who scanned the QR code makes me feel joyful.

To all the people I met and ones I missed - you’re doing amazing job, and I couldn’t be more happy to be part of this community. Thanks to all the organizers, speakers, and attendees for making this event so special. I’m looking forward to the next one!

This year Droidcon Berlin decided to expand its typical Flutter track to a standalone event - Fluttercon. I must say that it felt like Fluttercon became bigger than the Droidcon itself. Flutter merch, speakers, booths and discussions were visible everywhere.

In this short note I just wanted to highlight couple of remarkable talks and findings.

Sign up to 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!

First of all, it’s been amazing to see a significant number of first-time speakers breaking through the typical bubble of Flutter insiders. The variety of names and cultures, especially outside of Europe made this event really welcoming and inspiring.

Moreover, the quality of the talks itself has been splendid. The deep dives, complex showcases and fantastic demos made it all super engaging.

Some talks I enjoyed a lot:

• Demystifying Text Rendering in Flutter by Raouf Rahiche
• How Custom RenderObjects can make your life easier by Romain Rastel
• Healthy Code: A guide to Flutter App audit by Daria Orlova
• Shaders: beyond the gimmick by Renan Araujo
• Stop Treating Accessibility as an Afterthought: Concrete Steps to Build Inclusive Apps by Manuela Sakura Rommel

It was super inspiring to listen to Eric Seidel talk about the future of Flutter ecosystem from outside of the Google perspective. Many of us rely on Google building the entire platform, but at the same time there’s so much opportunity for us - developers and users, to build solid experiences around the fantastic Flutter foundations.

Lastly, I wanted to say thank you to everyone attending my talk on Thursday afternoon. Seeing the full room was so stressful, but at the same time gave me a lot of energy to talk about the project I helped to build.

I spoke about the journey we had to take while migrating Visible from being quite naive in terms of network reliability to almost completely offline-capable app. We’ve spent over an hour after the talk discussing various ideas and problems other folks in the community have. I got several Twitter DMs talking about similar struggles.

Here are the materials and slides btw.

Thanks for the amazing feedback and I hope to chat about offline-first architecture again!

In this article we’re going to go through basics of platform views, their benefits and limitations, as well as we’ll look into displaying them on platforms that are not yet officially supported. Let’s dig in!

This article is pretty bulky as I wanted it to be a comprehensive lookup doc for myself 🤪. Some information may be easily found in the official (splendid) docs, other is just my personal findings and opinion. Feel free to jump to a specific section using the table of contents.

How Platform Views are Displayed

When trying to understand how platform views are getting displayed in Flutter it’s worth to look at this in a simplified form first. Below you see some of the main pieces necessary to display a platform view with no iOS or Android specifics.

Anytime you want to display a native view you’ll start with your custom widget wrapper (in this case referred to as Flutter Widget). It’s going to render a UiKitView on iOS or PlatformViewLink on Android that come from Flutter’s widgets library.

On the native side you will need to use plugin (view) registry to register your view factory that will be responsible for providing a Flutter PlatformView implementation. The specific implementation will have to render a corresponding view for a given platform (UIView for iOS/macOS, View for Android).

iOS

We’ll start with iOS as the setup here is the most straightforward. There’s only one type of platform views that we can use on iOS and it uses a method called hybrid composition.

Hybrid composition is the platform view rendering mode where the view is appended to the view hierarchy. If you’d open Xcode’s view debugging utility you’d see the native UIKit view hovering above the FlutterViewController.

This approach has some obvious benefits. For instance, iOS is aware of the view features such as accessibility. It can handle gestures and text input properly. As you may imagine, when Apple releases some new features such as Apple Pencil scribble support, it may take some time to fully support that in Flutter. By leveraging native views we can get some of that at relatively low cost. One of the best examples may be flutter_native_text_input library that lets us use system-specific text fields instead of rendering them with Flutter. It’s definitely not the most seamless experience, but I can imagine situations when there is no better workaround than falling back to UITextView.

Sign up to 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!

How to implement an iOS view in Flutter?

In this tutorial we’ll go through some major steps when it comes to creating a native view in Flutter. I’d like us to follow decent practices of building plugins (practically speaking the native view is a form of plugin), so to get a head start we’re going to use a federated plugin template and plugin_platform_interface. This way the resulting code will be much easier to extend to other platforms.

If you’d like to see a more complex example of native view that is being migrated to a federated plugin template, have a look at the webview migration design document.

The goal

To make it easier to follow, for now we’ll just show a couple of native labels. Later on we’ll move to something more exciting, but there’s still a bit of code to go through before we can display meaningful elements on the screen.

For iOS our goal is to display a SwiftUI stack. It’s still a UIKit view, but it’s hosting a SwiftUI controller that allows us to write layout code in a more declarative way.

Setup

To make your life even easier you can generate the plugin template code via the very_good_cli. Once done you should see structure similar to following:

• Dart platform agnostic code in the main package
• Platform specific code in the packages per each platform
• Common plugin interface defined in PlatformInterface
• Example application

Using PlatformInterface class from plugin_platform_interface package helps to keep consistent API between platforms and prevents usage of extends in favor of implements when implementing platform code.

In my case I started with defining the Widget getPlatformView() method in the PlatformInterface and putting placeholders in every platform package. This way I will be forced to keep consistent API between all the platforms. Then in my Dart package I defined a common widget that I will display in my app called NativeView.

// camera_view/camera_view_platform_interface/lib/camera_view_platform_interface.dart

/// The interface that implementations of camera_view must implement.
abstract class CameraViewPlatform extends PlatformInterface {
...
  /// Returns the platform specific widget
  Widget getPlatformView();
}

// camera_view/camera_view/lib/camera_view.dart

CameraViewPlatform get _platform => CameraViewPlatform.instance;

class NativeView extends StatelessWidget {
  const NativeView({super.key});

  @override
  Widget build(BuildContext context) {
    return _platform.getPlatformView();
  }
}

If you’d build the app now, it would just fail. Let’s move on to implementing the iOS view on the Dart side.

iOS view - Dart side

The Dart implementation for a view is fairly straightforward. The UiKitView is a widget that wraps PlatformViewLayer with a user-friendly API. The most important argument is viewType that needs to be reused in the Swift code as well.

As mentioned before there’s only one way to render a platform view on iOS, so we don’t have to worry about the logic here.

class _UiKitBox extends StatelessWidget {
  const _UiKitBox({super.key});

  @override
  Widget build(BuildContext context) {
    // This is used in the platform side to register the view.
    const viewType = '@views/native-view';
    // Pass parameters to the platform side.
    final creationParams = <String, dynamic>{};
    return UiKitView(
      viewType: viewType,
      layoutDirection: TextDirection.ltr,
      creationParams: creationParams,
      gestureRecognizers: const <Factory<OneSequenceGestureRecognizer>>{
        Factory<OneSequenceGestureRecognizer>(
          EagerGestureRecognizer.new,
        ),
      },
      creationParamsCodec: const StandardMessageCodec(),
    );
  }
}

To expose _UiKitBox outside of the package the getPlatformView() method can be used. This way consumers of the package won’t be affected when the implementation details change.

class NativeViewIOS extends CameraViewPlatform {
  // …

  @override
  Widget getPlatformView() {
    return const _UiKitBox();
  }
}

iOS - Swift side

To conveniently edit Swift code you should open the example app in Xcode (specifically Runner.xcworkspace file). I tend to use command line for that by calling

open native_view/native_view/example/ios/Runner.xcworkspace/

Make sure to run flutter pub get and pod install for the app iOS project and head off to the plugin code. That’s what usually makes me laugh as you have to go through several levels of folders in order to access Swift files of your plugin.

#import "NativeViewPlugin.h"
#if __has_include(<native_view_ios/native_view_ios-Swift.h>)
#import <native_view_ios/native_view_ios-Swift.h>
#else
// Support project import fallback if the generated compatibility header
// is not copied when this plugin is created as a library.
// https://forums.swift.org/t/swift-static-libraries-dont-copy-generated-objective-c-header/19816
#import "native_view_ios-Swift.h"
#endif

@implementation NativeViewPlugin
+ (void)registerWithRegistrar:(NSObject<FlutterPluginRegistrar>*)registrar {
  [SwiftNativeViewPlugin registerWithRegistrar:registrar];
}
@end

import Flutter
import UIKit

@available(iOS 13.0, *)
public class SwiftNativeViewPlugin: NSObject, FlutterPlugin {
  public static func register(with registrar: FlutterPluginRegistrar) {
    let channel = FlutterMethodChannel(name: "native_view_ios", binaryMessenger: registrar.messenger())
    let instance = SwiftNativeViewPlugin()
    registrar.addMethodCallDelegate(instance, channel: channel)
  }

  public func handle(_ call: FlutterMethodCall, result: @escaping FlutterResult) {
    switch call.method {
    case "getPlatformName":
      result("iOS")
    default:
      result(FlutterMethodNotImplemented)
    }
  }
}

Once you have your Swift environment prepared you should be able to start writing some platform views code. For this example I wanted to try out embedding a SwiftUI view within Flutter. In order to do that a UIHostingController can be used.

Firstly, the view factory needs to be registered in the FlutterPluginRegistrar, obviously in the method called register().

let factory = FLNativeViewFactory(messenger: registrar.messenger)

registrar.register(factory, withId: "@views/native-view")

The implementation of FLNativeViewFactory is mostly a boilerplate, where in the create function we need to return the displayed view:

@available(iOS 13.0, *)
class FLNativeViewFactory: NSObject, FlutterPlatformViewFactory {
    private var messenger: FlutterBinaryMessenger

    init(messenger: FlutterBinaryMessenger) {
        self.messenger = messenger
        super.init()
    }

    func create(
        withFrame frame: CGRect,
        viewIdentifier viewId: Int64,
        arguments args: Any?
    ) -> FlutterPlatformView {
        return FLNativeView(
            frame: frame,
            viewIdentifier: viewId,
            arguments: args,
            binaryMessenger: messenger)
    }
}

The most interesting part is FLNativeView which will host the SwiftUI view:

@available(iOS 13.0, *)
class FLNativeView: NSObject, FlutterPlatformView {
    private var _view: UIView

    init(
        frame: CGRect,
        viewIdentifier viewId: Int64,
        arguments args: Any?,
        binaryMessenger messenger: FlutterBinaryMessenger?
    ) {
        _view = UIView()
        super.init()
        _view.backgroundColor = UIColor.gray
        let childView = UIHostingController(rootView: SwiftUIView())
        childView.view.frame = frame
        _view.addConstrained(subview: childView.view)
        childView.didMove(toParent: _view.inputViewController)
    }

    func view() -> UIView {
        return _view
    }
}

I took some inspiration from this StackOverflow answer to fix the constraints issue.

The SwiftUIView is a pretty straightforward layout and I placed it in a separate file to use Xcode preview

import SwiftUI

@available(iOS 13.0, *)
struct SwiftUIView: View {
    var body: some View {
        VStack(alignment: .center) {
            Text("Hello from SwiftUI")
                .font(.headline)
            Text("within Flutter")
                .font(.body)
        }
    }
}

@available(iOS 13.0, *)
struct SwiftUIView_Previews: PreviewProvider {
    static var previews: some View {
        SwiftUIView()
    }
}

iOS - performance

What’s really surprising - at least knowing some stereotypes about embedding native views - the performance is pretty impressive. In a much more complex case built internally we were able to max out the frame rate of the native view, and with a simple case of a confetti animation we’re getting also super smooth effect.

Android

The world of Android is a bit more complicated than the iOS. There are differences between various vendors and Android versions. Sometimes you may think that your platform view implementation works just fine on your test device but then there may be some odd device with more problems than you could ever imagine.

To spice things up a little bit, there was a major change introduced in Flutter 3.0. It changed the logic of which mode was used depending on Android version and device capabilities.

It seems that this change has introduced several serious bugs in how the Android platform view was displayed (e.g. wrong position, ghosting of the Flutter view, crashes, or scrolling jittering performance).

Unfortunately, it wasn’t widely announced so many people haven’t realized that there are some issues until they actually run their app on the latest version of Flutter. I was in the same situation where we had to choose whether we want to migrate to Flutter 3.0 or stay at the older version. Happily, three have been some fixes since then (e.g. for webview), so if you were stuck at Flutter 2 due to platform views issues, give the newest version a try and verify if they are still present.

Types of embedding

In this section I may use some abbreviations to make reading easier. The Flutter team came up with following terms for platform view modes:

• Virtual Display (VD)
• Hybrid Composition (HC)
• Texture Layer Hybrid Composition (TLHC)

This section may require some updates soon™️, as there is ongoing refactoring of the selection logic for platform views on Android. This is valid for master, 3.5.0-10.0.pre.36. There are some pending issues with hybrid composition on Android that you may want to be aware.

Virtual Display

This is the simplest mode of them all. It poses several limitations around accessibility (e.g. you wouldn’t use it as webview). Starting from Flutter 3.x it’s going to be a fallback mode for TLHC if the device does not support that – from what I understand Android 12+ does not support VD.

To use that you can simply instantiate the AndroidView widget.

@override
Widget getPlatformView() {
  return const AndroidView(
    viewType: '@views/native-view',
    layoutDirection: TextDirection.ltr,
    creationParams: <String, dynamic>{},
    creationParamsCodec: StandardMessageCodec(),
  );
}

When you try to inspect the views of the Flutter app with Android Studio Layout Inspector you won’t see anything (although this may be Inspector’s issue as well). The Android view is invisible to the debugger.

Virtual Display is used also after invoking initAndroidView() when using PlatformViewsService within PlatformViewLink. The AndroidView widget is a shortcut with less customization compared to AndroidViewSurface.

Hybrid Composition

To use this mode you have to employ PlatformViewLink widget. Instead of returning AndroidView you can return AndroidViewSurface in its surfaceFactory. Then when creating the view you should pass viewType and other parameters to PlatformViewsService.initExpensiveAndroidView().

Why is this expensive? Let’s have a look at the docs:

When this factory is used, the Android view and Flutter widgets are composed at the Android view hierarchy level.

Using this method has a performance cost on devices running Android 9 or earlier, or on underpowered devices. In most situations, you should use [initAndroidView] or [initSurfaceAndroidView] instead.

The Dart code for this piece is not as brief:

@override
Widget getPlatformView() {
  return PlatformViewLink(
    viewType: '@views/native-view',
    surfaceFactory: (context, controller) {
      return AndroidViewSurface(
        controller: controller as AndroidViewController,
        gestureRecognizers: const <Factory<OneSequenceGestureRecognizer>>{},
        hitTestBehavior: PlatformViewHitTestBehavior.opaque,
      );
    },
    onCreatePlatformView: (params) {
      return PlatformViewsService.initExpensiveAndroidView(
        id: params.id,
        viewType: '@views/native-view',
        layoutDirection: TextDirection.ltr,
        creationParams: <String, dynamic>{},
        creationParamsCodec: const StandardMessageCodec(),
        onFocus: () {
          params.onFocusChanged(true);
        },
      )
        ..addOnPlatformViewCreatedListener(params.onPlatformViewCreated)
        ..create();
    },
  );
}

Let’s revisit the usage of PlatformViewLink. Depending on the callback selected in the onCreatePlatformView a different mode will be used:

• initSurfaceAndroidView will fallback to initAndroidView, it (maybe) will get deprecated in favor of initAndroidView entirely,
• initAndroidView will use TextureView and TLHC, but may fallback to VD on some devices (e.g. when SDK <23), cannot handle SurfaceView
• initExpensiveAndroidView will use Hybrid Composition

When you try to inspect the views of the Flutter app with Android Studio Layout Inspector you can see the overall structure of the Flutter app from the point of view of Android. The native view is accessible to the debugger.

Texture Layer Hybrid Composition

This is a new mode introduced in Flutter 3.0, and has been getting fixes for last couple of months. As of writing this article it’s still not clear what will be the final logic when selecting this mode (the docs are not clear), but in general it aims to solve a lot of the performance problems with simple AndroidView widgets.

When this PR lands, it will fallback to Hybrid Composition instead of Virtual Display when using initSurfaceAndroidView, as this seems as more predictable approach for the developers. It should fallback to Virtual Display when initAndroidView is used.

Some interesting sources that I used:

• Issue describing logic improvements
• webview_flutter and google_maps,
• PR with new selection logic
• Hybrid Composition breaks the accessibility of the native view

Android - Kotlin side

The Kotlin side of the implementation is similar to the iOS. In the plugin initialization code the view needs to be registered, this time in the platformViewRegistry:

override fun onAttachedToEngine(
   @NonNull flutterPluginBinding: FlutterPlugin.FlutterPluginBinding
) {
   channel = MethodChannel(flutterPluginBinding.binaryMessenger, "camera_view_android")
   channel.setMethodCallHandler(this)
   context = flutterPluginBinding.applicationContext

   flutterPluginBinding
       .platformViewRegistry
       .registerViewFactory("@views/native-view", NativeViewFactory())
}

The PlatformViewFactory code is relatively straightforward as well, as it only returns NativeView:

class NativeViewFactory(val cameraController: CameraController) :
   PlatformViewFactory(StandardMessageCodec.INSTANCE) {
   override fun create(context: Context, viewId: Int, args: Any?): PlatformView {
       val creationParams = args as Map<String?, Any?>?
       return NativeView(context, viewId, creationParams, cameraController)
   }
}

internal class NativeCameraView(context: Context, id: Int, creationParams: Map<String?, Any?>?) : PlatformView {
   private val textView: TextView

   override fun getView(): View {
       return textView
   }

   init {
       textView = TextView(context)
       textView.textSize = 72f
       textView.text = "Hello from Android"
   }
}

macOS

Despite the fact that platform views are not supported on desktop yet, there’s already some basic functionality available on master channel of Flutter. In practice the implementation from iOS can be reused in the macOS plugin code as well. The main difference is that FlutterMacOS framework needs to be used instead of Flutter (but it should be unified in the future anyway).

Few things don’t work as of writing this article:

• gestures are not handled entirely on the native side, the method channels are not implemented
• there’s an annoying bug with threading with a pending fix, but it prevents users from modifying the window size, while the platform view is shown
• the platform view is shown above the widget tree, so you cannot show any custom UI, plus the navigation animation is broken as well

As you can see, there’s no real support for the desktop platform views right now. However, if you ever thought about showing any native view in Flutter macOS application, this is the time to start experimenting with that. The cool thing though, is that I was able to show almost exactly the same view as on iOS with very little changes to syntax or imported libraries.

Types of rendering

Let’s recap all the types of view rendering/composition available in Flutter as of version 3.0/3.3. Currently only Android, iOS, and Web are officially supported, although the last one has relatively limited feature set. Desktop platforms (Windows, Linux, and macOS) are still work-in-progress. Recently, there has been some progress e.g. on macOS it’s already possible to display PlatformView using Flutter master (as of August 2022).

Camera example

One of the goals while writing this article was to show a camera preview on at least 3 platforms. I’m happy to share that it was possible to do. I won’t get too much into the details here, but thanks to the similarities between iOS and macOS platform view implementation, as well as by leveraging SwiftUI I was able to mostly copy-and-paste the plugin code from iOS to macOS to get basic camera working.

Check out the example camera app

The iOS and macOS implementations use SwiftUI camera views from this article by Yono Mittlefehldt. The license note is included in every file copied from the original implementation.

The Android implementation uses CameraView library, which worked perfectly fine for this sample.

I’m quite happy with the final result, although it’s definitely not ready to use outside of demo environment. The journey I took shows that it’s going to be relatively easy to embed native views across all the platforms supported by Flutter. It’s not there yet, but I’m really hopeful and looking forward to see plugins like webview, video player or PDF readers on desktop platforms.