DEV Community: Raul Arroyo

The UI Details That Make It Feel Native

Raul Arroyo — Sat, 06 Jun 2026 05:01:00 +0000

Part 4 - The UI Layer, Native Chrome, and the Details That Make It Feel Like an App

In Part 3 we converted raw WordPress HTML into native content blocks.

That solved one big problem: the app no longer had to display a website inside a WebView. Posts became structured content that Compose could render natively.

But once the content was native, another problem became obvious.

The app worked, but it still needed a visual identity.

Not just colors. Not just a logo. The whole reading experience needed to feel designed: typography, spacing, hero images, top bars, progress indicators, shapes, transitions, and platform behavior.

This part is about styling the app. Not in the sense of "making it pretty", but in the sense of making the interface support the content and feel intentional.

The Problem With a Technically Correct UI

The first version of the detail screen was functional.

It had an image, a title, the author, and the parsed content blocks from Part 3. Text rendered as text, images rendered as images, embeds had their own components.

Technically, that was a big step forward.

Visually, it was not enough.

The screen still felt too close to a default Compose app. Clean, readable, but generic. And for a content-heavy app, generic is a problem. The UI has to create a reading mood before the user reaches the first paragraph.

The goal became:

make articles feel editorial
keep content readable
avoid a default Material look
support dark mode
keep Android and iOS feeling native
avoid overbuilding a custom design system too early

That last one matters. It is easy to disappear into design-system work before the app has enough real screens to justify it.

So the approach was pragmatic: use Material3 as a base, then override the pieces that affected the product feel the most.

Typography as Branding

The biggest visual change came from typography.

Default Material typography is good, but it is intentionally neutral. For this app, neutral made the UI feel like a template.

The content needed stronger hierarchy:

big editorial headlines
readable body text
compact labels
a different feel between covers, sections, and article body

The app defines custom font families once:

data class AppFonts(
    val display: FontFamily,
    val body: FontFamily,
    val label: FontFamily,
)

Then the Material typography scale is adapted instead of ignored:

MaterialTheme(
    typography = appTypography(fonts),
    colorScheme = appColors,
    shapes = appShapes,
) {
    AppContent()
}

This was an important decision.

I did not want every component to manually choose fonts. That becomes messy quickly. But I also did not want the default Material scale to define the personality of the app.

So the theme sets the baseline, and individual branded moments can still be more explicit:

Text(
    text = article.title,
    style = typography.coverTitle
)

This made the hero feel like part of the product, not just a header.

The lesson: typography is not decoration. In a content app, typography is part of the product behavior.

The Platform Problem

A real KMP app has to answer an uncomfortable question:

Should the UI be identical on Android and iOS?

For the article content, shared Compose UI made sense. The content model is shared, the rendering logic is shared, and the reading experience should be consistent.

But navigation chrome is different.

iOS users have different expectations around back buttons, safe areas, toolbar spacing, glass effects, and touch behavior. Android has its own expectations too.

Trying to force the exact same chrome everywhere made the app feel less native.

So the decision was hybrid:

shared Compose for the content
shared Kotlin state and navigation
Compose chrome where it feels right
native iOS chrome where platform feel matters

Android vs iOS

This is the comparison that best explains the decision.

The article content can stay the same, but the surrounding chrome should respect the platform. On Android, the Compose version can feel natural. On iOS, native toolbar behavior, safe areas, and button styling make a visible difference.

iOS	Android

The split ended up looking roughly like this:

The bridge stays small. Compose sends simple chrome state to iOS:

ArticleChromeState(
    title = title,
    collapsed = collapsed,
    progress = readProgress
)

SwiftUI renders the native buttons and calls back into Kotlin:

Button {
    actions.save()
} label: {
    Image(systemName: "heart")
}

The important part is what is not duplicated.

There is no second article screen in Swift. No second saved-state implementation. No separate navigation model.

Native chrome is presentation. Kotlin still owns behavior.

That decision sets up the rest of the styling work: the content can share the same visual language, while each platform keeps the pieces that users expect to feel native.

The Hero Image

The article hero became the first big styling decision.

A normal image at the top of the screen made the layout feel like a feed item expanded into a detail page. That was not the feeling I wanted. The article needed to open more like a cover.

So the detail screen starts with a tall, full-width hero image, with the category and title placed over it.

The problem: real CMS images are unpredictable.

Some images are bright. Some are dark. Some are concert photos with harsh lights. Some have faces near the title area. Some have text inside the image. Some have no clear focal point.

If the title is rendered directly over that, readability breaks immediately.

The fix was to treat the image as hostile until proven otherwise:

Box {
    RemoteCoverImage(url = article.imageUrl)
    ReadabilityGradient()
    CoverTitle(article.title)
}

There is nothing clever here. It is just a gradient.

But this kind of boring styling decision is what makes dynamic content survive real-world data. The image still feels immersive, but the title remains readable.

iOS	Android

Escaping the Default Material Look

Material3 is a great foundation, but it has a visual opinion.

That opinion is useful: accessible colors, typography slots, component behavior, interaction states, dark mode support. But if you accept all of it unchanged, your app can start to look like every other Material app.

