GM Friends. This is JetpackCompose.app’s Dispatch, sliding into your inbox with that "just discovered a compiler optimization that shaved 200ms off my build time" energy ⚡

This issues took longer than usual, but there was a good reason for that delay because there were big changes on my end……

📣 Personal Update

After six incredible years, I’ve closed the curtains on my chapter at Airbnb.

My time here has been nothing short of transformative, both professionally and personally. I experienced a pandemic while working at a travel company, witnessed a wildly successful IPO, open-sourced a meaningful project that was loved by the community, had 2 kids, landed on a Google I/O keynote, transitioned roles, lost both my grandparents, gave countless tech talks, and made lifelong friends along the way. It’s been a rollercoaster and completely action-packed — and I’ve felt an incredible symmetry between the energy I poured in and what I got back.

My role has been particularly special: operating at the intersection of Code, Design, and AI has been a dream come true. I’ve had the privilege of introducing and evangelizing technologies that directly shaped how Airbnb engineers build — from championing Jetpack Compose to introducing Generative AI inside everyday developer workflows.

The past couple of years stand out the most — helping lay the foundation for what it means to be an AI-first engineering organization. We were early, but we were right. Anyone working in this space knows how transformative the last few years have been, and I’m proud to have been right in the middle of it. It truly was a fantastic setup — what some might call “a dream job.”

There’s so much more to share, including what interviewing was like after 6 years, how much the process itself had changed, how I approached settling on my next gig, etc. Honestly, this change is truly bonkers but if you are ambitious and have a high tolerance, there’s never been a better time. Anyway, I hope to touch on the specifics in future editions of this newsletter.

Until then, it’s been real, Airfam ❤️

You're building a composable that should be completely inert—no touches, no focus, no accessibility interactions possible. Nothing. So here’s the code you come up with:

@Composable
fun InertContent() {
    Box(
        Modifier
            .pointerInput(Unit) {
                awaitEachGesture {
                  val event = 
                    awaitPointerEvent(PointerEventPass.Initial)
                  event.changes.fastForEach { it.consume() }
                }
             }
             .clearAndSetSemantics { 
                 this.hideFromAccessibility()
             }
             .focusProperties { this.canFocus = false }
    ) {
        Text("I should be completely inert")
    }
}

However, you notice that you are still able to focus elements using the keyboard. Why is that 🤔

See the answer in a section below ⬇️

😆 Dev Delight

🤔 Interesting tid-bits

Early Android's Wild West Days

Ever wonder why some Android APIs feel... quirky? Turns out, early Android development was basically the software engineering equivalent of jazz improvisation. According to Chet Haase's Androids book, Google—primarily a search and ad company at the time—had zero experience building operating systems or consumer electronics. Their usual playbook of "hire brilliant people from top universities and find projects for them" completely fell apart when faced with OS development's specialized demands.

The solution? Hire people who actually knew what they were doing. Android was mostly written by folks from Be OS, Danger, and Palm—companies that lived and breathed operating systems. But here's where it gets wild: the leaders told engineers what to build, not how to build it. Each engineer was free to implement however they saw fit.

The result? The entire View UI system—you know, the foundation of Android UI for over a decade—was written by a single developer in a single day. And since there was no alternative, everyone just... went with it.

This explains so much about Android's early architectural decisions. When you're moving that fast with that much freedom, you get innovation, sure, but you also get technical debt that echoes through the ages. It's a reminder that even the most successful platforms started with duct tape and determination.

If you work with Android for a living, I recommend giving this book a read if you haven’t already!

Swift Crashes the Android Party

In a plot twist nobody saw coming, the Swift programming language just announced official SDK support for Android. Yes, you read that right—Apple's darling language is now targeting the Android platform 🤯 I’m not sure how Steve Jobs would feels about that. This is definitely not a sentence I imagined writing this year but here we are!

The Swift SDK for Android includes the swift-java project, which automatically generates safe, performant bindings between Swift and Java code. This means you can now write your business logic in Swift and share it across iOS, Android, and potentially other platforms. Over 25% of packages in the Swift Package Index already build for Android, which is honestly impressive for a preview release.

