DEV Community: Kanon Fujita

[KMP] I Chose Kotlin Multiplatform for the UI. Sharing the Audio Engine Is What Saved Me.

Kanon Fujita — Sat, 29 Aug 2026 16:22:51 +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.

The occasion was RevenueCat Shipaton, a two-month hackathon running from August 1 to September 30. I started building on July 31, 2026, and the iOS version went live on the App Store within August. The Android version is coming soon.

I had done some Android development before, but I had never built an iOS app. I also have a full-time job, so the only time I can put into this is evenings and weekends.

This post is about why I chose Kotlin Multiplatform, not as a feature comparison but as a countdown of the days I actually had. It then covers the use I had not planned for, which is the one that ended up helping most, and the things I did not notice until I had shipped. Two months sounds like a lot, but a bit of math before starting showed that the time available for writing code was much shorter.

The deadline is not the submission date, it is the day you are live on a store

Under the Shipaton rules, the app's first public release has to happen within the contest window, and the app has to be live on the App Store or Google Play at submission time.

So before anything else, I worked out how many days it takes to get onto each store.

Step	Time it takes	Nature of the wait
Recruit 12 testers	A few days to unknowable	You are asking people for a favour; working faster does not speed it up
Google Play closed test	14+ days	12 or more testers must stay opted in for 14 consecutive days (the official testing requirements). The days themselves are the requirement
Google Play production access review	About a week	You apply only after the closed test is done
App Store review	Around 2 days	Apple says 90% of submissions are reviewed within 24 hours, though I have heard of it taking over a week, so leave a margin

On the Android side, more than three weeks pass just by waiting. The 14-day closed test is the big one.

Recruiting 12 testers is also a real hurdle for a solo developer. You have to ask people, get them to install the app, and have them stay opted in for 14 straight days. How many will say yes, and how long it takes, is not up to you. If this step slips, everything behind it slips too.

Build Android first, build iOS during the test window

That structure of waiting decided the order for me.

The red bars are the waits I cannot shorten myself.

If I finish Android first and get the closed test running, those 14 days become the window for building the iOS version. Do it the other way around and Android's 14 days simply shift later, with a real chance of missing the end of September.

With a day job on weekdays, I budgeted 5 days of ideation before implementation, then 2 weeks of implementation for Android and 10 days for iOS. On that plan, both versions are live on their stores by early September.

The options for shipping to two platforms alone

Option	Verdict
Write Android and iOS natively, separately	Double the work. Building the iOS version solo within the 14-day closed test window is a stretch
Flutter or React Native	Fast for UI. But the heart of this app is audio processing, not UI, and that part would have to be rewritten in yet another language
Kotlin Multiplatform + Compose Multiplatform	I already knew Kotlin, so this is what I picked

I did consider Flutter and React Native, but the decision came down to where the app's value lives. If the screens and the experience had been the main event, I might well have picked one of those.

At the time I chose, I was looking at exactly three things: I am one person shipping to two platforms, I already write Kotlin comfortably, and the UI and the app's core only have to be written once. How to handle music generation was not part of the decision. As I explain below, it was going to run on a server anyway.

After choosing, the engine moved on-device

That is the technology-selection story. What actually saved me was a part I had not been thinking about when I chose.

When I started, music generation ran in Python on AWS Lambda. The app uploads the videos, the server sends back a track. In that shape, Android and iOS both call the same server and get the same track back, so the question of what language to write the generator in never comes up.

But the setup had problems.

Uploading seven five-second videos means a lot of transfer and a lot of waiting
As a solo developer, every new user's compute cost lands directly on me
Offline, the app can do nothing
Users' videos get sent to my server

Lining those four up settled the direction: generation should happen entirely on the device. The question was how. The normal way is to write the same processing twice, once per platform. Rewriting audio processing in two languages, and keeping the output identical between them, was not realistic with the days I had left.

One common way to share audio code is to write it in C++ and call it from both platforms. It is a standard choice for audio work, but the build setup takes time and I already had Kotlin experience, so I passed on it this time.

This is where already being on Kotlin Multiplatform saved me. The engine is pure computation with no external dependencies, so writing it in Kotlin means it simply runs on both platforms. The server had guaranteed the same track on either OS, and that property survived the move onto the device.

In other words, the setup I had chosen to share UI turned out to also be the way to share the audio processing. I had not anticipated that use when I made the choice.

On day 5 of the project I ported the engine to Kotlin, and the next day I deleted the server. The C++ comparison and the porting itself deserve their own post.

