Download Native Code in your Mobile Applications with Zipline

In the dynamic world of mobile application development, rapid adaptability to new requirements and scenarios is crucial. In this article, we will explore how Zipline, an innovative tool, facilitates flexible and efficient deployment of native code in mobile applications.

Before delving into the topic, I want to remind you that this is not the first time we’ve addressed Zipline. I’m sharing my first article about this tool, where we analyzed it from a more practical approach:

Preparing for the Future: Strategies for Multiple Scenarios

In modern application development, it’s crucial to be prepared for various future scenarios. To achieve this, we implement several innovative strategies:

• Feature Flags: Allow activating or deactivating specific functionalities without the need to update the application, offering real-time flexibility.
• SDUI (Server-Driven User Interface): Provides the ability to modify the user interface remotely, adapting it to new needs without user intervention.
• Flexible and Resilient APIs: Designed to adapt to future changes and handle various situations, ensuring the longevity and versatility of the application.
• WebViews: Facilitate the integration of dynamic web content within the application, allowing rapid updates without the need to deploy a new version of our applications.

Challenges in Modern Backend Development

Traditional backends face several obstacles that hinder innovation and adaptability in software development:

• Backward Compatibility: Maintaining and testing multiple versions of clients consumes considerable time and resources.
• API Evolution: Modifying existing APIs often involves significant effort and can generate compatibility issues.
• SDUI Implementation: The integration and testing of server-controlled user interfaces represents a significant technical challenge.

These challenges highlight the need for more agile and efficient solutions in modern backend development, capable of rapidly adapting to changing market demands and emerging technologies.

The Web: Pioneer of Continuous Updates Since the 90s

The web solved the problem of updates in the 1990s, establishing a paradigm that we can apply to modern applications:

• Access to the latest version: Every user always has the most recent version of the software.
• Multifaceted benefits: This approach offers significant advantages for:
• Customers: Enjoy immediate improvements and fixes.
• Engineers: Can continuously iterate and improve the product.
• Development: Accelerates the innovation and release cycle.

This model of continuous updates is essential for maintaining modern applications that are agile and adaptable to changing user needs.

This approach has given a great boost to transferring these web facilities to mobile applications through WebViews, although often sacrificing the experience and performance of the applications.

QuickJS: An Efficient and Versatile JavaScript Engine

QuickJS is an embeddable JavaScript engine that offers a compact and efficient solution for running JavaScript in native applications:

• Developed in C with only 65,560 lines of code, demonstrating its efficiency and lightweight nature.
• Adds a native library of just 1.2 MiB to the APK, minimizing the impact on application size.
• Provides a JNI (Java Native Interface) binding for seamless integration:
• Facilitates communication between Java/Kotlin and native C/C++ code.
• Allows leveraging C and C++ libraries directly from the JVM or Android applications.

QuickJS in JVM/Android

The integration of QuickJS in Android using JNI consists of the following steps:

• Compilation and preparation: QuickJS is compiled as a static library for Android architectures and a JNI wrapper is created in C/C++.
• Implementation in Java/Kotlin: Native methods corresponding to the JNI wrapper functions are declared and the native library is loaded when the application starts.
• Using QuickJS: Once loaded, JavaScript scripts are executed and results are handled from Java/Kotlin.

This integration allows for efficient execution of JavaScript in Android applications, leveraging the speed of QuickJS.

In our example, we will use the QuickJS implementation provided by Zipline, which fulfills the aforementioned points. Let’s look at an example in a test:

import app.cash.zipline.EngineApi
import app.cash.zipline.QuickJs
import kotlin.test.Test
import kotlin.test.assertEquals
@OptIn(EngineApi::class)
class AndroidQuickJsTest {
@Test
    fun runJavaScript() {
        val quickJs = QuickJs.create()
        assertEquals(
            expected = "Hello World",
            actual = quickJs.evaluate("['Hello', 'World'].join(' ')")
        )
        quickJs.close()
    }
}