If you're building cross-platform apps and want to leverage existing Swift libraries or expertise, this opens new doors. Although I have some reservations about whether these doors should even exist in the first place. Wouldn’t it be nice if we all got along and made progress on a single cross-platform framework rather than building bridges from two different ends. Oh well…..a man can dream…..

Kotlin Wants Your Feedback on Multiplatform

Speaking of cross-platform development, the Kotlin team is running their yearly Kotlin Multiplatform survey to understand how the ecosystem is evolving. If you've been experimenting with KMP, have strong opinions about what's missing, or just want to influence where JetBrains focuses their efforts next, this is your chance to be heard.

Takes about 10 minutes, and you'll be helping shape the future of Kotlin Multiplatform. Plus, you get to vent about that one thing that's been annoying you. Win-win.

🕵🏻‍♂️ Insider Insight

If you’ve ever shipped an app to an older Android device and noticed it thinks daylight saving still exists in Fiji, congrats — you’ve met the timezone database problem. I recently stumbled on this due to an active discussion that both Jesse Wilson and Jake Wharton were involved in. When these two guys are giving something attention, you drop everything you are doing and pay attention.

So what even is the problem that this discussion was trying to solve?

Android devices use the IANA tzdata file buried deep inside /system/usr/share/zoneinfo/. Meaning the only way it gets updated is through a full OS update. So when a country like Fiji suddenly cancels daylight saving time (again), those devices are forever stuck thinking it still exists.

Starting with Android 10, Google finally fixed this with Project Mainline, shipping timezone data via Play System Updates (no full OTA required). Wouldn’t this already solve the problem? Why is there an active discussion then?

The kotlinx-datetime library is a platform-agnostic Kotlin library (JVM + Native + JS + Android) for date/time handling. Its concerns include:

• Making sure the library has access to correct tzdata at runtime (for whichever platform it runs).

• Handling cases where the host OS’s tzdata is outdated (old Android, custom embedded system, etc).

• Deciding how to retrieve, embed, or fallback to tzdata in those contexts.

• Ensuring consistent behavior across platforms, which may not have Project Mainline-like update mechanisms.

So even though Android devices using recent OS might get updated tz data via Mainline, this doesn’t guarantee that every platform/environment where kotlinx-datetime runs has correct or current rules — hence the discussion.

@Composable
fun InertContent() {
    Box(
        Modifier
            .pointerInput(Unit) {
                awaitEachGesture {
                  val event = 
                    awaitPointerEvent(PointerEventPass.Initial)
                  event.changes.fastForEach { it.consume() }
                }
             }
             .clearAndSetSemantics { 
                 this.hideFromAccessibility()
             }
             .focusProperties { this.canFocus = false }
    ) {
        Text("I should be completely inert")
    }
}

When you look at the code, you will realize that even for the touch events, we end up consuming them rather than ignoring them.

Moreover, here’s a use case that star subscriber Saket Narayan had:

Turns out, Compose doesn’t allow you to do this today!!! This discovery led to Saket reporting this as a feature request. Hit that +1 if you’d like to see this supported!

🦄 How you can help?

If you enjoy reading this newsletter and would like to keep Dispatch free, here are two quick ways to help:

👉🏻 Chip in via Github Sponsors. If your company offers an education budget, contributing a “coffee” to keep this newsletter going will certainly qualify. You’ll get an instant receipt for reimbursement, and I’ll keep Dispatch running ☕️

👉🏻Spread the word. Tweet, Bluesky, toot, Slack, or carrier‑pigeon this issue to someone who loves Android. Each new subscriber pushes Dispatch closer to sustainability.

👂 Let me hear it!

What’d you think of this email? Tap your choice below and lemme hear it 👇

🚀🚀🚀🚀🚀 AMAZING-LOVED IT!

🚀🚀🚀 PRETTY GOOD!

🚀 MEH - NOT GREAT

On that note, here’s hoping that your bugs are minor and your compilations are error free,

—