Archives

A driver reads the pit board once per lap, at 300 km/h, in under a second. If the board is cluttered, the message is lost. Semantics work the same way: your UI is read by a screen reader, and what it hears depends on what you put on the board.

In endurance racing every car carries a timing transponder: the circuit knows exactly where you are, every lap, every sector. This is how to put one on your KMP project.

The FIA technical regulations never call anything a small wing. They name parts by what they do. Shape tokens work the same way, and one XML file can feed Compose and SwiftUI without sharing a line of UI.

A deep link is the radio call that sends a user straight to one screen, skipping the whole navigation flow. Here's how I handle the parsing in commonMain and keep the platform glue thin on Android and iOS.

A race car streams telemetry to the pit wall over one radio link, whatever the sensor. Analytics and crash reporting in KMP should work the same way: one interface in commonMain, the native SDKs underneath.

In GT racing, every car crosses the weighbridge and the minimum weight limit only ever goes up. That's how a coverage floor should work too.

The pit lane is a second line through the same circuit, not a detour around it. Here is why NetFlow 0.7.0 added Retrofit-style annotations on top of its DSL, and the exact point where they stop.

The spec says 120 Nm and you already knew that. Knowing the number was never the hard part. My validation rules were already shared. The sixty lines of state around them were not.

Five ligths go out and every car reacts to the same signal at once. My shimmer effect wasn't doing that. Every skeleton on screen was running its own private clock.

AI generation adapts to anything you ask. A bash script adapts to nothing. After a few months of scaffolding KMP feature modules both ways, I know which one I trust.

Nobody starts a two-hour race with enough fuel for two hours. You run stints. Paging works the same way, and since 3.3 you can run the whole strategy from commonMain.

A driver changes the engine map from the wheel, mid-race, no pit stop required. Feature flags do the same for your app: change behaviour without shipping a build. Here's how I structure flags and remote config once, in commonMain, for both platforms.

expect/actual is easy until you leave the trivial expect fun behind. Here's what bites with expect classes, constructors, actual typealiases, and the compiler rules nobody warns you about.

An uncaught coroutine exception crashes your KMP app on both platforms, and the platform safety nets don't extend to iOS. Here's how I build crash boundaries in commonMain.

Tyre warmers keep rubber at temperature so the car has grip the instant it leaves the box. Coil 3's memory and disk cache do the same for images — and the same code now runs on Android and iOS from commonMain.

expect/actual isn't just for business logic. Here's how to build a shared barcode scanner Composable that reads through any platform's lens.

Before a race car can compete, it needs to be homologated. Before your KMP library can be used by anyone, it needs Maven Central.

The pit crew doesn't wait to be asked. They intercept the car, do their work, and the driver rejoins the race. Ktor plugins work the same way: auth, logging, and retry all happen before your business logic sees a thing.

The pit crew was always there. I just had to build it: a Gradle plugin that automates iOS and Android splash screen setup from a single config block.

Metro drops the clutch on runtime DI errors. Three patterns in a real KMP app: binding contributions, platform graphs, and child scopes.

Objective-C headers turned your Kotlin enums into class wrappers and your function signatures into noise. Swift Export sends the same data over a cleaner channel.

Why organising your garage by components is slowing down your pit stops.

A pit wall crew knows exactly what to do without being told from scratch. Custom Gemini commands work the same way.

Before the car hits the grid, telemetry confirms every sector. Before your UI ships, runComposeUiTest confirms every composable.

Navigation 3 supports shared element transitions. It always did. LocalNavAnimatedContentScope was the piece the docs never mentioned.

The intermediary between your app and the database never disappeared. It just stopped being your problem.

Track limits don't stop you from going wide. They penalise you for it. Custom Detekt rules work the same way.

StateFlow is your lap timer — always showing the latest lap. SharedFlow is the race radio — you only hear what's broadcasted while you're tuned in.

Same engine, different cockpit: how Compose and SwiftUI handle side effects when sharing a Kotlin Multiplatform ViewModel.

Building fluid, reliable shared element transitions in real-world Compose apps

What Is Really Worth Sharing

How Robolectric Made Compose UI Tests Fast and CI Friendly

Tired of Koin blowing up on iOS because of reified generics? Here’s the definitive fix. Clean, type-safe, Swift-friendly. No crashes, no leaks, no nonsense.

All logic, all flows, all platform calls are written in Kotlin.

A simple, clean, and shows how to combine multiple NavDisplays in a way that scales beautifully as your app grows.

Why handling loading in your repository isn’t bad architecture, it’s actually a sign of experience and clean design.

How to keep your app busy while your users (and you) sleep.

A funny and honest story about bugs, PHP, and how one vanilla ice cream helped me realize that talking to myself was actually my greatest debugging tool.

A real-world story of how one Android-first library became a Kotlin Multiplatform (KMP) journey.

A stunning leap in visual design that only native apps truly get to experience.

Bring Retrofit’s simplicity to Kotlin Multiplatform with Ktorfit — type-safe networking that just works everywhere.

Differences between KMP and Flutter

Koin Annotations on Compose Multiplatform

If you’ve been curious about Kotlin Multiplatform (KMP) or already building cross-platform apps, I’ve got some great news for you.