DEV Community: Kanon Fujita

[KMP]What It Took to Ship One Kotlin App to Both Stores

Kanon Fujita — Tue, 22 Sep 2026 07:38:07 +0000

Afterfade records seven five-second videos over the course of a day and turns them into one lo-fi track. It runs on Kotlin Multiplatform (KMP) and Compose Multiplatform, live on both the App Store and Google Play. I wrote four posts while building it — this one is the short version.

The numbers

Android took six days to build. iOS — my first iOS app — took two. 70.6% of the code is shared (9,011 of 12,764 lines). The music engine is 2,236 lines of pure Kotlin with zero external dependencies. Platform-specific code is almost entirely camera, video, billing, and ads.

commonMain  9,011   androidMain 1,537   iosMain 1,017   Swift 1,199

Everything written for iOS is the right two columns: 2,216 lines. → Full story

I deleted the server

Music generation started as Python on AWS Lambda — about a minute per track, cost scaling with users, and people's recordings traveling to my server. The engine is pure computation, so I ported it to Kotlin, put it in the shared source set, and it ran on both platforms. Generation now takes about 10 seconds, costs nothing, works in airplane mode, and nothing leaves the device.

The 52 tests I had written for Android ran on the iOS simulator without changing a line. I moved it on day 5 and deleted the AWS side the next day. → Full story

Where it broke

An iOS completion callback never returned to Kotlin/Native. I spent a full day on it, then rewrote the video export in Swift. Swift is 1,199 lines today, 9.4% of the codebase. App logic and screens took zero lines of it. → Full story

Where your app might land

Three questions:

On-device computation is the core → shareable
You draw your own UI → shareable
Camera, maps, or sensors are the point → per platform

If you already have an Android app in Kotlin: find one piece of logic that calls no OS API, move it into a shared module, and run its existing tests on the iOS simulator. They go green without a change, or they don't — and you know what you are working with.

Afterfade is built for RevenueCat Shipaton 2026.

App Store: https://apps.apple.com/us/app/afterfade/id6800247416
Google Play: https://play.google.com/store/apps/details?id=com.afterfade.app

Detailed posts:

I Had Never Written an iOS App. The iOS Version Took Two Days. — Choosing KMP, what shared and what didn't
Still 90% Kotlin, 9% Swift — The one piece I could not write in Kotlin
One Canvas-Drawn Cassette Deck UI, Identical on Android and iOS — Not a single Material Button; the drawing exists once in commonMain
No Server, Same Track on Both Platforms

[CMP]One Canvas-Drawn Cassette Deck UI, Identical on Android and iOS

Kanon Fujita — Tue, 22 Sep 2026 07:28:19 +0000

I build Afterfade on my own — seven five-second videos recorded over a day become one lo-fi track, built with Kotlin Multiplatform and Compose Multiplatform for Android and iOS. Background: why KMP and the Kotlin/Swift split. This post is about the UI.

Not a single Material Button, Card or Icon in this app. Everything — the mechanical keys, the cassette, the spinning reels — is drawn with Canvas and hand-written ImageVectors. The only Material I use is Text and one AlertDialog. I wanted the feel identical on both platforms, down to the millimetre, and what makes them match is that they run the same drawing code. The drawing exists once in commonMain. What worries people about Compose Multiplatform is that iOS will look like an Android app. This one looks like a cassette deck on both — there are no platform widgets to drift towards.

Why I did not use Material

The UI is built around a cassette deck and boombox metaphor. Material3's defaults did not fit — off-the-shelf components arrive with appearance and behaviour attached, and anything that does not fit has to be switched off piece by piece. Faster to draw from nothing.

Every dimension and colour goes through a token

Corner radii, stroke widths and colours all live as tokens in a 127-line theme definition. No raw dp values or colour literals appear in screen code.

object BoomboxElevation {
    val Key = 4.dp          // how far a mechanical key travels
}
object BoomboxColors {
    val Background = Color(0xFFEDEBE8)
    val RecRed = Color(0xFFD6431F)
    // ...
}

