u/ikrisliu

The app is Kotlin Multiplatform with Compose for the UI, which means the iOS screens are drawn by Skia into a single view rather than composed from UIKit. It's on the App Store. I want to write down what that decision costs on the iOS side specifically, including one thing I shipped broken because it can't be fixed from app code.

Text selection in CJK, which I couldn't fix

Long-press to select a word in Chinese and you get one character.

SkiaParagraph.getWordBoundary hands off to Skia, and SkUnicode ships no CJK segmentation dictionary, so you get plain UAX#29. An ideograph is Word_Break=Other and only matches WB999, the "break everywhere else" rule, so every character is its own word.

I spent most of a day trying to fix it from app code before giving up. To fix it you'd need characters merged, not split, and the rules that join across a character (MidLetter, Numeric, ExtendNumLet, ZWJ) all require ALetter/Numeric/Katakana/Hebrew_Letter on both sides. WB4 discards zero-width Format characters before any of that runs, so you can't insert your way out either. I think it needs a change in skiko.

Compose on Android has the reverse bug in the same feature, where a long press swallows the whole sentence, and there you can plant zero-width breaks with ICU and move on. Only one of the two was fixable from where I was sitting.

If anyone has a way around the Skia side I'd like to hear it, this is the part of the app I'm least happy about.

Overlays stop at the safe area

A full-window scrim behind a modal left the status bar and home indicator bands undimmed, because the popup respects platform insets. Looks like a rendering glitch on iOS since a native presentation dims edge to edge.

actual fun fullBleedPopupProperties(): PopupProperties = PopupProperties(usePlatformInsets = false)

Small fix, but you only go looking for it if you already know what the native version looks like.

Material sheets don't move like iOS sheets

This took more time than anything else on the list relative to how small it looks. Material3's ModalBottomSheet settles with a spring and an iOS sheet slides on a decelerating curve, and side by side you can tell immediately even if you can't say why.

Material3 doesn't expose an animation spec for sheets. It reads the show and drag-settle spec from motionScheme.defaultSpatialSpec and the dismiss spec from motionScheme.fastEffectsSpec, and it re-reads both from the ambient theme inside the sheet's own composition, so you have to override through a scoped theme rather than passing anything in:

private val SheetMotionScheme = object : MotionScheme by MotionScheme.standard() {
    override fun <T> defaultSpatialSpec(): FiniteAnimationSpec<T> = tween(400, easing = IosSheetEasing)
    override fun <T> fastEffectsSpec(): FiniteAnimationSpec<T> = tween(400, easing = IosSheetEasing)
}

val IosSheetEasing = CubicBezierEasing(a = 0.32f, b = 0.72f, c = 0f, d = 1f)

There's a fair amount of this kind of work. It doesn't come with the framework and it doesn't show up in any estimate, but users notice when it's missing.

Scroll behaviour you end up rebuilding

UIScrollView hands you a set of behaviours that people read as "this app is put together properly". None of them come with Compose. We wrote all three of these into our own UI library.

alwaysBounceVertical. On iOS a scroll view rubber-bands even when the content fits on screen. Compose won't bounce if there's nothing to scroll, so short pages feel inert next to a native app. Ours is a modifier doing a graphicsLayer translation, which means the list also needs clipToBounds() or the bounce draws the top row over whatever is pinned above it:

LazyColumn(
    modifier
        .fillMaxWidth()
        .clipToBounds()
        .alwaysBounceVertical(listState),
)

scrollsToTop. Tapping the status bar scrolls to top automatically on UIScrollView. In Compose you catch the tap and route it to the right scroll state yourself, and it gets fiddly on pages with a pinned top bar because the thing covering the status bar isn't the thing that scrolls. We ended up with a ScrollBox wrapping the whole scaffold rather than the top bar slot, and the bar opts into the gesture with a modifier.

Swipe to reveal row actions. Nothing built in, so the swipe, the action buttons and the thresholds are all yours. The part that's easy to miss is that opening one row has to close whichever row was open before, or you get two rows showing actions at once, which no iOS list does. Ours is a coordinator passed down through a composition local so the rows can see each other.

None of these were hard to write. They're just things you get on iOS rather than things you build, so nobody thinks to schedule them.

One where iOS was the stricter platform

We stream SSE from the backend. The first version used flow { ... emit(event) } inside Ktor's execute {} block, which passed everything on Android and died on iOS with the backend logging context canceled.

flow enforces context preservation and Ktor's response scope isn't guaranteed to run on the collector's dispatcher. On JVM/OkHttp it happens to, so the check never trips. Kotlin/Native throws, the coroutine fails, the connection drops. channelFlow + send fixes it.

So the iOS build caught a real concurrency bug that the Android build had no way of surfacing. That one went in our favour.

StoreKit 2 detail worth checking in your own code

Sharing the billing logic forced me to be precise about something I'd previously been sloppy with:

/** null when there is no active subscription; throws when the store can't be reached. */
suspend fun subscriptionAutoRenewing(): Boolean?

