Achieve mobile release independence in Flutter with flutter_eval

While Flutter mobile developers, in the eyes of many, enjoy superior tooling and a more predictable programming environment, there is one feature from web development that we often wish we had. This article will explore this coveted feature, focusing on how it can improve our Flutter development experience.

Our mobile-exclusive DX parts include stateful hot-reload, a tool that mobile Flutter developers frequently use but is missed in non-Flutter projects. The absence of this feature can lead to significant time loss daily, as developers struggle to regain the state of the app section they are currently working on. Moreover, the stability and robustness of our platforms are commendable, freeing us from concerns about ad blockers interfering with network requests or add-ons disrupting our application layout, which can lead to unexpected bugs. However, there is one aspect of the web developer's experience that I, and perhaps many of you, cannot help but envy – the capability to release new software versions on demand. This article will delve into this feature, exploring its potential to revolutionize our Flutter development process.

In contrast, the mobile development journey is a more complex and unpredictable one. When a broken feature is reported, it is promptly fixed, but the process becomes uncertain when the release is sent for review. The procedure can be a gamble, with approval times ranging from under an hour to several days, depending on the reviewer's findings. If a compliance issue is discovered, negotiations for a later fix can become political, with the primary concern being the user's smooth experience with the app.

Even after approval, the rollout process is still uncertain. Not all users may receive the fix, as updates depend on device usage and charging patterns. Some users may never update to the newest version, leaving unresolved issues in the error tracking system. While there are mitigation options like feature flags and forced updates, one aspect remains elusive: store reviews. Automating and enhancing the reliability of this process would be a welcome solution in the mobile development journey.

The most intriguing aspect of flutter_eval is its potential to allow developers to switch their app's implementation, including logic and UI, remotely, bypassing the entire review process. This tool, written in Dart, can be used in any environment where Dart is supported, including Android, iOS, desktop, and even the web, which adds an interesting twist to the context of this article.

When it comes to code safety, dart_eval prioritizes it with a robust and built-in security layer to protect your projects. By default, remote code can only interact with the compiled Dart code and its memory. However, the mechanism enables you to define which resources are accessible by the code running in the virtual machine. We will get into the details later in the discussion.

1. dart_eval: This component plays dual roles in the process. It acts as the virtual machine that runs our remote code, and it also serves as a command-line interface on the development machine for compiling the code into an .evc file.

2. eval_annotation: This annotation is used to mark the parts of the code that we intend to switch at runtime.

3. flutter_eval: This component provides specific features for the Flutter framework. It includes a widget that downloads the remote code package and configures it. Flutter_eval also includes helper widgets that switch the implementation at the appropriate time.

It's important to note that dart_eval does not replace your existing app implementation. Instead, it works with your current code to provide remote updates. However, these updates should be applied to specific parts of the app. We will discuss this in more detail later.

Once loaded, HotSwap widgets will ensure that the remote code replaces sections of the Dart code shipped with the application based on the hot-swap id. In the basic setup, we’ll use raw strings, but it’s recommended to use enums to avoid typos. For now, take note of the id selected here: #myHomePage. The childBuilder function makes sure there’s always something meaningful to render for the app. If the .evc code cannot be accessed for any reason, childBuilder will simply render the code provided with the original app’s release.

If you have any additional arguments for the remote widget, use the args array. It must always be populated with at least the current widget context, as it’s necessary for Flutter to correctly render the widgets, but will accept any number of arguments. As you can see, the BuildContext uses flutter_eval’s $BuildContext helper class, which wraps the context generated via shipped code to work with the runtime dart_eval VM. More details can be found in the documentation, but we’ll skip this complexity for brevity.

Next up, the cool part, preparing the hot swap package. Runtime code replacements are shipped independently from the app. Therefore, in the recommended setup, we store the remote code in a separate package. 

Start by creating the package, just like you would create any other package project. Then, get the flutter_eval.json file from the flutter_eval GitHub release matching the version number of your current flutter_eval version. The flutter_eval.json file contains bindings for many widgets that are shipped with the Flutter framework, so you can use them in the remotely delivered code. 

Then, create a .dart_eval/bindings directory in your new project and store the file there. It’ll be used in the compilation step.

While still in the new package project, make sure to add the eval_annotation dependency. It’ll give you access to the @RuntimeOverride annotation, allowing you to later replace the tag during runtime. Each RuntimeOverride annotation should decorate a function that returns a Widget. The args list you provide for the matching HotSwap widget will be converted to arguments of the function declared here. 

Once your implementation is ready, compile the code with the dart_eval CLI. If you haven’t already, activate it first, then call dart_eval compile with the desired output filename.

Now, the grand finale – publishing your code. My only recommendation is to pick a reliable hosting for your .evc files. Once live, the new .evc contents will replace the current implementation in the target apps. It’s also a good idea to include the application version number with the .evc file request. At some point, as you might have multiple app versions using .evc files, it’s advisable to be able to swap contents per app version to avoid interlocks.

This potential security risk was identified early on in the development process, and as a result, by default, your remote code does not have access to any resources on the disk or the network. However, if your use case requires granting access to potentially risky resources, you can still specify which directories on the disk and which domains on the web can be accessed, providing a more granular level of control over the security of your application.

An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (such as dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine or an interpreter that either that provides indirect access to Android APIs (such as JavaScript in a webview or browser)

~ Play Console Help

[...] interpreted code may be downloaded to an Application but only if the code:

a) does not change the primary purpose of the Application by providing

features or functionality that are inconsistent with the intended and

advertised purpose of the Application as submitted to the App Store,

b) does not create a store or storefront for other code or applications, and

c) does not bypass signing, sandbox, or other security features of the OS.

~ Apple Developer Program License Agreement

Both app stores generally allow the downloading and running of interpreted code, provided it does not directly access system APIs or bypass OS security measures. Additionally, the app cannot change its purpose through these updates, and it cannot offer an internal app gallery that is updated without allowing store reviewers to examine it before it is made available to users.