To change how far a key sinks when pressed, I edit one line, and both platforms sink by the same new amount.

What is drawn in Canvas

Roughly 1,800 lines of drawing code live in commonMain — the home screen cassette, the recording deck, the full icon set (hand-written vectors, no icon library), and the mechanical keys. The cassette parts are a shared collection of drawing functions; four screens call into them for the pieces they need.

How the press was built

The buttons recreate the keys on an old boombox — the kind that physically clunk downward when you press them. A flat drop shadow sits behind the key; on press the key body offsets toward it over a 90 ms tween, and a LongPress haptic fires at the moment of contact.

val pressed by interactionSource.collectIsPressedAsState()
val travel by animateDpAsState(
    targetValue = if (pressed || isRecording) BoomboxElevation.Key else 0.dp,
    animationSpec = tween(durationMillis = 90),
)

LaunchedEffect(pressed) {
    if (pressed) haptic.performHapticFeedback(HapticFeedbackType.LongPress)
}

While recording, isRecording holds the key down. This code lives in commonMain — nothing about the press can drift between platforms.

Screen reader labels are written once

Dropping Material means dropping what those components quietly carried: a Button announces itself, a Canvas says nothing. So the mechanical keys carry name and role explicitly.

Box(
    modifier = modifier
        .clickable(onClick = onClick)
        .semantics {
            this.contentDescription = contentDescription
            role = Role.Button
        },
)

Labels come from four-language string resources — declared once, feeding the accessibility tree on both platforms.

"Shared-looking" is not the same as shared code

I had split the capture screen with expect/actual because it touches the camera. The consequence: parts with nothing to do with the camera — the shutter key, the processing reel, the permission screen — got written twice. They looked identical, but only because every fix had to be repeated in both copies.

flowchart TB
    subgraph before["Before"]
        A1["Android capture screen<br/>the whole screen"]
        I1["iOS capture screen<br/>the whole screen (near copy)"]
    end
    subgraph after["After"]
        C2["Shared code (commonMain)<br/>shutter key, processing view, permission screen"]
        A2["Android capture screen<br/>camera only"]
        I2["iOS capture screen<br/>camera only"]
        C2 --> A2
        C2 --> I2
    end
    before --> after

    classDef sharedC fill:#d9ead3,stroke:#38761d,color:#000
    classDef platC fill:#f4cccc,stroke:#aa3333,color:#000
    class C2 sharedC
    class A1,I1,A2,I2 platC
    style before fill:#ffffff,stroke:#bbbbbb
    style after fill:#ffffff,stroke:#bbbbbb

Moving everything that does not touch a camera API to the shared side gave a net reduction of 249 lines and brought the shared portion from 64.6% to 70.6%.

UI code written only for iOS

Some things must not be the same. On iOS you swipe from the left edge to go back — without it an app feels wrong. Compose Multiplatform does not provide it, so I wrote it in iosMain. Android does not get this — the left-edge swipe is the OS back gesture.

Which UIs suit this approach

The more you draw yourself, the larger the share that lives in common code. An app with a world of its own sits well with Compose Multiplatform; an app chasing each platform's stock look gets less out of this.

If you are choosing between Compose Multiplatform and Flutter for a hand-drawn UI, the drawing will not settle it. What settles it is whether you have something outside the UI worth keeping in the same language — here, 2,200 lines of audio processing next to 1,800 lines of drawing.

Afterfade is being built for RevenueCat Shipaton 2026.

App Store: https://apps.apple.com/us/app/afterfade/id6800247416
Google Play: https://play.google.com/store/apps/details?id=com.afterfade.app

[KMP]No Server, Same Track on Both Platforms

Kanon Fujita — Sat, 12 Sep 2026 15:23:25 +0000