What ended up shared: the engine and the UI

The ported engine is about 2,200 lines of Kotlin in commonMain (the shared source set used by both Android and iOS). It has no external dependencies, and the only thing it uses from the standard library is kotlin.math.

Green is code shared by both platforms, red is code written per platform. Exactly one line runs from the engine to OS-dependent code, and that is the part that pulls audio data out of a video file. Everything past that point runs as shared code: analysis, arrangement, mixing, rendering.

The random number generator is also self-implemented (SplitMix64), so the same input always produces the same track. Which also means both platforms run the same generation logic and produce tracks of the same quality.

In hindsight, sharing the engine is the thing I am most glad KMP gave me. But I only realised that later. While I was building, the benefit I could actually feel was on the UI side.

The app looks like a cassette deck. It uses almost none of Material's default components; most of what is on screen is drawn by hand, down to details like how a key sinks when pressed and the reels that spin during processing. Keeping that level of polish identical across two platforms is normally a lot of work. With Compose Multiplatform, each adjustment is made once and lands on both.

The more the UI is worth fussing over, the more sharing it pays off.

How long it actually took

Here is how the implementation time came out (as of August 21, 2026).

	Estimated	Actual
Android	2 weeks	6 days
iOS	10 days	2 days

Considerably faster than planned. The iOS version took two days because the UI and the music engine were already shared, and what remained to write was only the OS-specific part: camera, playback, export. Starting from zero iOS experience and having something working in two days came down to how much did not have to be written.

The current line counts (as of August 28, 2026):

commonMain  7,799   androidMain 1,813   iosMain 1,298   Swift 1,156

That works out to 64.6% shared.

What I noticed only after shipping

Shipping to iOS first surfaces Android's problems early

The plan was "finish Android first, build iOS during the test window", but the store submission happened on iOS first, and so did the release.

App Store review flagged how my camera and microphone permission flow was built. The gist: once you show a pre-permission explanation screen, it must lead directly into the system permission dialog, with no path for the user to defer it.

I rebuilt the permission flow, and not only on iOS. The design being loose about permissions was just as true of the Android version, so I fixed the same screen on both at once. The copy lives in shared resources, so the fix across four languages was also a single change.

Fixes made during the closed test doubled as iOS improvements

The plan was to spend the closed test's 14 days entirely on iOS implementation. In practice, testers reported things, I found things I wanted to fix myself, and I shipped several Android updates during that window. It did not go purely to iOS as planned.

But most of what I fixed lived in the shared code. Work done for the Android version became improvements to the iOS version at the same time. The test window did eat into implementation time, but none of that work had to be done twice.

Work that was missing from the estimate

The combination of iOS's asynchronous APIs and Kotlin cost me a day. A video export stopped returning forever, and finding and working around the cause took time. In the end I rewrote the iOS-specific AV work in Swift. That story is in another post.

Nothing outside the code was shared. Signing, build settings and uploading to TestFlight are ordinary iOS work and all of it still happens, and review responses, screenshots and policy compliance happen once per store. That turned out to be tougher than I expected. I will write separately about where KMP helped and where it did not.

Afterfade is being built for RevenueCat Shipaton 2026.

App Store: https://apps.apple.com/us/app/afterfade/id6800247416
Google Play: in review

[KMP] Where Kotlin Stops and Swift Starts in a Kotlin Multiplatform App

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 and Compose Multiplatform. Implementation took six days for Android and two days for iOS.

This post is about a bug I hit during development, and how it led me to a rule for deciding how much of the iOS side to write in Kotlin and where to hand off to Swift.

One thing worth knowing up front: I had never built an iOS app before. Swift and AVFoundation were both new to me on this project. The reason I could still ship the iOS version in two days is that the UI and the music engine were already shared with Android.

The video export never returned

Once seven five-second videos have been collected, the app generates a track and then exports a single video that stitches the clips together in time with it. That export never returned.

While it runs, the app shows a loading state, and it simply stayed there. No crash, nothing in the logs. The same flow worked fine on Android, and it only reproduced on iOS. I will refer to this state, where a process never returns and the app sits waiting forever, as a hang.

The part that hung is shown in red below. Green is code shared by both platforms, blue and orange are code specific to each one.

The export is not shared between the two platforms. Here is what the iOS side looked like at the time.