If we run our tests, we will encounter the following error:

which indicates that the native QuickJS library was not loaded.

Next, we’ll see that Zipline already has its own native QuickJS library.

QuickJS on iOS

The integration of QuickJS in iOS follows a process similar to Android, but with specific considerations due to iOS architecture and its interoperability with native C libraries. The key steps include:

Integration of QuickJS in iOS:

• Compile QuickJS as a static library for iOS architectures
• Create an Objective-C wrapper that serves as a bridge between Swift/Objective-C and QuickJS
• Use a bridging header to expose wrapper functions to Swift
• Implement a Swift class that encapsulates QuickJS functionality

This process allows efficient use of QuickJS in iOS applications, leveraging interoperability between Swift, Objective-C, and C.

Example of Objective-C wrapper (QuickJSWrapper.h):

#import <Foundation/Foundation.h>
@interface QuickJSWrapper : NSObject
- (instancetype)init;
- (NSString *)evaluateScript:(NSString *)script;
- (void)close;
@end

Implementation of the wrapper in Objective-C (QuickJSWrapper.m):

#import "QuickJSWrapper.h"
#include "quickjs.h"
@implementation QuickJSWrapper {
    JSRuntime *rt;
    JSContext *ctx;
}
- (instancetype)init {
    self = [super init];
    if (self) {
        rt = JS_NewRuntime();
        ctx = JS_NewContext(rt);
    }
    return self;
}
- (NSString *)evaluateScript:(NSString *)script {
    JSValue val = JS_Eval(ctx, [script UTF8String], [script lengthOfBytesUsingEncoding:NSUTF8StringEncoding], "<input>", 0);
    const char *str = JS_ToCString(ctx, val);
    NSString *result = [NSString stringWithUTF8String:str];
    JS_FreeCString(ctx, str);
    JS_FreeValue(ctx, val);
    return result;
}
- (void)close {
    JS_FreeContext(ctx);
    JS_FreeRuntime(rt);
}
@end

Implementation in Swift:

import Foundation
class QuickJSEngine {
    private let wrapper: QuickJSWrapper
init() {
        wrapper = QuickJSWrapper()
    }
func evaluate(_ script: String) -> String {
        return wrapper.evaluateScript(script)
    }
deinit {
        wrapper.close()
    }
}
// use
let engine = QuickJSEngine()
let result = engine.evaluate("['Hello', 'World'].join(' ')")
print(result) // print: Hello World

This integration allows efficient use of QuickJS in iOS applications, leveraging the interoperability between Swift, Objective-C, and C. This provides a smooth development experience and maintains optimal performance.

Zipline already includes its own implementation of this wrapper, allowing us to use it directly in our multiplatform code.

import app.cash.zipline.EngineApi
import app.cash.zipline.QuickJs
import kotlin.test.Test
import kotlin.test.assertEquals
@OptIn(EngineApi::class)
class IOSQuickJsTest {
@Test
    fun runJavaScript() {
        val quickJs = QuickJs.create()
        assertEquals(
            expected = "Hello World",
            actual = quickJs.evaluate("['Hello', 'World'].join(' ')")
        )
        quickJs.close()
    }
}

If we run our tests, as we did for Android, we will obtain the following result:

Next, we’ll explore how Zipline significantly simplifies the use of QuickJS on both Android and iOS. This abstraction offers a unified and user-friendly interface, allowing developers to leverage QuickJS capabilities more efficiently and with less repetitive code on both platforms.

The simplification provided by app.cash.zipline.QuickJs is particularly valuable in the context of cross-platform development. It allows for maintaining a more consistent codebase and reduces the inherent complexity of integrating JavaScript engines into native applications.

Kotlin/JS: Versatility and Power in Web and Mobile Development

Kotlin/JS is a powerful tool that allows running Kotlin code in JavaScript environments, offering a unique and versatile development experience:

Flexible execution:

