This article will continue the story about the multi-platform implementation of the in-app review. Here’s the beginning of it. After I created an implementation in KMP it was interesting for me — if it is easy to create a Flutter plugin that uses this implementation? Spoiler — really easy.

I think this article will be useful for the companies that have both Flutter and KMP teams since it allows to use the same code base (write KMP library and then wrap it with the Flutter plugin) instead of writing the plugin in pure native.

I won’t describe how to create a Flutter plugin from scratch since there’s a good documentation about it, so let’s dive into the most interesting part — integration of the KMP library.

Let’s start with the Android part. KMP module is compiled into AAR artefact for the Android. You can add it directly into the project (into libs folder), but since my artefact was already published into GitHub maven I decided to add it as the remote dependency.

For this purpose I added a repository into the android/build.gradle file of the plugin. Here’s the way how it looks like

So, as you can see, it’s just the default declaration of the repository. Of course, you can use jcenter and so on but GitHub maven was enough for me in this case. And then we add the dependency

After the sync we are ready to use the library classes inside the android part of the plugin, so let’s do it.

Now let’s discuss some interesting moments from this part of the plugin.

1. As you can remember — both GooglePlayInAppReviewManager and AppGalleryInAppReviewManager require an instance of ComponentActivity to work, so I had to implement the ActivityAware interface to receive and store the instance of the activity. Note — by default the Flutter application inherits the MainActivity from FlutterActivity. But this variant is not suitable for my case since FlutterActivity doesn’t extend the ComponentActivity, so I had to change it to the FlutterFragmentActivity.
2. To make the AppGallery’s implementation work well I had to call it inside the ON_CREATE state of the lifecycle. For this purpose I added a lifecycle observer (lines 57–60).
3. To pass the result back to the Flutter part I invoke the result.success with the ReviewCode enum’s name after the event from the flow is received.

Everything other is pretty clear I think if you already have an experience in creating the Flutter plugin.

Let’s move on to the iOS part. KMP allows you to build an XCFramework. For this purpose you need to add the following lines into the build.gradle file of the KMP module:

When you declare XCFrameworks, Kotlin Gradle plugin will register three Gradle tasks:

assembleXCFramework
assembleDebugXCFramework
assembleReleaseXCFramework

Here you can find more info about it.

Unlike the Android, for iOS I decided not to publish the artefact but to add it directly to the iOS part, so I just added the xcframework into the iOS folder. But it’s not the end — to resolve the framework classes inside the iOS part of the plugin I also had to mention the framework inside the podspec file:

s.vendored_frameworks = 'inAppReviewKMP.xcframework'

After the setup is finished we are ready to implement the iOS part:

There’s not so much interesting inside, but I just want to highlight how to implement the flow collecting default approach — class InAppReviewCollector is responsible for it. As an alternative, you can use Swift Concurrency or this library.

Finally, we can see how it looks inside the Flutter part

Here’s the full project implementation

So, let’s summarise all the article — to use the KMP library inside the Flutter plugin, we need to build the AAR artefact for the Android part (add it from the remote repo or directly inside the project) and build a XCFramework/use pod for the iOS part (don’t forget to add it inside the podspec).

Thank you for reading! Feel free to ask questions and leave the feedback in comments or Linkedin.

This article is previously published on proandroiddev.com