Recomposition is not re-rendering, and that is why your list stutters
Compose re-executes functions whose inputs changed. An unstable parameter means all of them.
compose
129 posts
Your custom font has a fallback, and you didn't choose it
A custom font covers a subset of Unicode. Everything outside it falls back, and the fallback decides how your app renders emoji, non-Latin scripts and symbols — usually without anyone checking.
Image loading is the least portable thing in your shared UI
Decode, cache and memory pressure are platform concerns, and the composable that hides them decides your scroll performance.
Shared navigation has no back stack owner, and that is the hard part
Android has a system back gesture with an owner. iOS has a navigation controller. A shared back stack answers to both.
TextFieldState is a document, and edits are transactions on it
TextFieldState models text, selection and composition together. Editing through its transaction API preserves undo history and cursor position in ways string replacement cannot, which matters for any non-trivial input.
Your list rows are different heights because text measurement is honest
Text height depends on content, font and scale, which makes uniform list rows harder than they look. Line-break strategies, hyphenation and baseline-relative padding are the tools that solve it without fixed heights.
@Preview is Android-only, and your shared UI has no preview at all
The annotation lives in an Android artifact, so commonMain cannot use it — and that shapes how you write composables.
AnnotatedString is why you don't need three Text composables in a Row
Text takes a String or an AnnotatedString. The second lets one composable carry multiple styles, inline content and clickable spans — replacing the Row of Texts that breaks at large font scales.
A shared ViewModel has no lifecycle, so you have to give it one
androidx.lifecycle.ViewModel is Android's. The shared class needs an explicit clear() and two platforms that call it.
Compose is growing a styles API, and it's for the gap theming never covered
MaterialTheme scopes values to a subtree, which is the wrong shape for reusable per-component configuration. Compose's styles direction addresses that gap; wrapper composables are the pattern to use today.
composeResources is not Android resources, and qualifiers resolve differently
Same folder names, different resolution. The accessor is typed, and a missing qualifier fails somewhere new.
Extending MaterialTheme beats replacing it, until it doesn't
Material models colour, type and shape. Everything else a design system needs — spacing, motion, semantic colour — has to be added. Extending with a parallel CompositionLocal is usually right; a full custom system rarely is.