RenewalInfo.willAutoRenew gives you the real answer, but if "no active subscription" and "StoreKit didn't respond" both collapse into false, a paying user sees a "your subscription has been canceled" banner any time their connection is flaky. Nothing to do with cross-platform, I just found it while writing the shared interface.

One thing that was easier than native

Live language switching. NSLocalizedString resolves against NSBundle, which caches the launch language, so changing language in-app normally means swizzling or a restart. CMP resolves resources per composition against NSLocale.preferredLanguages, which reads AppleLanguages out of NSUserDefaults live.

NSUserDefaults.standardUserDefaults.setObject(listOf(tag), "AppleLanguages")

That plus a key(tag) re-render and all 12 locales swap with no restart. Read preferredLanguages at startup first so you can restore "follow system" later.

Overall

Layout, state and business logic shared fine. What didn't come free is the stuff above: text selection is worse and in one case I couldn't fix it, and insets, scroll behaviour and motion all need deliberate work or the app reads as Android with different colours. A lot of that work is rebuilding things UIKit gives you by default, which is easy to underestimate because you've never had to think about them. You need someone who knows what iOS is supposed to feel like, because nothing in the toolchain will tell you.

Whether that's a good trade depends on how much of your app is the shared part. For us it was worth it. I wouldn't assume that generalises.

Upfront disclosure: I found this while shipping a Compose Multiplatform app, but this bug is pure Android — it's in androidx ui-text and it reproduces in any Compose app with a SelectionContainer or a selectable Text. If your app has Chinese, Japanese or Korean users, you probably have it right now and haven't noticed.

The symptom

Long-press a word in Chinese prose to select it. Instead of the word, you get the entire clause, stopping only at punctuation. Latin text in the same app behaves perfectly.

That's why this survives review: if you and your QA read English, the selection handles look flawless.

The cause

WordIterator.nextBoundary / prevBoundary skip any boundary whose two sides are both letters or digits. That rule was added for a good reason — a letter↔emoji seam shouldn't split a word — but the check is on character class, and every ideograph is a letter.

So in Chinese, every boundary between two characters qualifies as "letter on both sides", every boundary gets skipped, and the expansion runs until it hits punctuation or the end of the paragraph. English stops at its spaces (spaces aren't letters), which is why the bug is invisible in Latin scripts.

In my testing this is present from 1.8.0 through at least 1.12.0-beta02, and there's no public API to opt out of the behavior.

The workaround

Since you can't change the iterator, you change the text: plant zero-width breaks at Han–Han seams so the iterator has boundaries it won't skip. ICU already knows where the words are — it segments Han by dictionary off the script, not the locale, so the default locale is fine and the boundaries come out identical under zh and en:

fun cjkWordBoundaries(text: String): List<Int> {
    // Latin-only prose already selects correctly and is the common case — skip the scan entirely.
    if (text.codePoints().noneMatch(::isHan)) return emptyList()
    val iterator = BreakIterator.getWordInstance()
    iterator.setText(text)
    val offsets = mutableListOf<Int>()
    var offset = iterator.first()
    while (offset != BreakIterator.DONE) {
        if (text.isHanSeam(offset)) offsets += offset
        offset = iterator.next()
    }
    return offsets
}

/** Interior offsets only, and only where BOTH sides are Han. */
private fun String.isHanSeam(offset: Int): Boolean {
    if (offset <= 0 || offset >= length) return false
    return isHan(codePointAt(offset)) && isHan(Character.codePointBefore(this, offset))
}

private fun isHan(cp: Int): Boolean = Character.UnicodeScript.of(cp) == Character.UnicodeScript.HAN

Two things that matter in the details:

• Only report Han↔Han seams. A Han↔Latin seam already stops the runaway on its own, so planting a break there would only pollute the text for no gain.
• Keep the Latin fast path. Most strings in most apps have no Han at all, and you don't want an ICU pass on every selectable Text.

The more general point

The reason I'm posting this rather than just filing it: it belongs to a category I got burned by repeatedly, which is Android quietly being the forgiving platform.

Another one from the same codebase, this time in coroutines. This is fine on Android:

fun stream(): Flow<Event> = flow {
    client.prepareGet(url).execute { response -> /* parse */ emit(event) }
}

flow {}'s emit enforces context preservation — you may not emit from a coroutine context other than the collector's. Ktor's execute {} block gives you a scope that may run on a different dispatcher. On OkHttp it happens to run in-context, so the contract is never violated and everything passes, forever.

It's still a contract violation. It's just latent instead of active, held in place by an implementation detail of the engine you happen to use. Swap the engine, change a dispatcher, and it becomes real. (channelFlow {} + send is the fix — send is safe across contexts.)

Same shape as the WordIterator bug: the platform's forgiving behavior in the common case is exactly what stops you from finding the problem.

What I'd check in your own app

1. Long-press a Chinese/Japanese sentence in any selectable Text. Takes 10 seconds.
2. Grep for flow { wrapping a third-party callback or execute/use scope.

Happy to go into detail on either. If someone knows of a ui-text issue already tracking the first one, or a cleaner workaround than planting breaks, I'd genuinely like to hear it — the zero-width approach works but it means the string you select from isn't byte-identical to the string you rendered, and I'm not thrilled about that.