• Compatible with modern web browsers
• Works with advanced JavaScript engines like QuickJS

Kotlin features:

• Familiar syntax: nullability, data classes
• Full access to Kotlin standard library
• Robust development tools
• Compatibility with popular libraries: Compose, Coroutines, Serialization, Okio

JavaScript integration:

• Support for dynamic typing with “dynamic”
• Access to standard JS functions: console.log(), JSON.stringify()
• Integration with build tools like webpack
• Use of NPM or Kotlin/Multiplatform libraries

While implementing Kotlin/JS in native applications presents technical challenges, it offers significant potential for cross-platform development and code reuse.

@OptIn(ExperimentalJsExport::class)
@JsExport
fun sayHello(): String {
    return listOf("Hello", "World")
        .joinToString(" ")
}

Running Kotlin/JS Code with QuickJS

import app.cash.zipline.EngineApi
import app.cash.zipline.QuickJs
import kotlin.test.Test
import kotlin.test.assertEquals
@Test 
fun sayHello(){
  val quickJs = QuickJs.create()
  quickJs.loadJsModule("./kotlin-kotlin-stdlib-js-ir.js")
  quickJs.loadJsModule("•/hello-kotlin-js.js")
assertEquals(
   "Hello World", 
   quickJs.evaluate(
    "require('•/hello-kotlin-js.js').com.example.sayHello()"
   )
  )
quickJs.close()
}

Zipline emerges as an innovative solution to simplify the integration of Kotlin/JS in mobile applications. Recognizing the inherent challenges of executing Kotlin/JS in a native environment, Zipline offers a more accessible and efficient alternative. This tool aims to pave the way for developers, facilitating the incorporation of Kotlin/JS’s powerful features into the mobile application ecosystem.

Zipline offers an intuitive and familiar interface for developers, allowing them to leverage the advantages of Kotlin/JS without facing the underlying complexity of its implementation. This approach significantly simplifies the process of integrating and executing Kotlin/JS code in native applications.

Next, we’ll examine how Zipline achieves this goal, providing an API that streamlines the incorporation of Kotlin/JS into mobile application development.

Zipline: Facilitating Communication Between Kotlin and JavaScript

Zipline uses a Kotlin compiler plugin to optimize the interaction between application components. This plugin performs three key functions:

• Adapter creation: Develops specialized interfaces that act as a bridge between Kotlin and JavaScript, allowing for smooth communication.
• Call modification: Adjusts the bind() and take() functions to use the generated adapters, ensuring seamless integration.
• Sending: Implements the necessary interfaces and encodes calls in JSON for efficient transmission.
• Receiving: Decodes incoming JSON calls and directs them to the corresponding native code.

This architecture facilitates a robust integration between Kotlin and JavaScript, maintaining type safety and effective bidirectional communication. As a result, developers can leverage the best of both worlds, merging the robustness of Kotlin with the versatility of JavaScript in their applications.

Kotlinx Serialization

Zipline uses JSON as an intermediate format for bridged calls, utilizing kotlinx.serialization to generate this JSON efficiently. The essential function in this process is encodeToStringFast, which streamlines data serialization between Kotlin and JavaScript.

package app.cash.zipline.internal
import kotlinx.serialization.ExperimentalSerializationApi
import kotlinx.serialization.KSerializer
import kotlinx.serialization.json.Json
import kotlinx.serialization.json.decodeFromDynamic
import kotlinx.serialization.json.encodeToDynamic
@OptIn(ExperimentalSerializationApi::class) // Zipline must track changes to decodeFromDynamic.
internal actual fun <T> Json.decodeFromStringFast(deserializer: KSerializer<T>, string: String): T =
  decodeFromDynamic(deserializer, JSON.parse(string))
@OptIn(ExperimentalSerializationApi::class) // Zipline must track changes to encodeToDynamic.
internal actual fun <T> Json.encodeToStringFast(serializer: KSerializer<T>, value: T): String =
  JSON.stringify(encodeToDynamic(serializer, value))

