Plugin Architecture Implementation for Mobile App

Plugin Architecture Implementation for Mobile Apps

Plugin architecture—step beyond modularity. Modular apps have all modules known at compile time, assembled into single binary. Plugin architecture allows app parts to be added, replaced, or updated independently from the main app—sometimes at runtime.

Not always needed. Specific scenarios: platform app with partner extensions, super app where mini-programs are plugins, corporate MDM system where client-company adds modules.

How It Works on Android

Android enables dynamic code loading via DexClassLoader. Plugin is APK or DEX file loaded at runtime:

val pluginApkPath = File(context.filesDir, "plugin-v2.apk").absolutePath
val classLoader = DexClassLoader(
    pluginApkPath,
    context.codeCacheDir.absolutePath,
    null,
    context.classLoader
)
val pluginClass = classLoader.loadClass("com.plugin.FeatureImpl")
val plugin = pluginClass.getDeclaredConstructor().newInstance() as PluginContract
plugin.initialize(pluginContext)

PluginContract interface implemented by plugin. Main app knows only the interface, not implementation. Plugin downloaded from server, verified by digital signature (JarVerifier or custom via SHA-256), placed in filesDir, loaded.

Google Play Integrity API verifies downloaded plugin wasn't replaced. IntegrityManager.requestIntegrityToken() before plugin load confirms request integrity.

Limitation. App Store (iOS) forbids dynamic executable code loading—guideline 2.5.2. On iOS, plugin architecture means either compile-time plugins (all known at build, connected via protocols) or interpreted content (JavaScript via JavaScriptCore, Lua, WebAssembly)—not native code, doesn't violate guidelines.

iOS: Plugins via Protocols and JavaScriptCore

iOS dynamic plugin code loading impossible without jailbreak. But plugin architecture implementable via:

1. Protocol-based compile-time plugins. Each plugin is Swift Package implementing PluginProtocol. App compiles with all plugins, activates needed ones via config. Plugins isolated through modules, host API access only through protocol.

2. JavaScriptCore as runtime. Plugin is JavaScript file downloaded from server, executed via JSContext. Host registers native functions as JS objects: context["nativeAPI"] = nativeAPI as AnyObject. Execution speed acceptable for business logic, unacceptable for rendering. This is how WeChat mini-programs and some super apps work.

3. WebAssembly. iOS 14+ WKWebView runs WASM via JavaScript engine. Plugin compiles to WASM (from C++, Rust, AssemblyScript), runs in isolated environment. Native code interaction via WASM imports/exports.

Plugin Versioning and Compatibility

Hardest plugin architecture part—not code loading, but compatibility management. App v2.5 must run plugin written for v2.0 API, not crash on v2.6 plugin expecting non-existent API.

Solution—explicit contract versioning. PluginContract has minHostVersion and targetHostVersion. On plugin load, host checks compatibility before initialize(). Obsolete API versions marked @Deprecated, supported for two major versions.

Case study. Corporate retail super app: main app—authorization, navigation, common UI. Plugins: StockPlugin (inventory), CRMPlugin (customer management), AnalyticsPlugin (dashboards). Each developed by separate team, loaded via MDM on employee first launch. Android: DexClassLoader with signature verification. iOS: compile-time plugins via local SPM packages, activation via feature flags. Plugin update—without main app update in Google Play (via custom distribution server for corporate devices).

Timeline

Pricing determined individually. Plugin architecture solves complex platforms; for standard products it's excessive and complicates development without benefit.