One of the first things that felt wrong was shape.

The default rounded corners made the interface feel softer than intended. The app needed sharper edges, especially around content surfaces and editorial blocks.

So the theme defines flatter shapes:

val appShapes = Shapes(
    small = sharpCorners,
    medium = sharpCorners,
    large = sharpCorners
)

The gotcha: passing shapes into MaterialTheme is not a magic wand.

Some Material components have their own defaults. Some custom components already had explicit shapes. Some buttons and cards still needed direct styling.

So the decision became:

use Material3 for structure and behavior
use the app theme as the baseline
override specific components when the product identity needs it
avoid creating a giant design system before the UI proves what it needs

That balance kept the app moving.

The Collapsing Top Bar

The top of the article should feel immersive.

The user lands on the hero image and title first, not a heavy toolbar. But after scrolling, the screen needs to become practical: back button, title, save, share, and progress.

The top bar starts transparent and becomes solid once the reader scrolls past enough of the hero:

val collapsed =
    scrollOffset > heroHeight * collapseThreshold

Then the background and title fade in:

val topBarAlpha by animateFloatAsState(
    targetValue = if (collapsed) 1f else 0f
)

This was less about animation and more about rhythm.

At the beginning, the screen behaves like a cover.

After scrolling, it behaves like a reader.

That transition made the screen feel much more intentional without adding much complexity.

Reading Progress

The reading progress indicator came from a simple observation: posts are not always short, and the body can contain very different block types.

Text, images, galleries, embeds, and related content do not create a uniform scroll experience. A small progress indicator gives users a sense of place without interrupting the article.

The implementation is intentionally approximate:

val readProgress =
    visibleContent / totalContent

It is not pixel-perfect.

But pixel-perfect progress would mean measuring dynamic content that may change size after images or embeds load. That is more complexity for very little user benefit.

The decision was to optimize for feel, not mathematical precision.

Insets: The Detail You Notice When It Fails

Once native chrome enters the picture, layout gets more delicate.

If SwiftUI renders a navigation bar, Compose needs to know how much space that bar occupies. Otherwise content can end up behind it, especially when an article has no hero image.

The fix was to measure the native chrome and send the inset back to Compose:

val topPadding =
    if (usesPlatformChrome) measuredChromeHeight
    else composeToolbarHeight

This is not the exciting part of styling.

But it is one of the most important parts of making the app feel polished. Users may not know what a safe area is, but they absolutely notice when content starts in the wrong place.

The Result

The UI started as technically correct, but generic.

After this pass, it had more identity:

full-bleed article heroes
protected title readability over unpredictable images
custom typography for editorial hierarchy
sharper Material shapes
a collapsing top bar that changes with reading context
lightweight reading progress
shared content UI
platform-aware chrome where it matters

The biggest lesson was that styling a real app is not one big theme file.

It is a series of decisions:

What should be branded?
What should stay standard?
What should be shared?
What should feel native?
What complexity is worth it?

That is where KMP became interesting for this part of the app.

It was not about proving that everything could be shared. It was about deciding what should be shared.

What's Next

In Part 5 I will cover the modularization work: splitting the project into client, data, domain, database, and UI modules, and what changed once the app stopped being one big Compose module.

Stack: Kotlin 2.3.10 · Compose Multiplatform 1.10.2 · Ktor 3.4.1 · SQLDelight 2.3.1 · Koin 4.1.1

Coming Back to Kotlin: Building a Real App with KMP Part 3 — From Raw HTML to Native Content dame algo parecido

Raul Arroyo — Wed, 25 Mar 2026 00:44:51 +0000

Part 3 — Parsing WordPress HTML and Enriching Embeds

WordPress posts arrive as raw HTML strings. A single post might contain paragraphs, headings, YouTube iframes, Spotify embeds, Instagram blockquotes, image galleries, internal post references, and ordered lists — all mixed together, none of it consistent.

You can't just dump that into a WebView and call it a day. Well, you could. But the result looks like a website inside an app, it doesn't respect your theme, dark mode breaks, fonts are wrong, and interactions feel foreign. For a magazine app where the reading experience is the whole point, that's not acceptable.

The approach: a custom HTML parser that converts raw WordPress HTML into a typed List<ContentPart> that Compose can render natively.

ContentPart — The Typed Model

The first thing to build is the sealed interface that represents every possible block of content:

sealed interface ContentPart {
    data class Text(val content: AnnotatedString) : ContentPart
    data class Heading(val content: AnnotatedString, val level: Int) : ContentPart
    data class Image(val url: String, val alt: String?) : ContentPart
    data class Gallery(val imageUrls: List<String>) : ContentPart
    data class Video(val thumbnailUrl: String, val videoUrl: String) : ContentPart
    data class Spotify(
        val embedUrl: String,
        val title: String? = null,
        val thumbnailUrl: String? = null
    ) : ContentPart
    data class InstagramPost(val url: String, val username: String?) : ContentPart
    data class InternalPost(val slug: String, val title: String?) : ContentPart
    data class UnorderedList(val items: List<AnnotatedString>) : ContentPart
    data class OrderedList(val items: List<AnnotatedString>) : ContentPart
    data class CallToAction(val text: String, val url: String) : ContentPart
    data class Divider : ContentPart
    data class Html(val content: String) : ContentPart
}