Suspend Functions and Callbacks

Zipline’s suspension bridges use pass-by-reference to manage suspended functions and callbacks. This approach presents interesting challenges, such as encoding SuspendCallback in JSON and the need to build additional bridges to facilitate communication between Kotlin and JavaScript. This technique achieves a smoother integration between Kotlin’s suspended functions and the JavaScript runtime environment, preserving efficiency and type safety in calls between both languages.

If we have the following definition

Zipline transforms the previous definition into

How is a SuspendCallback encoded in JSON? Zipline builds another bridge to achieve this.

Kotlin Flows and Pass by Reference

Zipline handles Kotlin Flows and their operations efficiently through strategic use of pass by reference:

• For return flows, it implements pass by reference of Flow.
• In flow collection, it uses inverse pass by reference of FlowCollector.
• When emitting to a collector, it employs the suspended emit() function, implemented as a pass by reference of SuspendCallback.

Let’s take a look at the code generated by Zipline. First, we have the manifest, which contains references to all the files in the package. In this case, we see a reference to a file called kotlinx-coroutines-core.js

This file, found within the files generated by Zipline for packaging, is simply the JavaScript version of Kotlin Coroutines.

If we analyze the code generated for our example

class BasicSayHello : SayHelloService {
    override fun sayHello(): Flow<String> {
        return flowOf("Hello Compose")
    }
}

we will see the following code generated by Kotlin/JS, ready to be interpreted by Zipline

  var flowOf = kotlin_org_jetbrains_kotlinx_kotlinx_coroutines_core.$_$.h;
  var protoOf = kotlin_kotlin.$_$.i9;
  var close = kotlin_app_cash_zipline_zipline.$_$.e;
  var SayHelloService = kotlin_kmp_zipline_example_core.$_$.b;
  var initMetadataForClass = kotlin_kotlin.$_$.j8;
  var VOID = kotlin_kotlin.$_$.f;
  var listOf = kotlin_kotlin.$_$.d6;
  var Adapter = kotlin_kmp_zipline_example_core.$_$.a;
  var Companion_getInstance = kotlin_app_cash_zipline_zipline.$_$.g;
  var KProperty0 = kotlin_kotlin.$_$.w9;
  var getPropertyCallableRef = kotlin_kotlin.$_$.g8;
  var lazy = kotlin_kotlin.$_$.yc;
  //endregion
  //region block: pre-declaration
  initMetadataForClass(BasicSayHello, 'BasicSayHello', BasicSayHello, VOID, [SayHelloService]);
  //endregion
  function BasicSayHello() {
  }
  protoOf(BasicSayHello).sayHello_xahftl_k$ = function () {
    return flowOf('Hello Compose');
  };

Zipline: Building Robust Bridges between Kotlin and JavaScript

The Zipline bridge is a powerful tool that offers several key advantages in mobile application development:

• Facilitates Kotlin/JS integration, enabling near-native calls
• Provides a unified mechanism for data and services in Kotlin/JS
• Incorporates concurrency capabilities
• Completely abstracts the underlying JavaScript
• Simplifies the complexity of JSON handling

These features allow developers to leverage the power of Kotlin/JS more efficiently and transparently in their mobile applications, enhancing flexibility and cross-platform development capabilities.

Important considerations when using Zipline

• Careful resource management: Each object obtained through take() must be explicitly closed with close() to avoid memory leaks, especially in long-running applications.
• Exception handling: JavaScript exceptions are wrapped in a ZiplineException when propagated to Kotlin. Implementing a robust error handling strategy is crucial.
• Divergent code versions: Zipline allows dynamic updates, which can result in different instances of the application running different versions of the code. This requires careful version management and thorough testing to avoid inconsistent behaviors.
• Optimization of transferred data: Communication between Kotlin and JavaScript involves serialization and deserialization. Very large parameters or responses can significantly affect performance and memory consumption. It is essential to optimize the amount of data transferred.

