Beyond React Native: Architecting a Unified ONDC Commerce Stack with Kotlin Multiplatform & Compose

The ONDC Mandate: Performance and Scale Demand a New Architecture

The Open Network for Digital Commerce (ONDC) is not just another e-commerce platform; it's a foundational protocol designed to democratize digital commerce in India. This ambitious goal requires applications—both buyer and seller apps—that are not only feature-rich but also exceptionally performant, scalable, and reliable. For years, the default choice for building across iOS and Android has been cross-platform frameworks like React Native or Flutter. While they've served a purpose, their inherent architectural limitations pose a significant risk to applications built for the high-transaction, real-time demands of the ONDC network.

The reliance on a JavaScript bridge in React Native or a custom rendering engine in Flutter can introduce performance overhead, UI inconsistencies, and a complex dependency on third-party libraries for accessing native features. In the ONDC context, where a single search query can trigger a cascade of network requests and real-time inventory updates, these milliseconds of latency add up, leading to a sluggish user experience and potential transaction failures.

It's time for a paradigm shift. This guide provides a technical blueprint for architects and CTOs looking to build the next generation of ONDC applications. We will explore how to leverage Kotlin Multiplatform (KMP) and Compose Multiplatform to create a single, unified codebase that delivers uncompromising native performance across Android, iOS, and even the Web.

Why Kotlin Multiplatform is the Ideal Choice for ONDC

Kotlin Multiplatform isn't just another cross-platform framework; it's a fundamental shift in how we build software. Instead of abstracting away the platform, KMP embraces it. It allows you to share common code where it makes sense (business logic, data layer) while giving you direct, unbridled access to the native UI and platform APIs.

Unified Business Logic for the ONDC Protocol

The core of any ONDC application is its interaction with the Beckn protocol—search, select, init, confirm, status, etc. With KMP, you can write this entire protocol layer once in a shared Kotlin module. This includes:

• Data Models: Define ONDC entities like Item, Provider, Order, and Fulfillment in a single commonMain source set.
• API Client: Use a multiplatform networking library like Ktor to handle all HTTP requests and responses to your ONDC gateway or backend.
• State Management: Implement your application's state logic using Kotlin Coroutines and Flows, ensuring a consistent, reactive data flow across all platforms.
• Validation and Business Rules: All complex business logic, such as GST calculations, inventory checks, or delivery-time estimations, resides in the shared module, eliminating the risk of divergent implementations.

This approach guarantees that a feature implemented for Android will behave identically on iOS and the Web, as it's running the exact same compiled Kotlin code.

True Native Performance and UI

Unlike frameworks that render UI through a bridge or a non-native engine, KMP allows for two powerful UI strategies:

1. Pure Native UI: The shared Kotlin module compiles to a standard library format for each platform (AAR for Android, Framework for iOS). You can then build your UI using the platform's recommended toolkit: Jetpack Compose for Android and SwiftUI for iOS. Your native UI code calls directly into the shared Kotlin view models, resulting in zero performance overhead.
2. Shared UI with Compose Multiplatform: The more revolutionary approach. Compose Multiplatform extends Jetpack Compose to share UI code across Android, iOS (currently in Alpha), Desktop, and Web. You can write your UI components once in Kotlin and have them render natively on each platform. For ONDC, this means your product detail screen, shopping cart, and checkout flow can be defined in a single codebase, achieving unprecedented development velocity.

Seamless Interoperability with the expect/actual Pattern

Every platform has unique capabilities—GPS, secure storage, payment SDKs, or push notifications. KMP provides a clean, type-safe mechanism for accessing these features called expect/actual declarations.

In your commonMain shared code, you expect a function or class:

// in commonMain
expect fun getDeviceLocation(): Flow<Location>

Then, in each platform-specific source set, you provide the actual implementation:

// in androidMain
import com.google.android.gms.location.FusedLocationProviderClient

actual fun getDeviceLocation(): Flow<Location> {
    // Android-specific implementation using FusedLocationProviderClient
}

// in iosMain
import platform.CoreLocation.CLLocationManager