I build an app called Afterfade on my own. You record seven five-second videos over the course of a day, and the app turns them into a single lo-fi track. It ships on both Android and iOS, built with Kotlin Multiplatform (KMP) and Compose Multiplatform.

Music generation used to be Python running on AWS. The app extracted audio from the videos, uploaded it, and got a finished track back. There is no server now. Generation happens entirely on the device — about 10 seconds instead of a minute, zero cost per track, works in airplane mode, and nothing you record leaves your phone.

Why is in an earlier post; this one is about what I actually did. The part that mattered most: the tests I had written for Android ran on iOS as they were.

The setup I had, and what bothered me about it

The app pulled audio out of the videos, uploaded it to AWS, and Python on Lambda built a track and sent it back.

Afterfade is free and ad-supported. On Lambda in Tokyo, a track costs roughly $0.0023 — about $670/month at 300,000 tracks. The absolute numbers are not the problem; I did not want a setup where cost scales with usage.

Moving on-device turns one implementation into two

While generation lives on a server, there is exactly one implementation. Move it onto the device and it becomes two — one for Android, one for iOS. And this app is supposed to be deterministic.

This is where KMP paid off. Music generation touches no OS API, so I write it once in Kotlin and it runs on both. The ported engine is 2,236 lines in commonMain, importing only kotlin.math. FFT, filters, and resampling are hand-rolled — zero third-party dependencies. That DSP layer is now public as afterfade-dsp.

And because the destination language was Kotlin, the tests came along as they were. The 52 tests I had written for the JVM ran on the iOS simulator after nothing more than moving them to the shared source set.

Only two points on the path to a finished track touch the OS.

The MP4 decoder and the filesystem are the only pieces borrowed from the OS. About 86% of the music path is shared Kotlin.

Do both platforms really produce the same track?

I ran those 52 tests on the iOS simulator and 51 passed. One accompaniment did not match its expected value. The cause was this line, which converts a MIDI note number to a frequency.

fun midiToHz(midi: Int): Double = 440.0 * 2.0.pow((midi - 69) / 12.0)

pow is not required by its specification to return a correctly rounded result. The JVM and Apple's libm disagree on the last bit for some inputs. There are only twelve semitone ratios, so I dropped pow and replaced it with twelve correctly rounded constants. This looks like an audio-only problem, but it happens anywhere you compare floating-point results across platforms.

Had I written this twice, in Kotlin and in Swift, I would have had to build the verification tool before I could check anything.

Which workloads can lose their server?

The bill was not the only thing that went away — so did API versioning, timeouts, retries, cold-start workarounds, and the code that guaranteed uploaded audio was deleted.

My rule: the work has to be pure computation. The input is already on the device, the output follows from that input, and there is no large asset like a trained model to ship. If all three hold, there is not much reason to keep it on a server.

Since the day I deleted the server, I have not thought about the bill once. The setup I picked to share the UI turned out to help most outside it.

Afterfade is being built for RevenueCat Shipaton 2026.

App Store: https://apps.apple.com/us/app/afterfade/id6800247416
Google Play: https://play.google.com/store/apps/details?id=com.afterfade.app

[KMP] I Had Never Written an iOS App. The iOS Version Took Two Days

Kanon Fujita — Sat, 29 Aug 2026 16:22:51 +0000

I'm building an app called Afterfade on my own — seven five-second videos recorded over a day become one lo-fi track. The iOS version is live on the App Store; the Android version is in review.

I had some Android experience but had never built an iOS app. With only evenings and weekends, implementation came to six days for Android and two for iOS. Eight days total.

It is built with Kotlin Multiplatform (KMP) and Compose Multiplatform — iOS support went stable in May 2025. This post covers why I picked KMP, and what did and did not end up shared.

I counted the days to the store before writing anything

This was built for RevenueCat Shipaton, a two-month hackathon that requires you to be live on a store. Google Play demands 14 consecutive days of 12 testers in a closed test before you can even request production access — weeks pass while you do nothing. So: finish Android first, start the closed test, and spend those unmovable 14 days building iOS.