Packaging

The Zipline packaging process generates several key files for efficient code distribution and execution:

• manifest.zipline: Contains essential metadata about the package, including versions and dependencies.
• .js files: Contain the JavaScript code compiled from the original Kotlin code.
• .js.map files: Are mapping files that facilitate debugging by relating the compiled JavaScript code to the original Kotlin code.
• .klib files: Represent the compiled Kotlin libraries, containing the bytecode and metadata necessary for execution.

This file structure allows Zipline to load and execute the code efficiently, maintaining the capability for dynamic updates and facilitating code maintenance in production.

Manifest

The manifest file generated by Zipline is essential for the package’s operation, containing crucial information:

• Package version: Identifies the specific version of the packaged code.
• Dependencies: Lists all libraries and modules necessary for code execution.
• File names: Specifies the .js, .js.map, and .klib files included in the package.
• Integrity hashes: Provides hashes to verify the integrity of the files.
• Additional metadata: May include information about the target platform, specific configurations, and other details relevant to code loading and execution.

This manifest serves as an essential guide for the Zipline loader, ensuring efficient and secure loading of the packaged code in the execution environment.

The Zipline packaging process is a crucial stage that prepares the code for efficient distribution and execution. This process involves several important steps:

1. Kotlin code compilation: The Kotlin source code is compiled into JavaScript and Kotlin bytecode.
2. JS file generation: .js files containing the compiled JavaScript code are created.
3. Mapping file creation: .js.map files are generated to facilitate debugging, linking the JavaScript code with the original Kotlin code.
4. Kotlin library packaging: .klib files containing the compiled Kotlin libraries are generated.
5. Manifest generation: A manifest.zipline file is created, which includes metadata about the package, versions, and dependencies.
6. Hash calculation: Hashes are generated to verify the integrity of the packaged files.

This process ensures that all necessary code is properly packaged and prepared for loading and execution by the Zipline Loader in the target environment.

Zipline Loader

The Zipline Loader is a crucial component that manages the loading and execution of packaged code. Its main features are:

• Initialization: Starts by using a manifest URL as the entry point.
• Result: Provides a running Zipline instance that integrates QuickJS and the necessary bridges.

Efficient loading process:

• First, it retrieves the package manifest.
• Then, it downloads all bytecode in parallel to optimize loading time.
• As it receives the bytecode, it loads it into QuickJS, allowing for progressive initialization.

Intelligent caching system:

• Avoids unnecessary downloads of rarely changing Kotlin standard libraries.
• Selectively updates only modified modules.
• Applies this caching strategy to all project modules, optimizing resource usage and loading time.

This architecture allows the Zipline Loader to offer a fast and efficient loading experience, adapting to the needs of dynamic code updates in mobile applications.

Zipline optimizes application performance and availability through embedded code, a strategy that involves including the most recent bytecode and manifest directly in the APK. This technique significantly reduces the need for frequent downloads and ensures that the application runs smoothly, even without an internet connection.

Always Up-to-Date Code

Zipline ensures that your application always runs the latest version of the code, adapting nimbly to various scenarios. This feature guarantees that your software is constantly optimized and up-to-date with the latest improvements.

fun startZipline(
    scope: CoroutineScope,
    dispatcher: CoroutineDispatcher,
    loader: ZiplineLoader,
    manifestUrl: String,
    data: MutableStateFlow<String>
) {
scope.launch(dispatcher + SupervisorJob()) {
        // load the manifest
        val loadResultFlow: Flow<LoadResult> = loader.load(
            applicationName = ApplicationName,
            freshnessChecker = DefaultFreshnessCheckerNotFresh,
            manifestUrlFlow = repeatFlow(manifestUrl, 500L),
        )
     // implementation code ...
    }
}

Environment Configurations:

Development Environment

• Automatic updates: Code reloads instantly when changes are saved, facilitating an agile and efficient development cycle.