Html is the escape hatch — anything the parser doesn't recognize yet goes there. It renders as-is with a fallback composable. Over time, as new block types show up in the content, they get their own ContentPart subtype and a proper UI.

The Parser — Strategy Pattern

The parser uses a BlockHandler interface:

interface BlockHandler {
    fun canHandle(tagName: String): Boolean
    fun handle(tagName: String, content: String): List<ContentPart>
}

Each handler knows how to process one type of block. The main HtmlParser finds block-level tags with a regex, extracts the full block content (with a depth counter for nested tags), and routes to the right handler:

val blockRegex = Regex(
    "<(p|img|iframe|figure|hr|ul|ol|h[1-6])(?:\\s[^>]*)?>",
    RegexOption.IGNORE_CASE
)

The handlers are registered as a list and checked in order:

fun defaultHandlers(): List<BlockHandler> = listOf(
    DividerBlockHandler,
    ImageBlockHandler,
    TextBlockHandler,
    EmbedBlockHandler,
    CallToActionBlockHandler,
    ListBlockHandler
)

A KMP-specific gotcha

Kotlin's Regex on KMP doesn't support DOT_MATCHES_ALL as a RegexOption. On JVM you can use (?s) in the pattern or Pattern.DOTALL. In KMP the portable fix is replacing . with [\s\S] in any regex that needs to match across newlines. Worth knowing before you spend an hour wondering why your regex works in unit tests on JVM but silently fails on iOS.

The Tricky Cases

Most block types are straightforward — a <p> becomes ContentPart.Text, an <img> becomes ContentPart.Image, an <hr> becomes ContentPart.Divider. The interesting ones are the embeds.

YouTube — lazy loading

WordPress with the custom theme uses lazy loading on iframes. The actual URL isn't in src — it's in data-lazy-src:

<iframe src="about:blank" 
        data-lazy-src="https://www.youtube.com/embed/{videoId}">

Any image validation logic needs to filter out about:blank URLs or you'll end up with broken thumbnails. The EmbedBlockHandler checks data-lazy-src first, then falls back to src.

For YouTube we don't embed the player — we show a thumbnail with a play button that opens the YouTube app via a confirmation dialog. Clean, fast, no WebView required.

Spotify — oEmbed enrichment

Spotify embeds arrive as an iframe with just the embed URL. Not very exciting to look at as a card. But Spotify has a public oEmbed endpoint that returns the track/album/playlist title and thumbnail — no authentication required:

GET https://open.spotify.com/oembed?url={spotifyUrl}

The SpotifyContentPart composable fetches this data with a LaunchedEffect and shows a skeleton while it loads. The result is a card with the actual album art and track title — something worth tapping.

The decision of where to make this request was interesting. It could live in the ViewModel, pre-fetched for all Spotify parts before rendering. But that means waiting for N requests before showing anything. Instead, each SpotifyContentPart fetches its own data independently using koinInject<SpotifyService>() directly in the composable. The cards load progressively as you scroll.

Instagram — blockquote detection

Instagram blocks thumbnail URLs from third-party apps — or so I thought.
Instagram actually has a semi-public thumbnail URL pattern:

https://www.instagram.com/p/{shortcode}/media/?size=l

We extract the shortcode from the embed URL and attempt to load it with SubcomposeAsyncImage. If Instagram blocks the request (which it does inconsistently), the error slot shows a fallback placeholder with the Instagram gradient branding. If it loads — and it does load sometimes — you get the actual post image with the aspect ratio adjusted dynamically using onSuccess to read the painter's intrinsicSize.

onSuccess = { state ->
    val width = state.painter.intrinsicSize.width
    val height = state.painter.intrinsicSize.height
    if (width > 0 && height > 0) {
        imageAspectRatio = width / height
    }
}

The container height starts at 220.dp as a fallback and adjusts to the real aspect ratio once the image loads. Not perfect, but better than a static placeholder.

Internal post references

The magazine embeds links to related articles within post content using a custom WordPress block class: wp-block-embed-my-wp-site. The EmbedBlockHandler detects this and extracts the slug from the href:

if (content.contains("wp-block-embed-my-wp-site")) {
    val slug = extractSiteSlug(content) ?: return emptyList()
    val title = extractEmbedTitle(content)
    return listOf(ContentPart.InternalPost(slug = slug, title = title))
}

At render time, InternalPostContentPart resolves the slug to a post ID via the repository — first checking the local DB, then the API if not cached — and navigates to that post on tap using the AppNavigator singleton from Part 2.

Image Grouping

WordPress content frequently includes multiple consecutive images — a photo series from a concert, an event gallery. Rendering them one-by-one as full-width images takes forever to scroll through.

After parsing, the ViewModel runs a post-processing step that groups three or more consecutive ContentPart.Image items into a ContentPart.Gallery:

private fun groupConsecutiveImages(
    parts: List<ContentPart>,
    minCount: Int = 3
): List<ContentPart> {
    val result = mutableListOf<ContentPart>()
    var i = 0
    while (i < parts.size) {
        val part = parts[i]
        if (part is ContentPart.Image) {
            var j = i
            while (j < parts.size && parts[j] is ContentPart.Image) j++
            val count = j - i
            if (count >= minCount) {
                val images = parts.subList(i, j)
                    .filterIsInstance<ContentPart.Image>()
                    .mapNotNull { it.url }
                result.add(ContentPart.Gallery(imageUrls = images))
                i = j
            } else {
                repeat(count) { result.add(parts[i + it]) }
                i += count
            }
        } else {
            result.add(part)
            i++
        }
    }
    return result
}

The GalleryContentPart composable renders these with different layouts depending on count — 3 images get a "hero + two below" layout, 4 get a "large left + three stacked right" layout, and 5+ get a mosaic with a +N counter on the last tile. Tapping any image or the counter opens a full-screen gallery viewer with pinch-to-zoom and swipe navigation.

The Result

After parsing, a typical post produces something like:

ContentPart.Text("La cantante belga Angèle ha regresado...")
ContentPart.InstagramPost(url = "https://www.instagram.com/p/DVTyrbVCPXe/")
ContentPart.Text("El video musical, creado con (LA)HORDE...")
ContentPart.Video(thumbnailUrl = "...", videoUrl = "...")

Each type gets its own composable renderer. The LazyColumn in PostDetailContent iterates over the list and dispatches to the right component. No WebViews, no HTML rendering engines, no platform-specific workarounds — just Compose all the way down.

What's Next

In Part 4 we cover the UI layer — the PostHero component with the collapsible top bar, custom theming with Anton and Space Grotesk fonts, platform-specific transitions, and the Material3 shapes gotcha that will catch you off guard if you expect the theme to propagate automatically.

Stack: Kotlin 2.3.10 · Compose Multiplatform 1.10.2 · Ktor 3.4.1 · SQLDelight 2.3.1 · Koin 4.1.1

Building the Architecture in KMP: Data Flow, MVI, and Hard Decisions

Raul Arroyo — Fri, 20 Mar 2026 01:07:12 +0000

Part 2 — Architecture, MVI, and the Offline-First Decision

In Part 1 I wrote about the stack and the first walls — library compatibility, Navigation3 bugs, Coil 3 differences. Now we get into the decisions that shaped how the whole app is structured.

Fair warning: this post has opinions. Architecture is one of those topics where everyone has a preferred approach, and mine was shaped by years of Android development followed by three years of Flutter. Your mileage may vary.

The Overall Structure

I'm following a simplified Clean Architecture. Not strict by the book, but principled enough that I can navigate the codebase without thinking too hard about where things live:

data/
  remote/
    model/       ← DTOs — what the API returns
    service/     ← Ktor clients (WordPress, Spotify)
    mapper/      ← DTO → Entity, Entity → Domain
  repository/    ← PostRepository — single source of truth
domain/
  model/         ← PostDetail, PostSummary, ContentPart
ui/
  screens/       ← ViewModels + Composables
  components/    ← Shared UI components
  navigation/    ← Navigation3 setup
  theme/         ← Colors, typography, shapes

The key constraint I set for myself: the UI layer never talks to the network directly. Everything goes through the repository, and the repository always reads from the database. The network is just a way to keep the database up to date.

Two Domain Models Instead of One

Early on I had a single Post model that tried to serve both the list view and the detail view. That doesn't scale well. The list needs almost nothing — title, excerpt, image, category. The detail needs author info, content, tags, related posts. Cramming those into one model means either always fetching too much or constantly dealing with nullable fields that "don't apply here."

I split them:

// For lists — lightweight, fast to load from DB
data class PostSummary(
    val id: Int,
    val title: String,
    val excerpt: String,
    val imageUrl: String?,
    val categoryName: String?,
    val isSaved: Boolean
)

// For the detail screen — everything we need
data class PostDetail(
    val id: Int,
    val title: String,
    val content: String,
    val imageUrl: String?,
    val categoryName: String?,
    val categoryId: Int?,
    val author: Author?,
    val date: String?,
    val slug: String?,
    val tags: List<String>,
    val tagIds: List<Int>,
    val isSaved: Boolean
)

One thing worth noting: PostDetail has both tags (the display names, like "Vive Latino") and tagIds (the WordPress IDs, like [38763, 1032]). The names come from the API's embedded _embedded.wp:term data. The IDs come from the top-level tags array. We need both — names for display, IDs for querying related posts.

Also notice that PostDetail has content as a raw string, but we never show it directly. It gets parsed into List<ContentPart> in the ViewModel before reaching the UI. More on the parser in Part 3.

The Data Flow

WordPress API (Ktor)
    ↓
WordpressPostDto
    ↓  toEntity()
PostEntity (SQLDelight DB)
    ↓  toPostSummary() / toPostDetail()
Domain Model
    ↓
ViewModel → UI

Every piece of data touches the database. The API is the source of new data. The database is the source of truth for the UI. This gives you offline support for free — if the API fails, you still render cached content.

The mapper layer is split into two files: WordpressPostDtoMapper.kt for DTO → Entity (data layer concern), and PostEntityMapper.kt for Entity → Domain (connecting the data layer to the domain). Each file has one job.