The options for shipping to two platforms alone

Writing each one natively doubles the work. Flutter or React Native let you write once, but the language becomes Dart or TypeScript. KMP + Compose Multiplatform keeps the language as Kotlin. I already knew Kotlin, so this is what I picked.

What paid off later was that for the first week I wrote a plain Android app without thinking about iOS at all, then added the iOS target. Pick Flutter or React Native and that week starts with rewriting in Dart or TypeScript. If you already have an Android app, KMP is the only option where the second platform is something you add rather than something you restart.

You can drop down to native later, and only where you need it

KMP gives you expect/actual: shared code declares a capability, and each platform writes the implementation.

// commonMain (shared by both platforms) — declaration only
@Composable
expect fun InterstitialAdEffect(
    show: Boolean,
    placement: String,
    onShown: () -> Unit = {},
    onComplete: () -> Unit,
)

The implementation calls that platform's APIs directly — the iOS camera is 320 lines of Kotlin calling AVFoundation as-is, the same API names you would write in Swift. This is also the escape hatch when an SDK has no KMP support; RevenueCat and AdMob have no shared KMP SDK, so each platform uses its official native SDK directly.

What gets shared and what does not

Only one line runs from the engine into red: pulling audio data out of a video file. Everything past that — analysis, arrangement, mixing, rendering — is shared. This app draws every component by hand, so all that polish lands on both platforms at once.

Moving the music engine onto the device

Music generation originally ran in Python on AWS Lambda — slow, costly, offline-unusable, and users' videos had to leave the device. The engine is pure computation with no external dependencies, so writing it in Kotlin means it runs on both platforms as-is. I ported it on day 5 and deleted the server the next day.

One review comment fixed both platforms and four languages

App Store review flagged my permission flow: once you show a pre-permission explanation, it has to lead straight into the system dialog, with no path to defer. The Android version had the same loose flow, and that screen lives in shared code. I fixed both at once. The copy lives in one shared resource set, so four languages were a single change too.

What did not get shared

Only two things ate real time, and both happened where I tried to write platform-specific work in shared code.

Video export got rewritten in Swift

iOS's asynchronous APIs and Kotlin made video export hang forever. I wrapped AVAssetExportSession's callback in suspendCancellableCoroutine; the callback never fired and the coroutine waited forever. I spent a day on it, then rewrote the AV work in Swift. The iOS "two days" includes that day.

Swift is 1,199 lines, 9.4% of the total — all video work and billing/ad SDK calls. I wrote that up in another post.

Some of the iOS feel comes for free, some does not

Haptics and the scrolling photo grid worked on both from shared code. What did not come for free was the swipe-back gesture (52 lines) and making the iPad share sheet appear as a popover. This app draws every component itself, though. Standard UI components would have more gaps to fill.

2,216 lines were all the second platform needed

commonMain  9,011   androidMain 1,537   iosMain 1,017   Swift 1,199

Everything written for iOS is the two columns on the right: 2,216 lines. 70.6% shared, and the ~3,700 platform-specific lines are almost entirely camera, video, billing and ads. Estimated two weeks for Android took six days; estimated ten days for iOS took two.

I got a first iOS app onto the App Store because only 2,216 lines were left. Shipping to a second platform is a question about the store, not about how much there is to build.

Afterfade is being built for RevenueCat Shipaton 2026.

App Store: https://apps.apple.com/us/app/afterfade/id6800247416
Google Play: https://play.google.com/store/apps/details?id=com.afterfade.app

[KMP] Still 90% Kotlin, 9% Swift

Kanon Fujita — Fri, 21 Aug 2026 14:18:00 +0000

I build an app called Afterfade on my own. You record seven five-second videos over the course of a day, and the app turns them into a single lo-fi track. It runs on both Android and iOS, built with Kotlin Multiplatform (KMP) and Compose Multiplatform. Swift and AVFoundation were new to me. Implementation still took six days for Android and two days for iOS (previous post).