Production Environment

• Offline startup: The application loads cached or embedded code, ensuring functionality even without internet access.
• Online updates: When a connection is established, Zipline automatically searches for and applies the latest code updates.

This “always up-to-date code” strategy combines flexibility in development with robustness in production, keeping your application current without compromising its availability.

Additionally, Zipline, through the loader, allows configuring a cache to avoid constant queries. Let’s see how to set it up:

Android

In Android, we’ll configure the loader’s cache as follows:

startZipline(
    scope = scope,
    dispatcher = ziplineDispatcher,
    loader = ZiplineLoader(
        dispatcher = ziplineDispatcher,
        manifestVerifier = NO_SIGNATURE_CHECKS,
        httpClient = okHttpClient,
    ).withCache(
       cache =  ZiplineCache(
            context = TODO("android context"),
            fileSystem = FileSystem.SYSTEM,
            directory = "android-cache".toPath(),
            maxSizeInBytes = (10 * 10 * 1024)
        ),
        cacheDispatcher = TODO()
    ),
    manifestUrl = manifestUrl,
    data = data,
)

By creating a ZiplineLoader, we’ll have a constructor where we’ll apply the withCache function and configure our ZiplineCache object. In this object, we can set fileSystem, directory, and maxSizeInBytes. If we examine the implementation, we’ll see that Zipline’s cache uses Okio and SQLDelight as underlying persistence mechanisms.

iOS

The implementation in iOS is similar to Android, with the difference that it doesn’t require using the context as a parameter.

startZipline(
    scope = scope,
    dispatcher = ziplineDispatcher,
    loader = ZiplineLoader(
        dispatcher = ziplineDispatcher,
        manifestVerifier = NO_SIGNATURE_CHECKS,
        urlSession = urlSession,
    ).withCache(
        cache = ZiplineCache(
            fileSystem = FileSystem.SYSTEM,
            directory = "ios-cache".toPath(),
            maxSizeInBytes = 10 * 1024
        )
    ),
    manifestUrl = manifestUrl,
    data = data,
)

The complete implementation of the Zipline cache for both platforms can be seen in the following Pull Request

Zipline on iOS

Zipline offers a robust cross-platform solution that integrates seamlessly with iOS, leveraging the capabilities of Kotlin Multiplatform (KMP) and QuickJS. Below are the key features of Zipline in the iOS environment:

Cross-Platform Integration

• Zipline is implemented as a standard Kotlin Multiplatform library, enabling unified development across platforms.
• QuickJS, the JavaScript engine used by Zipline, runs natively on iOS. This eliminates the need for Java Native Interface (JNI) and optimizes performance.

Development Structure with KMP

• Development with Zipline and KMP follows an efficient pattern:
• Shared interfaces and types are defined in the commonMain module, ensuring consistency across platforms.
• Specific implementations are done in the hostMain module for shared code, or in androidMain and iosMain for platform-specific functionalities.

This structure allows developers to maximize code reuse while maintaining the flexibility to adapt to iOS particularities. The result is more efficient development and a more maintainable codebase.

 val ziplineDispatcher = Dispatchers.Main
 val urlSession = NSURLSession.sharedSession
startZipline(
      scope = scope,
      dispatcher = ziplineDispatcher,
      loader = ZiplineLoader(
          dispatcher = ziplineDispatcher,
          manifestVerifier = NO_SIGNATURE_CHECKS,
          urlSession = urlSession,
      ),
      manifestUrl = manifestUrl,
      data = data,
  )

Interesting Features

Kotlin Line Numbers

Thanks to the mapping generated by Zipline, it’s possible to identify the code lines in case an exception occurs in our JS code.

Let’s look at an example of an exception thrown from our JS code

Code Signing

Zipline provides us with a code signing mechanism, ensuring that only authorized applications can download the bytecode. For this purpose, it offers a public and private key system with two algorithms: Ed25519 and EcdsaP256. We can configure this mechanism in our server application using the Zipline plugin.