Offline-First Sync

The WordPress REST API has a modified_after parameter that returns only posts modified since a given timestamp. Combined with SQLDelight's ability to query MAX(lastModified), incremental sync becomes straightforward:

suspend fun syncPosts() = withContext(Dispatchers.IO) {
    val latestModified = queries.getLatestModifiedDate().executeAsOneOrNull()?.MAX
    val latestDate = queries.getLatestDate().executeAsOneOrNull()?.MAX

    if (latestModified == null || latestDate == null) {
        // Empty DB — initial download
        val posts = api.getPosts(perPage = 50)
        savePosts(posts)
    } else {
        // Incremental — only what changed since last sync
        val newPosts = api.getPosts(
            after = latestDate,
            modifiedAfter = latestModified
        )
        if (newPosts.isNotEmpty()) savePosts(newPosts)
    }
}

First launch: 50 posts. Every subsequent launch: only what changed. Fast, bandwidth-efficient, and the UI always has something to show even offline.

One gotcha: WordPress's modified_after parameter is not widely documented and the naming is slightly inconsistent across WordPress versions. Test it against your actual endpoint before trusting it.

MVI for Screen State

I've always used MVVM. It's what the Android documentation pushes, it's what most tutorials use, and honestly it works fine for most apps. But MVI has been getting a lot of attention lately — and for good reason. The unidirectional data flow, the explicit state modeling, the clear separation between what the user does and what the UI shows — it all clicks when you see it in action.

This project felt like the right place to try it properly. Not because MVVM would have failed here, but because I wanted to understand MVI from the inside, not just from blog posts.

The pattern maps cleanly to KMP ViewModels.

Each screen has three things:

Intent — what the user can do:

sealed interface PostDetailIntent {
    data class LoadPost(val postId: Int) : PostDetailIntent
    data class ToggleSaved(val postId: Int, val current: Boolean) : PostDetailIntent
    data class OpenGallery(val imageUrls: List<String>, val initialIndex: Int) : PostDetailIntent
}

State — what the UI renders:

sealed interface PostDetailState {
    data object Loading : PostDetailState
    data class Success(
        val postDetail: PostDetail,
        val parts: List<ContentPart>,
        val imageUrls: List<String>,
        val isSaved: Boolean,
        val relatedPosts: List<PostSummary> = emptyList()
    ) : PostDetailState
    data class Error(val error: Error) : PostDetailState
}

Effect — one-time events that don't belong in state:

sealed interface PostDetailEffect {
    data class ShowError(val error: Error) : PostDetailEffect
}

The ViewModel exposes a StateFlow<PostDetailState> for state and a Channel<PostDetailEffect> for effects. Why Channel and not SharedFlow for effects? Because SharedFlow can drop events if the collector isn't active at the moment of emission. Channel buffers them. For a snackbar that should appear exactly once, that matters.

class PostDetailViewModel(
    private val repository: PostRepository,
    private val htmlParser: HtmlParser,
    private val navigator: AppNavigator
) : ViewModel() {

    private val _state = MutableStateFlow<PostDetailState>(PostDetailState.Loading)
    val state: StateFlow<PostDetailState> = _state.asStateFlow()

    private val _effects = Channel<PostDetailEffect>(Channel.BUFFERED)
    val effects = _effects.receiveAsFlow()

    fun onIntent(intent: PostDetailIntent) {
        when (intent) {
            is PostDetailIntent.LoadPost -> loadPost(intent.postId)
            is PostDetailIntent.ToggleSaved -> toggleSaved(intent.postId, intent.current)
            is PostDetailIntent.OpenGallery -> navigator.navigateToGallery(
                intent.imageUrls, intent.initialIndex
            )
        }
    }
}

One Kotlin-specific gotcha worth mentioning: state comes from collectAsState() in Compose, which returns a delegated property. Smart casts don't work on delegated properties. This means you can't write if (state is PostDetailState.Success) { state.postDetail } — the compiler won't smart-cast state inside the branch. The fix is a local variable:

val currentState = state  // local variable — smart cast works here
when (currentState) {
    is PostDetailState.Success -> { currentState.postDetail }
    // ...
}

A small thing that can cost 20 minutes of confusion if you've never hit it before.

Navigation as a Singleton

One non-obvious decision: AppNavigator is a singleton in Koin. Not a scoped dependency, not passed through the composable tree — a single instance that any ViewModel or Composable can inject.

class AppNavigator {
    private var backStack: MutableList<NavKey>? = null

    fun attach(backStack: MutableList<NavKey>) {
        this.backStack = backStack
    }

    fun navigateToPost(postId: Int) {
        backStack?.add(AppRoute.PostDetail(postId))
    }

    fun navigateToGallery(imageUrls: List<String>, initialIndex: Int) {
        val json = Json.encodeToString(imageUrls)
        backStack?.add(AppRoute.ImageGallery(json, initialIndex))
    }
}

This means a component like InternalPostContentPart — which renders a "Read also" card inside a post's content — can navigate to another post without needing to bubble a callback up through five layers of composables. It just injects the navigator directly:

@Composable
fun InternalPostContentPart(part: ContentPart.InternalPost) {
    val repository = koinInject<PostRepository>()
    val navigator = koinInject<AppNavigator>()
    // ...
    Card(onClick = { postId?.let { navigator.navigateToPost(it) } }) { ... }
}

Whether this is "clean" is debatable. But it's pragmatic, and in a KMP project where threading the callback through shared composables gets complicated, the singleton approach saves real complexity.

What's Next

In Part 3 we get into the most technically interesting part of the project: the custom HTML parser that turns raw WordPress content into typed ContentPart objects that Compose can render. WordPress posts contain a mix of paragraphs, headings, YouTube embeds, Spotify iframes, Instagram blockquotes, image galleries, and internal post references — none of it consistent, all of it needing different UI treatment.

Stack: Kotlin 2.3.10 · Compose Multiplatform 1.10.2 · Ktor 3.4.1 · SQLDelight 2.3.1 · Koin 4.1.1

I Came Back to Kotlin for KMP — Here’s What Broke First

Raul Arroyo — Thu, 19 Mar 2026 05:53:31 +0000

Part 1 — Why KMP, Why Now, and the First Walls

I've been building mobile apps since 2011. Java with Eclipse, back when ADT was the only game in town and a simple ListView took half a day to get right. Then Kotlin came along and everything got better. Then Flutter came along and I spent the last three years living in Dart land — and honestly, it was great. But something kept pulling me back.

Late last week I decided to come back to Kotlin. Not for a side project or a tutorial — for something real. I collaborate with a music magazine that had just updated their WordPress backend and refreshed their theme. A working REST API, fresh content, a product I actually care about. It was the perfect excuse to dive into Kotlin Multiplatform.

I'd been watching KMP from a distance for years. It always seemed almost ready. Then in late 2023 it went stable, the tooling caught up, and the library ecosystem started filling in. The timing finally felt right.

This is the first post in a series documenting what I'm building and everything I'm learning along the way — the good decisions, the bad ones, and the things that just flat out broke.

The Pitch

The project is a reader app backed by a WordPress REST API — posts, authors, categories, tags, embeds. Nothing exotic on the backend side. The interesting part is entirely in the client.

The bet I'm making: Compose Multiplatform for the entire UI, not just shared business logic. One codebase for every screen on Android and iOS. That's a significant commitment compared to the typical "shared ViewModel, native UI" approach — but coming from Flutter, where you do exactly this, it feels natural. And for someone working alone, eliminating the context switch between two UI stacks is worth a lot.

Here's the full stack:

[versions]
kotlin = "2.3.10"
compose-multiplatform = "1.10.2"
ktor = "3.4.1"
sqldelight = "2.3.1"
koin = "4.1.1"
coil = "3.4.0"
navigation3 = "1.0.0-alpha06"

Each of these deserves its own explanation, because nothing here was obvious.

Why Not Room?

The first real decision was local storage. Coming from Android, Room is the obvious choice — I've used it for years. But Room's KMP support is still marked experimental, and on iOS in particular it can be fragile.

I went with SQLDelight instead. It's been KMP-native from the start. You write plain SQL, it generates fully type-safe Kotlin query functions and a data class for each table. Any mismatch between your schema and your code is a compile error — not a runtime crash at 2am.

The tradeoff is that you lose the annotation-based convenience of Room. But the result is surprisingly clean:

CREATE TABLE postEntity (
    id INTEGER NOT NULL PRIMARY KEY,
    title TEXT NOT NULL,
    excerpt TEXT NOT NULL,
    content TEXT NOT NULL,
    imageUrl TEXT,
    categoryName TEXT,
    categoryId INTEGER,
    slug TEXT,
    tags TEXT,
    isSaved INTEGER AS kotlin.Boolean NOT NULL DEFAULT 0,
    lastModified TEXT NOT NULL
);

selectPostById:
SELECT * FROM postEntity WHERE id = ?;

selectPostBySlug:
SELECT * FROM postEntity WHERE slug = ?;

SQLDelight generates a PostEntity data class and a selectPostById(id: Long): Query<PostEntity> function from this. You call it like normal Kotlin. Adding a column means updating the SQL — and the compiler tells you everywhere that needs to change.

Navigation3 — Alpha Is Alpha

For navigation I went with Navigation3, Jetbrains' new navigation library for Compose Multiplatform. At 1.0.0-alpha06 it's still rough around the edges.

The most painful bug I hit early: double-tapping the back button crashes the app. The backstack empties completely and Navigation3 throws trying to display nothing. The fix ended up being a simple guard:

val isNavigating = remember { mutableStateOf(false) }

fun safeBack() {
    if (!isNavigating.value && backStack.size > 1) {
        isNavigating.value = true
        backStack.removeLastOrNull()
        isNavigating.value = false
    }
}

Not elegant. But it works, and until the library stabilizes it's the pragmatic solution.

Coil, Koin, and the Details

Coil 3 introduced LocalPlatformContext for KMP — replacing Android's LocalContext. If you copy-paste Coil 2 code into a KMP project, images just don't load on iOS with no clear error. The fix is one line, but finding it costs time:

// This is how you do it in KMP — not LocalContext.current
ImageRequest.Builder(LocalPlatformContext.current)
    .data(url)
    .crossfade(true)
    .build()

Koin 4 initializes differently per platform. On Android you call startKoin in Application.onCreate(). On iOS you expose an initKoin() function and call it from Swift before the first Compose frame. The gotcha that bit me: KoinApplicationAlreadyStartedException. If Koin gets initialized twice — easy to do when juggling Android Application classes and iOS entry points — the app crashes immediately on launch with a confusing error message.

The `libs.versions.toml` Tax

This one isn't unique to KMP but it cost me real time. The libs.versions.toml file has a specific structure — [versions], [libraries], [plugins] — and Gradle's configuration cache is unforgiving about mistakes. I had library declarations mixed into the [versions] block and the error message pointed to something completely unrelated. The fix was formatting. The lesson was to read the TOML spec carefully upfront.

Coming from Flutter

One thing I didn't expect: the mental model shift from Flutter to Compose Multiplatform is smaller than I thought. Both are declarative UI frameworks with a component tree and reactive state. The Dart-to-Kotlin switch is almost a relief — I'm back in a language I know deeply, with IDE support that actually works.

What's different is the platform integration story. Flutter abstracts away the platform almost completely. KMP lets you go as native as you want, which is both powerful and occasionally annoying. Platform channels become expect/actual declarations. The splash screen, share functionality, and back gesture all need platform-specific handling that Flutter would paper over for you.

Whether that's a feature or a bug depends on what you're building. For an app that needs to feel native on both platforms, it's a feature.

What's Next

In Part 2 we'll get into the architecture — why we split posts into two domain models (PostSummary and PostDetail), how the data flows from the WordPress API through SQLDelight to the UI, and how MVI fits into a KMP ViewModel.

Stack: Kotlin 2.3.10 · Compose Multiplatform 1.10.2 · Ktor 3.4.1 · SQLDelight 2.3.1 · Koin 4.1.1 · Coil 3.4.0 · Navigation3 1.0.0-alpha06

Thoughts?

If you're exploring Kotlin Multiplatform right now, I'm curious — what’s been your biggest friction point so far?

Have you tried going full Compose Multiplatform for UI, or are you sticking to shared logic only?

Drop a comment, I'd love to compare notes (and maybe avoid a few future headaches).

Don't Lose the Spark: Keeping Your Coding Passion Alive in a Leadership Role

Raul Arroyo — Fri, 05 Apr 2024 06:15:20 +0000

Remember the thrill of seeing your first line of code come to life? That feeling of creation and problem-solving is what hooked me on software development for over 10 years. During all this time, I have had the opportunity to work on a huge ammount of projects and bussinness, for both small start-ups and big companies in various industries and using different technologies. Along the path, I have had the pleasure of meeting amazing people, learning a lot, and tackling obstacles that have contributed to my personal and professional path.

Enthusiasm and discovery.

My first projects involved building videogames from scratch, interact with motion sensors, create lots of eyecandy pages. Each line of code I wrote unlocked new possibilities, and the excitement of seeing it all come together was incredible. Every project was an escapade to learn new things as well as discover unexplored technology. It was exhilarating for me to be part of competent teams working alongside other developers towards making products for people's pleasure or use.

I remember how exciting it felt when what I built started being useful and users were happy about it. It is so satisfying realizing that my code actually matters to individuals' lives. This makes your work feel like second nature since you are actively participating in something bigger.

However, as time went by routine set in. Projects became more monotonous while tasks became repetitive. The learning curve flattened out and the initial enthusiasm wilted away. The sense of fulfilment I previously experienced upon finishing a project waned eventually giving way to emptiness and desolation.

The aspiration of the eternal developer.

From the very start, my vision was clear: to embody the essence of an eternal developer. To exist as a consistent entity, engrossed in a continual stream of code, accomplishing tasks in succession, without pause.

I envisioned myself laboring ceaselessly, mastering the complexities of code and resolving issues with precise accuracy. My objective was to evolve into a development powerhouse, adept at transforming any concept into a tangible manifestation. Nevertheless, the harsh reality soon became apparent.

A new challenge arises: managing groups of developers.

As my skills grew, so did my desire to contribute in a different way. Leading development teams became the next frontier for me, but it wasn't without its hurdles.

This transition, though exciting, can be a minefield for those who are unprepared, like me. Many talented programmers struggle initially in this new role. The main reason is that technical skills, while essential, are not enough to lead a team. A completely new set of habilities is required, a shift in focus that many are not ready to make.

What makes leading development teams so challenging?

Motivating a team with diverse personalities was initially tough. I learned to tailor my communication style and celebrate individual strengths

Managing different personalities is crucial for effective leadership.
Understanding each developer's unique work style, motivations, and preferences is essential for bringing out the best in each team member.
Clear and effective communication is vital for the success of any team. A leader must be able to clearly communicate goals, inspire the team, and address conflicts efficiently.
Delegating responsibilities is a key aspect of leadership. A leader cannot handle everything on their own and must learn to delegate tasks effectively, while trusting their team to complete them.
Motivating and inspiring the team, especially during challenging times, is a crucial skill for a leader. They must be able to keep their team motivated and engaged to achieve success.

