Android and iOS adjuster apps sharing one Kotlin Multiplatform core for assessment rules, sync and offline data.
View live demo Opens a working demo with sample content in a new tab.
On location
Witley Bay Bingo Hall roof damagePhoto: Simon_Cotterill (CC0)
Lightning StormPhoto: Brandon Morgan (CC0)
House HomePhoto: Binyamin Mellish (CC0)
Storm CloudsPhoto: Free Nature Stock (CC0)
Clearing fallen treesPhoto: USFWS/Southeast (CC BY 2.0)
About the Project
This is a Kotlin Multiplatform app development project for a regional insurance group whose loss adjusters assess property, motor and liability claims on site. The group already had two native apps, one for Android and one for iPhone. Over time they had drifted apart, and the drift had reached the one place it could not be tolerated: the settlement figure.
The calculation behind every settlement — excess, depreciation, policy limits — had been implemented twice, by two teams, in two languages. When the rules changed, Android usually shipped first and iOS followed weeks later, and in between the same damage could produce different numbers depending on which phone the adjuster carried. We rebuilt the apps around one shared core so that, by construction, they always agree.
About the Client
The client is a regional insurance group with a team of field adjusters who visit homes, vehicles and business premises after a claim. Their work happens in flooded basements, rural farmhouses and car parks, often with little or no mobile signal, and their conclusions turn directly into money paid to customers.
The group wanted to keep native apps: its adjusters were attached to the feel of their platform, and accessibility features and camera handling matter on site. What it could not keep was two independent versions of the rules that decide what a claim is worth.
Project Goals
Guarantee identical settlement calculations on Android and iOS.
Release rule changes to both platforms at the same time.
Work fully offline in basements and rural areas, then sync safely.
Keep a genuinely native interface on each platform.
Test the financially sensitive logic once, thoroughly.
Project Overview
The Challenge and Our Solution
The Challenge
Two separate native apps had drifted apart. The settlement calculation was implemented twice, and a rule change in the Android release took three weeks to reach iOS — during which the two apps could produce different figures for the same damage. Adjusters worked in basements and rural properties with no signal, so everything also had to run offline.
Our Solution
We extracted the parts that must never differ — assessment rules, excess and depreciation calculations, validation, offline storage and sync — into a Kotlin Multiplatform module with one set of unit tests. The Android app kept Jetpack Compose and the iOS app kept SwiftUI, so each still feels native. Offline data uses one SQLDelight schema compiled for both platforms, and sync conflicts are resolved by the same shared code on either device.
One Rulebook, Shared Between Two Native Apps
We identified everything that must never differ between platforms — assessment rules, excess and depreciation calculations, validation, the offline data model and sync — and moved it into a Kotlin Multiplatform module. That module compiles to native code for both Android and iOS, so each app calls the same logic rather than a reimplementation of it.
The result is that a settlement figure is no longer the product of two codebases that happen to agree. It is produced by one piece of code, reviewed once, and shipped to both platforms together.
Assessment, excess and depreciation rules written once
Validation shared between platforms
Native compilation for Android and iOS
Offline-First by Design
Adjusters cannot wait for a signal before recording a claim. The apps store everything locally in a single SQLDelight schema compiled for both platforms, so the data model is identical on every device. Photos, measurements and notes are captured offline and attached to the claim record.
When a connection returns, sync runs in the shared core as well. Conflicts — for example, an office update made while the adjuster was offline — are resolved by the same code on either platform, which means the outcome no longer depends on which phone did the syncing.
One SQLDelight schema for both platforms
Evidence captured offline and synced later
Conflict resolution in shared code
Native Interfaces Without Compromise
Sharing logic did not mean sharing a lowest-common-denominator interface. The Android app kept Jetpack Compose and the iOS app kept SwiftUI, each following its platform’s conventions for navigation, typography, camera access and accessibility.
Adjusters on both platforms got the same capabilities at the same time, while still using an app that feels like it belongs on their phone. Interface work can now focus on usability, because correctness lives in the core.
Jetpack Compose on Android
SwiftUI on iOS
Same features released together
Testing the Logic That Carries Financial Risk
Because the rules live in one module, they are covered by one shared test suite written with Kotest. Every rule change runs against the same scenarios — partial losses, limits, excesses, depreciation schedules — before it reaches either app.
Previously, the two implementations had to be tested separately and still drifted. Now a rule change is tested once and released to Android and iOS in the same week, rather than three weeks apart.
One Kotest suite for the shared core
Scenario tests for settlement rules
Same-week releases on both platforms
Our Process
How We Delivered It
1
Comparing the Two Apps
We traced the settlement calculation through both existing codebases and documented every difference we found.
2
Drawing the Shared Boundary
We agreed exactly which logic belongs in the shared core and which stays native, so neither side became a compromise.
3
Building the Core and Its Tests
Rules, validation, the offline schema and sync were rebuilt in Kotlin Multiplatform with a scenario-based test suite.
4
Connecting Compose and SwiftUI
Both native apps were wired to the shared core screen by screen, keeping their platform look and feel.
5
Field Trials and Rollout
Adjusters trialled the apps in low-signal locations before a coordinated release on both stores.
Key Features
What We Delivered
Shared assessment engine
Excess, depreciation and settlement rules written once and tested once.
One offline schema
SQLDelight database and sync logic compiled natively for Android and iOS.
Native interfaces
Jetpack Compose on Android, SwiftUI on iOS — each following its platform.
Evidence capture
Photos, measurements and notes captured offline and synced with the claim record.
Outcome
Results and Impact
Settlement calculations identical on both platforms by construction.
Rule changes released to Android and iOS in the same week, not three apart.
One shared test suite covering the logic that carries financial risk.
Native interfaces retained on both platforms — no compromise in feel.
Client Feedback
What the Client Says
★★★★★
Sharing the assessment rules between Android and iOS ended a class of bug we had lived with for years. The two apps cannot disagree now, and a rule change reaches both in the same week instead of three apart.
Mobile LeadRegional insurance group
Services
Services Behind This Project
The Kotlin Multiplatform, Mobile App expertise we used to build this cross-platform app development — and can bring to yours.
High-performance Android and iPhone apps built with Flutter, Dart, Kotlin and Swift — from idea and UI/UX design to Google Play and App Store launch.
Learn more
FAQ
Frequently Asked Questions
What is Kotlin Multiplatform and why use it here?
Kotlin Multiplatform lets one Kotlin codebase compile to native code for Android and iOS. It suits apps where business logic must be identical on both platforms but each interface should stay fully native. For an insurer, sharing the settlement rules removes the risk of two apps calculating different figures for the same claim.
Do the apps still feel native on iPhone and Android?
Yes. Only the logic is shared. The iPhone app uses SwiftUI and the Android app uses Jetpack Compose, so navigation, typography, camera handling and accessibility follow each platform’s conventions. Users get the same features at the same time without a cross-platform look.
How does the app work without mobile signal?
All claim data, photos and measurements are stored locally in a shared database schema. Adjusters can complete assessments offline, and the app syncs automatically when a connection returns. Conflicts are resolved by the same shared code on both platforms, so the result is consistent.
Can existing native apps be moved to a shared core gradually?
Usually, yes. We start by extracting the most critical and most duplicated logic — here, the settlement rules — and connect both apps to it, then move further pieces over time. This avoids a risky big-bang rewrite and delivers the consistency benefit early.
How is financially sensitive logic tested?
The shared rules have one scenario-based test suite covering limits, excesses, depreciation and partial losses. Every change runs against it before release. Testing once, rather than maintaining two separate suites, is what allows rule changes to ship to both platforms in the same week.
What drives the cost of a project like this?
Cost depends on how much logic must be shared, the complexity of the rules and offline sync, how many screens each native app has, and how much of the existing apps can be kept. An audit of the current codebases is the best starting point for a reliable estimate.
Similar Work
Related Projects
Case studies built with the same technologies or for similar needs.