zipline {
    mainFunction.set("com.santimattius.server.main")
    signingKeys{
        create("key1"){
            privateKeyHex.set("48d701dfbcf924c71f3a1c36e40c7a881092b1cfd2f1a0d60fc8e2df8606d02d")
            algorithmId.set(SignatureAlgorithmId.Ed25519)
        }
        create("key2"){
            privateKeyHex.set("3041020100301306072a8648ce3d020106082a8648ce3d030107042730250201010420fa385f4496620d77120f5fcec0568c205cb842374bf3faf45cdbd6aede73c755")
            algorithmId.set(SignatureAlgorithmId.EcdsaP256)
        }
    }
}

If we need to generate these keys, the plugin provides us with two tasks: generateZiplineManifestKeyPairEcdsaP256 and generateZiplineManifestKeyPairEd25519. When executing these tasks, the public and private keys for our signature will be generated.

Once we have our keys, we need to configure our Zipline Loader with the public keys. To do this, we’ll use ManifestVerifier.Builder to create our ManifestVerifier and then configure our loader

private val verifier = ManifestVerifier.Builder()
        .addEd25519("key1","78b7468afab3bbea07b389c8375b63afa0b623c0ab800ac98e4afecc02810cf1".decodeHex())
        .addEd25519("key2","04844a04209407ee2027463d11ffc41b27277cf83d274ea71d94bc24c08b1784f6745e65e2180e1b70995de2447f2d89626d9d339de36607cbe382e937e16833f7".decodeHex())
        .build()
//verifier configuration
 startZipline(
      scope = scope,
      dispatcher = ziplineDispatcher,
      loader = ZiplineLoader(
          dispatcher = ziplineDispatcher,
          manifestVerifier = verifier,
          httpClient = okHttpClient,
      ),
      manifestUrl = manifestUrl,
      data = data,
  )

In the following Pull Request you can see the complete changes

Once our server is configured and compiled, we will see that our keys are configured in our Zipline manifest

This configuration provides us with a security mechanism for our code, ensuring that our applications do not expose their source code.

Rules are Rules

Although Zipline offers great flexibility to modify the behavior of already published applications, it is crucial to carefully consider its use and not implement it in all aspects of our application.

Zipline is a powerful tool for dynamically updating mobile application code. However, it is essential to maintain a balance between this flexibility and compliance with app store policies. It is advisable to limit the use of Zipline to non-essential components of the application, while maintaining major updates through the official channels of Google Play Store and Apple App Store. This practice ensures transparency with users and compliance with the standards set by Apple and Google. Significant functionality and security updates should primarily be made through conventional store updates. Zipline should be reserved for minor adjustments and optimizations that do not substantially alter the user experience or core functionality of the application.

Conclusion

Zipline emerges as an innovative and powerful tool in mobile application development, offering a flexible solution for native code deployment. Throughout this article, we have explored its key features, including its cross-platform integration, its development structure with Kotlin Multiplatform, and its security mechanisms such as code signing.

Zipline’s ability to facilitate dynamic updates and its compatibility with both Android and iOS make it an attractive option for developers seeking agility and efficiency. However, it is crucial to remember that its implementation must be careful, respecting app store policies and using it primarily for minor optimizations.

In summary, Zipline represents a significant advance in how we approach mobile application development and maintenance. It offers a balance between flexibility and security, allowing developers to quickly adapt to new requirements while maintaining the integrity and compliance of their applications. Its intelligent adoption can lead to more efficient development and a better experience for both developers and end users.

References

• https://jakewharton.com/dynamic-code-with-zipline/
• https://code.cash.app/zipline
• https://jakewharton.com/using-kotlin-js-and-native-on-android/
• https://johnsonlee.io/quickjs/quickjs.html
• https://github.com/dokar3/quickjs-kt
• https://mvnrepository.com/artifact/app.cash.quickjs