actual fun getDeviceLocation(): Flow<Location> {
    // iOS-specific implementation using CLLocationManager
}

This powerful pattern allows your shared business logic to depend on platform features without being coupled to their specific implementations, keeping the core clean and platform-agnostic.

Architectural Blueprint: A KMP-Powered ONDC Application

Let's design a robust, scalable architecture for a typical ONDC Buyer App using KMP. This blueprint can be easily adapted for Seller Apps as well.

The Shared Kotlin Core (commonMain)

This is the heart of your application. It contains no platform-specific code and is responsible for all business logic and data handling.

• Network Layer: Built with Ktor, a multiplatform asynchronous HTTP client from JetBrains. It will handle signing ONDC requests and parsing responses. Serialization is managed by kotlinx.serialization.
• Data Persistence: Using SQLDelight, a library that generates type-safe Kotlin APIs from your SQL statements. It provides multiplatform drivers for SQLite on Android/iOS and in-memory or other solutions for the Web/Desktop. This is perfect for caching ONDC catalog data or storing user preferences.
• Repository Pattern: Repositories will abstract the data sources (network vs. local cache) from the rest of the application. For instance, an OndcProductRepository will have functions like searchProducts(query: String) which internally decides whether to fetch from the network via Ktor or serve from the SQLDelight cache.
• State Management/View Models: A set of classes responsible for holding and managing UI-related state. These are written in pure Kotlin, using StateFlows to expose data streams that the UI layer on each platform can observe. Libraries like MVIKotlin can provide a more structured MVI (Model-View-Intent) approach.

Platform-Specific Layers (androidMain, iosMain, jsMain)

These layers contain the "glue" code that connects the shared core to each platform.

• Android (androidMain):

  • UI: Built entirely with Jetpack Compose. Screens and components observe the StateFlows from the shared ViewModels.
  • Dependency Injection: Using Koin or Hilt to provide dependencies like the FusedLocationProviderClient or SharedPreferences to the actual implementations.
  • Actuals: Provides implementations for Android-specific APIs (e.g., location services, payment gateway SDKs, file system access).

• iOS (iosMain):

  • UI: Built with SwiftUI. The shared Kotlin module is imported as a Swift framework. A thin adapter layer can be created to convert Kotlin's Flows into Swift's Combine Publishers for seamless integration with SwiftUI views.
  • Dependency Injection: Can use a simple service locator pattern or a Swift library like Swinject.
  • Actuals: Provides implementations for iOS-specific APIs using frameworks like CoreLocation, UserNotifications, and integrating with the Apple Pay SDK.

• Web (jsMain):

  • UI: This is where Compose for Web shines. You can reuse the same Composable functions written for Android to build a responsive web front-end. It transpiles the Kotlin code to JavaScript and uses HTML5 Canvas for rendering.
  • DOM Access: For elements that require direct DOM manipulation, Kotlin/JS provides full interoperability with JavaScript APIs.
  • Actuals: Implements expect declarations using browser APIs like localStorage or the Geolocation API.

The Backend: Headless ERPNext and ONDC Gateway

This KMP client-side architecture is backend-agnostic but pairs exceptionally well with a headless system like ERPNext. The shared Kotlin core's Ktor client communicates with two primary endpoints:

1. Your ONDC Gateway: For all ONDC protocol network calls.
2. Your Headless ERPNext Instance: For business-specific operations like user authentication, retrieving detailed order history, or managing customer support tickets that fall outside the ONDC protocol's scope.

Navigating the Challenges: Tooling, Talent, and Maturity

While KMP offers a compelling vision, adopting it requires a clear understanding of its current ecosystem.

• Tooling: The primary IDE is Android Studio, which has excellent support for KMP. However, iOS developers will need to work between Xcode (for UI and final builds) and Android Studio (for shared code). JetBrains' Fleet IDE is emerging as a potential unified solution. Gradle build times can also be a consideration for large projects.
• Talent Pool: Finding developers with deep KMP experience is still rare. The strategy should be to upskill existing Android (Kotlin) developers and pair them with iOS developers who are open to learning the architecture. The learning curve for an experienced Kotlin developer is surprisingly gentle.
• Library Ecosystem: The multiplatform library ecosystem is growing rapidly but is not yet as vast as that for React Native or Flutter. However, essential, high-quality libraries for networking (Ktor), persistence (SQLDelight), and state management (Coroutines/Flows) are mature and production-ready.

