Implementing Shared Business Logic with Kotlin Multiplatform (KMP)

For years, mobile developers have been forced to choose between the performance of native development and the efficiency of cross-platform frameworks. Native development requires maintaining two separate codebases, which often leads to logic drift where business rules behave differently on iOS and Android. Cross-platform frameworks like Flutter or React Native solve the duplication problem but often introduce a custom rendering engine or a bridge that can degrade the user experience.

The logic-first paradigm represents a significant shift in this architectural debate by separating the concerns of business logic and user interface. This approach suggests that while the UI should be native to ensure the best possible performance and accessibility, the underlying data layers do not need to be platform-specific. By sharing the core logic, teams can achieve a high level of code reuse without sacrificing the high-fidelity feel of a truly native application.

This architectural pattern is primarily enabled by technologies like Kotlin Multiplatform which allow for the compilation of shared code into native libraries. On iOS, the shared code becomes a framework that Swift can consume directly, while on Android, it remains a standard library. This allows engineers to write their networking, persistence, and validation logic once while keeping the presentation layer completely decoupled.

The goal of logic-first development is not to write the entire app once, but to ensure the most critical and complex parts of your application are only written and tested a single time.

A major advantage of this approach is the reduction in testing overhead and the elimination of duplicate bugs across platforms. When a calculation error is fixed in the shared module, the fix propagates to both platforms simultaneously after a rebuild. This consistency is vital for applications handling complex financial transactions, healthcare data, or offline synchronization logic.

In a real-world scenario, the majority of mobile app code is dedicated to communicating with APIs and persisting that data locally. A logic-first approach treats these tasks as platform-independent services that reside within the shared module. This allows for a unified networking client configuration, including headers, retry logic, and authentication interceptors.

Modern libraries such as Ktor provide a multiplatform engine that uses the underlying native networking stacks like URLSession on iOS and OkHttp on Android. This ensures that the application still benefits from platform-level optimizations and security features. The following example demonstrates a shared repository that manages user profile data using a logic-first approach.

1class UserProfileRepository(private val api: UserApiService, private val database: LocalDatabase) {
2    // Fetches profile from network and persists to local storage
3    suspend fun refreshUserProfile(userId: String): Result<Profile> {
4        return try {
5            val remoteProfile = api.fetchProfile(userId)
6            database.saveProfile(remoteProfile)
7            Result.success(remoteProfile)
8        } catch (e: Exception) {
9            // Fallback to local cache if network fails
10            val cached = database.getProfile(userId)
11            cached?.let { Result.success(it) } ?: Result.failure(e)
12        }
13    }
14}

The repository pattern shown above acts as a single source of truth for both mobile platforms. Since the logic for error handling and caching is contained within this class, the mobile clients only need to observe the resulting data. This drastically reduces the surface area for platform-specific bugs and ensures that the offline-first experience is identical for all users.

Despite the goal of maximum sharing, some features inevitably require access to native platform APIs. Whether it is accessing the device's keychain, interacting with the camera, or getting the current battery level, a bridge is necessary. The logic-first paradigm handles this through a contract-based system known as the expect/actual mechanism.

In this pattern, the shared module defines an expected interface or class that it needs to function. Each platform then provides the actual implementation using its own native libraries and language features. This allows the shared code to remain clean and testable while still having the power to reach down into the hardware when required.

1// In the common shared module
2expect class DeviceLogger() {
3    fun logEvent(message: String)
4}
5
6// In the iOS implementation module
7actual class DeviceLogger {
8    actual fun logEvent(message: String) {
9        // Uses native iOS os_log
10        println("iOS Native Log: $message")
11    }
12}
13
14// In the Android implementation module
15actual class DeviceLogger {
16    actual fun logEvent(message: String) {
17        // Uses Android Log.d
18        android.util.Log.d("MobileApp", message)
19    }
20}

This mechanism is superior to traditional bridging because it is resolved at compile time. There is no runtime overhead or serialization cost associated with calling into native code. The compiler ensures that if an expected declaration is added, every supported platform provides a corresponding implementation before the build can succeed.

Transitioning to a logic-first architecture requires a thoughtful evaluation of your team's current expertise and project requirements. It is often most effective for existing native teams who want to increase velocity without retraining everyone on a new UI framework. This approach allows Swift developers to keep writing Swift and Android developers to keep writing Kotlin for their respective views.

However, this paradigm does introduce complexity in the build pipeline and continuous integration process. You must ensure that your CI environment can build for both targets and handle the distribution of the shared library. Additionally, debugging shared code can sometimes be more difficult than debugging pure native code if the sourcemaps are not correctly configured.

• Reduced code duplication in business, network, and data layers.
• Full access to native UI components and platform-specific APIs.
• Consistent behavior across platforms for complex logic.
• Steeper learning curve for build system configuration.
• Requires coordination between iOS and Android engineers on shared interfaces.

When deciding whether to adopt this approach, consider the complexity of your business logic. If your app is primarily a simple CRUD interface with very little unique logic, the overhead of a shared module might not be justified. For feature-rich applications with offline modes and complex state management, the logic-first approach provides a massive long-term advantage.