suspend fun generateFilm(...): Boolean = withContext(Dispatchers.IO) {
    // ... build the AVMutableComposition ...

    val exportSession = AVAssetExportSession(
        asset = composition,
        presetName = AVAssetExportPresetMediumQuality,
    ) ?: return@withContext false

    exportSession.outputURL = outputUrl
    exportSession.outputFileType = AVFileTypeMPEG4

    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 to expose it as a Kotlin suspend function. This seems to be the common way to bridge a native async API from Kotlin/Native, and it apparently works most of the time.

When it does not work, the completion handler is never invoked. cont.resume(...) is never reached, so the coroutine waits forever. No exception is thrown either, which left me with no indication of where it had stopped.

What I tried, and why none of it worked

I suspected the dispatcher first. I switched from Dispatchers.IO to Dispatchers.Main, and I tried pushing the work onto the main thread explicitly with dispatch_async(dispatch_get_main_queue()). The behaviour changed, but the hang did not go away.

Then I added a timeout. Wrapping the call in withTimeoutOrNull should at least have prevented it from waiting forever. That did not work either. The export still never came back with the timeout in place.

In the end I stopped using the completion handler altogether and polled exportSession.status every 200 milliseconds instead. That worked.

It is a poor fix, though. It throws away the completion callback the API already provides and checks the state on a timer instead, which means up to 200 milliseconds of delay after the export finishes, and it also makes the failure reason harder to surface.

The same thing takes a few lines in Swift with async/await. Even without any iOS experience, it is the kind of code you can get working by following the sample in the documentation. Instead I had 30 lines of Kotlin that were not receiving the completion callback correctly.

I never worked out why the completion handler was not invoked, or why withTimeoutOrNull had no effect. I stopped chasing the cause there and went looking at something else instead.

Why did I pick Kotlin Multiplatform in the first place?

The question I should have been asking was not how to fix it, but why this code was in Kotlin at all.

The reason to use Kotlin Multiplatform is to share code. So I went back and checked what FilmGenerator.ios.kt actually shared with Android.

It shared nothing. The file was iOS-specific work built on AVMutableComposition and AVAssetExportSession, while the Android version was entirely separate code built on Media3 Transformer. The only thing the two had in common was the function signature.

I had put code that cannot be shared on top of the machinery for sharing it. There was no benefit to gain, and what I was left with was the overhead of cinterop, the mechanism that lets Kotlin call C and Objective-C APIs, plus bugs caused by the two languages disagreeing about how asynchronous work should be awaited.

Whether Kotlin/Native can call an API is not a reason to write it in Kotlin. That was my mistake here.

Two questions for deciding what goes to Swift

Since then, I ask myself these two questions in order whenever I add something to the iOS side. They live in the project's rules file.

1. Can Android reuse the same code?

If it cannot, there is nothing to share by writing it in Kotlin, and all that remains is the cost of reaching iOS APIs from Kotlin. If it cannot be reused, write it in Swift.

2. Does the API call you back when it finishes?

Many iOS APIs return control immediately and call you back later through a completion handler, a delegate, or GCD. That model and the way Kotlin coroutines wait are built on different assumptions, and when they fail to line up you get a silent hang like this one. If the API calls you back, write it in Swift.

The first question settles it most of the time. The second is there to catch what the first one misses, and that is exactly what happened with the hang above: I missed the first question, and wrote something matching the second without noticing.

There are two more kinds of work that go to Swift without needing a question. One is APIs like CoreGraphics, where you release objects with CFRelease once you are done; Kotlin manages memory for you by default, so mixing manual release into it means tracking leaks and double frees by hand. The other is an iOS UI component itself, a UIView subclass such as a video player or a camera preview, which is simpler to build in Swift and embed from Compose.

NativeBridge: how Kotlin calls Swift

Handing work to Swift is not as simple as calling a Swift function from Kotlin, because in the usual setup that direction does not exist. In KMP, Swift depends on the Kotlin framework and not the other way around.

So the Kotlin side declares empty slots to be filled in later, and Swift injects the real implementations when the app starts. What goes into those slots is not a value but the work itself, as a lambda.

// composeApp/src/iosMain/.../bridge/NativeBridge.kt
typealias FilmExportFn = (
    clipPaths: List<String>,
    // ... the rest of the export arguments ...
    completion: (Boolean) -> Unit,
) -> Unit

object NativeBridge {
    var exportFilm: FilmExportFn? = null
    var createPlayerView: PlayerViewFactory? = null
    var extractAudio: AudioExtractFn? = null
    // ...
}

// iosApp/iosApp/iOSApp.swift
private func setupNativeBridge() {
    let bridge = NativeBridge.shared

    bridge.createPlayerView = { path, gravity, startSec, endSec, muted, pixelate in
        LoopingPlayerView(path: path, gravity: AVLayerVideoGravity(rawValue: gravity), ...)
    }
    // ...
}

The expect/actual interfaces did not change. What changed is the body of each actual, which now calls a NativeBridge lambda instead of reaching into AVFoundation.

// FilmGenerator.ios.kt today, 37 lines in total
val exportFilm = NativeBridge.exportFilm ?: return false

return suspendCancellableCoroutine { cont ->
    exportFilm(expandedPaths, expandedStarts, trackPath, bpm, outputPath) { success ->
        cont.resume(success)
    }
}

A 108-line file became 37 lines, and no AVFoundation API name appears in it any more. Embedding into Compose works the same way: UIKitView(factory = { NativeBridge.createPlayerView(...) }). The UI layer stays in Kotlin and does not change at all.

What it looks like in Swift

// iosApp/iosApp/FilmExporter.swift
// give up after 60 seconds; this waits without blocking a thread
let watchdog = Task {
    try await Task.sleep(nanoseconds: 60 * NSEC_PER_SEC)
    session.cancelExport()
}
await withCheckedContinuation { continuation in
    session.exportAsynchronously {
        continuation.resume()
    }
}
watchdog.cancel()

Structurally this is the same as the Kotlin version: a completion handler wrapped in a continuation. The difference is that here it is the usage the language and its runtime are designed around.

The timeout is also straightforward to express with Task. Because Task.sleep waits without occupying a thread, everything else keeps running while it waits. The problem I had with withTimeoutOrNull on the Kotlin side went away with it. The hang has not come back since the migration.

How the iOS side ended up divided

Applying those questions, the iOS-specific work landed like this. The Android side is mostly shared code already, so the only side that needs sorting is iOS.

Feature	Written in	Reason
Video composition and export	Swift	Calls back on completion
Audio extraction (AVAssetReader + CoreMedia)	Swift	Track loading calls back on completion
Dominant colour extraction (CoreGraphics)	Swift	You release the objects yourself
Video playback (AVPlayer + AVPlayerLayer)	Swift	The UI component itself
Sharing and saving to Photos	Swift	Calls back on completion
The camera capture session	Kotlin	Everything completes as you call it

That last row needs a little explanation.

The camera capture session is still in Kotlin. AVCaptureSession, AVCaptureDeviceInput and AVCaptureMovieFileOutput are all set up in CaptureScreen.ios.kt.

fun setupSession() {
    session.beginConfiguration()
    // ... swap the input device and the outputs ...
    if (session.canSetSessionPreset(AVCaptureSessionPreset1920x1080)) {
        session.setSessionPreset(AVCaptureSessionPreset1920x1080)
    }
    session.commitConfiguration()
}

I did not land on "move everything that touches AVFoundation to Swift" because this part is entirely synchronous. Everything from beginConfiguration() to commitConfiguration() completes as you call it, and there is no asynchronous completion to wait for.

The recording-finished callback (AVCaptureFileOutputRecordingDelegateProtocol) does call back, but it stays in Kotlin too. What makes a callback API dangerous is suspending a coroutine until the callback arrives. This one is not awaited that way; it only updates screen state when it fires, so it works fine in Kotlin.

What I hand to Swift is only the UIView that hosts the AVCaptureVideoPreviewLayer, which is the UI component itself.

The line is drawn per API behaviour, not per framework. Within the same AVFoundation, work that completes synchronously stays in Kotlin, and work that waits for a callback goes to Swift.

Share the right things, not the most lines

After the migration, the Swift code came to 1,251 lines. commonMain is 6,049 lines, which puts the shared portion at 48.7%. Had I kept everything in Kotlin, that number would look better.

Since then a larger refactor moved the screens and the generation flow into commonMain, and the shared portion is up to 64.6% (measured August 28, 2026). The line between Kotlin and Swift is still where this post leaves it; what got redrawn was the boundary inside Kotlin. I will write separately about what moved where.

I would argue that the value of Kotlin Multiplatform is not in how many lines you shared, but in whether the things worth sharing are actually shared.

In this app, the things worth sharing were the music engine and the UI, not the way a video export gets invoked. The engine is plain Kotlin in commonMain, about 2,200 lines, with no external dependencies. It runs on both platforms without a single platform branch, and the same input produces the same track on either one.

It is also why someone with no iOS experience could ship the iOS version in two days. Most of it did not have to be written. The part that did was fastest to write in Swift, and gave me the least trouble.

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: coming soon...