The Business Case: Why C-Level Should Invest in KMP for ONDC

For CTOs, CIOs, and Product Leaders, the decision to adopt a new technology stack must be driven by clear business value.

1. Reduced Time-to-Market: Writing the most complex part of the application—the business logic—once and deploying it everywhere dramatically accelerates development. A new feature for ONDC settlement or logistics tracking is built once and is immediately available on all platforms.
2. Lower Development & Maintenance Costs: A single logic codebase reduces the surface area for bugs and simplifies testing. You need a smaller, more focused team of Kotlin developers rather than maintaining separate, siloed teams for Android, iOS, and Web.
3. Superior and Consistent User Experience: By avoiding a performance-inhibiting bridge and using native UI components (or a high-performance shared UI with Compose), the application feels snappy and responsive. The consistency of business logic ensures a predictable and reliable experience for users, which is critical for building trust on the ONDC network.
4. Strategic, Future-Proof Asset: A KMP codebase is a long-term asset. It's not tied to the whims of a single company's framework. It's built on Kotlin, a modern, pragmatic language backed by Google and JetBrains, and compiles to standard, platform-native binaries. This is a resilient architecture built for the next decade of digital commerce.

---

Frequently Asked Questions (FAQ)

Q1: How does Kotlin Multiplatform's UI approach with Compose compare to Flutter? Flutter uses its own rendering engine (Skia) to draw pixels on the screen, which gives it great control but means it doesn't use native UI components. Compose Multiplatform takes a hybrid approach. On Android, it uses the native Jetpack Compose. On iOS, it currently uses a Canvas implementation (similar to Flutter) but is moving towards using native iOS components. On the Web, it also uses a Canvas. The key difference is that KMP gives you the choice: you can use Compose for shared UI or drop down to build with 100% native SwiftUI and Jetpack Compose if a specific screen demands it, all while sharing the same business logic.

Q2: What is the learning curve for an existing Android or iOS team? For an Android team already using Kotlin and Jetpack Compose, the learning curve is minimal. They mainly need to learn the KMP project structure and multiplatform libraries like Ktor. For an iOS team, the primary learning curve involves becoming familiar with Kotlin's syntax (which is very similar to Swift) and understanding how to integrate the compiled Kotlin framework into an Xcode project. The expect/actual pattern is intuitive for developers on both platforms.

Q3: Can we integrate our existing native libraries and SDKs with a KMP project? Absolutely. This is a core strength of KMP. You would use the expect/actual pattern. For example, if you need to integrate a specific Indian payment gateway SDK, you would expect a PaymentHandler class in your common code. Then, in androidMain and iosMain, you would write the actual implementations that call the respective native Android and iOS SDKs.

Q4: How mature is Compose for Web for a production ONDC application? Compose for Web is currently in Beta and is rapidly maturing. For complex, public-facing consumer apps, it's ready for building internal tools, dashboards (like a seller admin panel), or specific parts of a larger application. For a full-fledged ONDC buyer app on the web, a thorough evaluation of its performance and accessibility features is recommended. Many teams choose to start with KMP for sharing logic between Android and iOS and adopt Compose for Web as it reaches stability, giving them a clear and simple migration path.

---

Build Your Future-Proof ONDC Platform with Induji Technologies

The ONDC network demands more than just a functional app; it requires a strategic, high-performance, and scalable technical foundation. Moving beyond traditional cross-platform frameworks to a modern stack like Kotlin Multiplatform is not just a technical upgrade—it's a competitive advantage.

The experts at Induji Technologies specialize in architecting and building complex, mission-critical commerce platforms. We can guide you through every step of designing and implementing a unified ONDC stack with Kotlin Multiplatform, ensuring your application is ready for the scale and demands of India's new digital commerce era.

Contact us today for a strategic consultation and to request a quote for your ONDC project.