I was building a Kotlin Multiplatform SDK that needed to support four analytics providers—Google Analytics, Facebook, AppsFlyer, and Amplitude. Each customer typically only uses one or two, never all four.

The Challenge: How to let developers pick and choose which analytics integrations to include, without forcing them to bundle everything?

The solution seemed obvious: build separate implementations for each analytics provider and let developers include only what they need.

On Android, this is straightforward—create separate Gradle modules, and developers pick which ones to add. Done in 30 seconds.

dependencies { implementation("com.example:shared:1.2.3") implementation("com.example:analytics-google:1.2.3") // ✓ Just this } 

But on iOS? I had no idea where to start.

So I had two terrible options (or maybe more, but I could only think of these...

Recently, I got curious about HTML parsing—you know, that thing browsers do billions of times a day that we all take completely for granted.

How hard could it be? I thought, like every programmer before me who has wandered into this particular circle of hell.

Turns out: very hard. HTML parsing isn’t just about recognizing <div> tags and calling it a day. It’s a complex mess of state machines, error recovery, and edge cases with countless bizarre scenarios.

The good news? HTML parsing is a solved problem. It’s been thoroughly documented in standards like the WHATWG and W3C spec. I went with the WHATWG HTML Living Standard¹ because it’s what all modern browsers actually implement, and it’s actively maintained. The WHATWG spec defines a parsing algorithm so intricate that implementing it correctly is...

There isn’t much literature about the internal workings of Compose, the amazing declarative framework which allows you to build not only Android apps but also cross-platform applications. In this article, I would like to explain the core concepts of how Compose works internally. This is going to be a very theoretical exploration, but I’ve created flowcharts to help build a mental model. I’ve skimmed over some parts that I thought weren’t crucial for understanding Compose’s internal mechanics.

Background

Compose was heavily inspired by React and was initially built as an extension of the old Android view system, where you can replicate the XML structure in Kotlin. However, while it initially worked using the old view system, JetBrains didn’t want to integrate that capability into the Kotlin language. This led Google to develop an alternative using function syntax.