Then the video export hung forever on iOS, and the fix was to stop writing that part in Kotlin. If you are considering KMP, what you are probably worried about is exactly that: what happens when you hit something Kotlin cannot handle cleanly. It turned out to cost one folder of Swift. The UI, the music engine, and the Android version were untouched.

The video export never returned

After collecting seven clips, the app generates a track and exports a video stitching them together. That export never returned — no crash, nothing in the logs. The same flow worked fine on Android.

// the iOS export implementation at the time, the relevant part
suspendCancellableCoroutine { cont ->
    exportSession.exportAsynchronouslyWithCompletionHandler {
        cont.resume(exportSession.status == AVAssetExportSessionStatusCompleted)
    }
    cont.invokeOnCancellation { exportSession.cancelExport() }
}

AVAssetExportSession reports completion through a completion handler, so the call is wrapped in suspendCancellableCoroutine. When it does not work, the handler is never invoked, and the coroutine waits forever with no exception.

What I tried, and why none of it worked

I changed the dispatcher and wrapped the call in withTimeoutOrNull. Neither fixed the hang. I never worked out the root cause — my best guess is object lifetime — but it did not matter. The iOS export shared nothing with Android; it was iOS-specific AVMutableComposition and AVAssetExportSession while the Android version was entirely separate code on Media3 Transformer. Being able to call an API from Kotlin/Native is not a reason to do it there.

Two questions for deciding what goes to Swift

Since then, I ask two questions whenever I add something to the iOS side. Can Android reuse the same code? If not, there is nothing to share by writing it in Kotlin. Does the API call you back when it finishes? Bridging a completion handler into a coroutine works most of the time; when it does not, it fails silently. In either case, write it in Swift.

The hang happened because I answered the first question wrong.

NativeBridge: how Kotlin calls Swift

Swift can call into Kotlin, but the usual setup gives you nothing for the opposite direction. So the Kotlin side declares empty slots, and Swift injects the real implementations at startup as lambdas.

// iosMain (iOS-only Kotlin)
object NativeBridge {
    var exportFilm: FilmExportFn? = null
    var createPlayerView: PlayerViewFactory? = null
    var extractAudio: AudioExtractFn? = null
}

The expect/actual entry points did not change, so all I swapped were the iOS-specific implementation files. Swift and Kotlin never land in the same file, and a change on either side cannot quietly alter the other without crossing a shared signature. Embedding into Compose is one call — UIKitView(factory = { NativeBridge.createPlayerView(...) }) with UIKitView.

How the iOS side ended up divided

Applying those questions: video composition, audio extraction, sharing, dominant colour extraction, and video playback all went to Swift — they either call back on completion or manage their own object lifetimes. The camera capture session stayed in Kotlin, because everything from AVCaptureSession's beginConfiguration() to commitConfiguration() completes as you call it.

On iOS too, 90% of the code is still Kotlin

Here is the current breakdown (measured September 2, 2026).

commonMain 9,011   androidMain 1,537   iosMain 1,017   Swift 1,199

Against those 12,764 lines, commonMain accounts for 70.6%. Swift is 9.4% — AVFoundation calls and NativeBridge registrations. The music engine is about 2,200 lines of plain Kotlin in commonMain, no external dependencies, no platform branches (the DSP layer is public as afterfade-dsp). The same input produces the same track on both platforms, verified down to bit-identical waveforms.

You do not need to work out how much will fit in Kotlin before choosing KMP. Whatever does not fit gets handed over afterwards, inside the platform-specific files. The worst case I hit was 1,199 lines of Swift, an untouched Android version, and a shared portion that went up rather than down.

Afterfade is being built for RevenueCat Shipaton 2026. I plan to write separately about the music engine and the UI.

App Store: https://apps.apple.com/us/app/afterfade/id6800247416
Google Play: https://play.google.com/store/apps/details?id=com.afterfade.app