Becoming the leader of development teams is a major accomplishment. Yet, this promotion comes with a harsh truth: you start to drift away from hands-on coding. The passion you once had for coding begins to fade, causing feelings of disappointment and a lack of drive.

How do you keep your love for software development alive

The pull of hands-on coding can be strong, even when you're leading a development team. Here are some strategies I used to keep myself connected to the code and the joy of creation:

Discover fresh methods to engage with coding

Engage in open source initiatives: Allocate time to contribute to projects that pique your interest. This will keep you aware of the newest technologies and techniques, and provide the chance to collaborate with other skilled developers.
Guide fellow developers: Share your expertise with novice programmers. This serves as a fantastic method to maintain your connection to coding and assist others in advancing their careers.
Stay on top with current trends: Stay informed by reading software development blogs, articles, and books. Attend industry conferences and events. Keeping up with the latest technologies will keep you motivated and on top.
Carve Out "Scratch Pad" Time: Scheduling dedicated time for personal coding projects, even if it was just a few hours a week, proved to be crucial. These projects allowed me to experiment with new libraries, frameworks, and coding paradigms, keeping my coding skills sharp and reigniting the spark of creative problem-solving.

Understand the importance of your role

Remember your role as a leader: it plays a crucial part in the team's success. Your choices and leadership style have a significant influence on the quality of work produced, the team's efficiency, and the satisfaction of customers.
Celebrate the team's achievements: When the team accomplishes its goals, take the time to acknowledge and celebrate the effort put in by each individual. This not only boosts morale but also keeps the team driven and engaged.
Keep your focus on the overarching goal: Don't lose sight of the primary objective in software development: creating products that are not only functional but also improve the lives of those who use them.

Achieving a balance:

One must strike a harmonious balance between leadership duties and coding enthusiasm. Seek chances to remain engaged in software development, even if it entails a reduced level of involvement.
Do not hesitate to assign tasks to others. You are not obligated to handle everything independently. Have confidence in your team and allot responsibilities to individuals, trust that they have the necessary skills and expertise.
Prioritize your mental and physical well-being. Stress and fatigue often afflict team leaders. Ensure you take periodic breaks, engage in physical activity and get enough rest.

Don't let your love for software development fade as you transition into a leadership role. There are plenty of ways to stay involved with coding, even if you're not actively writing lines of code every single day. As a leader, your actions have a big influence on the team's achievements.

Aim to be the kind of leader you've always admired
All the while balancing your leadership duties and your coding passion.

Becoming a software developer is not a straightforward process. It involves exciting findings, the joy of building something, and the expected hurdles of progress. As you progress in your career, keep in mind that the same initial excitement that got you into coding is still present.

Being a leader in software development allows you to use your technical skills to support and motivate others. It's all about creating a cooperative space where imagination flourishes, and where your direction helps a team accomplish extraordinary feats.

Keep the passion for coding alive! Being a leader is very fulfilling. Balancing between management and creativity is a valuable journey. Embrace new challenges, fuel your coding spirit with the mentioned strategies, and most importantly, lead with the same excitement for innovation that initially attracted you to coding.

The world of software development is always changing, and your leadership will influence the future. As you motivate others, don't forget to inspire yourself as well. The journey never stops!

DEV Community: Raul Arroyo

The UI Details That Make It Feel Native

Part 4 - The UI Layer, Native Chrome, and the Details That Make It Feel Like an App

The Problem With a Technically Correct UI

Typography as Branding

The Platform Problem

Android vs iOS

The Hero Image

Escaping the Default Material Look

The Collapsing Top Bar

Reading Progress

Insets: The Detail You Notice When It Fails

The Result

What's Next

Coming Back to Kotlin: Building a Real App with KMP Part 3 — From Raw HTML to Native Content dame algo parecido

Part 3 — Parsing WordPress HTML and Enriching Embeds

ContentPart — The Typed Model

The Parser — Strategy Pattern

A KMP-specific gotcha

The Tricky Cases

YouTube — lazy loading

Spotify — oEmbed enrichment

Instagram — blockquote detection

Internal post references

Image Grouping

The Result

What's Next

Building the Architecture in KMP: Data Flow, MVI, and Hard Decisions

Part 2 — Architecture, MVI, and the Offline-First Decision

The Overall Structure

Two Domain Models Instead of One

The Data Flow

Offline-First Sync

MVI for Screen State

Navigation as a Singleton

What's Next

I Came Back to Kotlin for KMP — Here’s What Broke First

Part 1 — Why KMP, Why Now, and the First Walls

The Pitch

Why Not Room?

Navigation3 — Alpha Is Alpha

Coil, Koin, and the Details

The libs.versions.toml Tax

Coming from Flutter

What's Next

Thoughts?

Don't Lose the Spark: Keeping Your Coding Passion Alive in a Leadership Role

Enthusiasm and discovery.

The aspiration of the eternal developer.

A new challenge arises: managing groups of developers.

How do you keep your love for software development alive

Discover fresh methods to engage with coding

Understand the importance of your role

Achieving a balance:

The `libs.versions.toml` Tax