The Future of Android, Kotlin, and Everything - droidcon New York 2024

The tenth-anniversary keynote at droidcon New York. It starts as a look back at running the first three NYC conferences, then argues that native development didn’t die — it consolidated — and that Compose Multiplatform is close enough now to be argued as a default rather than an option.

Chapter links jump into the video.

Ten years of droidcon NYC

• 0:03 — Intro — Opening crowd work, and the 2014 conference shirt I designed myself by copy-pasting in Photoshop, as you can probably tell.
• 1:25 — Story time, 2013 — Touchlab was New York’s Android shop when everyone else made iPhone apps. Meanwhile in London there was Novoda, an Android shop running an Android meetup, also run by a Kevin. Then came a rumor that they were going to do a droidcon — which factored into our decision more than a little.
• 2:46 — Would Lucasfilm come after us? — A genuine 2014 concern about the “droid” brand. We decided the press would be worth it. They never did.
• 3:26 — We had never run a conference — I hadn’t seen the Metropolitan Pavilion before we put down the deposit, and my first thought on seeing it was that Touchlab might not survive this. Jeff gets the credit for thinking big. Also: sponsors are what make these events happen, so go say hi.
• 4:06 — Tips for running a community conference — Don’t pay the venue deposit before you know who their AV vendor is. Renting gear is expensive but you will want to go straight home afterward. Don’t schedule on a weekend — half the appeal is taking time off work.
• 4:48 — Kotlin in the 2014 conference app — Early enough that the VM stopped on a class and we never worked out why; we just removed it. I also hid gold and silver tickets for anyone who built the app from source.
• 6:49 — Every conference is stressful, the first one especially — Photos, familiar faces, and the discovery that internet pictures do not, in fact, live forever.
• 8:51 — Thanks — To Jeff, for being characteristically optimistic about obviously bad ideas, and to Greg and the droidcon team, who are the reason this still exists at the level it does.
• 9:32 — Why community events matter — Industry events are fun, but you can’t really say anything the host doesn’t love. Dissent is how things improve. Without it we might all still be talking about AsyncTask.

Where the community is now

• 10:54 — What changed around us — Covid and then remote work broke the meetup habit; nobody commutes back in from Westchester for pizza. Meetup itself went sideways, and the Android community on Twitter essentially evaporated. That used to be the level playing field.
• 11:34 — What this event is for — Deep dives, advanced topics, things that are a little weird or controversial. Not getting started with RecyclerView. That focus, plus someone paying for a trip to New York, is why the people actually doing things in Android show up.
• 12:57 — Where the native default sits now — Unscientific, but the threshold for “now we go native” has clearly moved. In 2014 it wasn’t even a question — the startup was the app.

Native didn’t die, it narrowed

• 13:37 — Writing a keynote — Far more stressful than reviewing them. I sampled other anniversary keynotes for the vibe and found every single one was a look back. Which is partly why I did the nostalgia first and then moved on.
• 14:59 — Android development in 2024 is a specialized discipline — The live debates are modularized architecture, Gradle performance, and first-render times in Compose measured in milliseconds. Architecture conversations went from “let’s sort this out” to standardizing testable architecture across teams and features.
• 16:19 — “Native is dying” started around 2007 — Every couple of years cross-platform is about to catch up and devices are about to get good enough. It never went that way. Native apps are critical to a certain class of product, and saving a little money there is a bad trade.
• 17:00 — The Lagrange point — New apps go native less often, while native development itself got more complex. The community hasn’t contracted; the domains where native gets built have narrowed, and the complexity inside them has grown a lot.
• 17:40 — The hype cycle, twice — Web hype peaked at comparisons to the printing press, then faded — and the modern world now doesn’t exist without it. Mobile followed the same curve. Excitement about mobile development dropped; the utility never did.
• 19:01 — The boring middle — For many people mobile is the only way they reach the digital world. The boring middle is any product that needs mobile where mobile isn’t the product. My medical records app is a perfect example: enormously useful, and as a mobile developer I have to switch my brain off to use it.
• 20:23 — What mobile devs do now vs. 2014 — Back then it was a side hustle you could buy a car with. Now it’s large native apps, with a strong pull toward freelance.
• 21:04 — An aside on speaking — The last time I spoke at droidcon NYC was 2014, where I ran out of slides before the end of the talk. Doing two talks in one day is also a bad idea.

Compose Multiplatform as a default

• 21:45 — The risk cliff — Cross-platform is a capital-letters decision, and the part that matters at the table is what happens if it doesn’t work out. The answer used to be a rewrite, which forced a lot of decisions.
• 22:26 — The actual claim — Not “this works.” That this becomes the default choice for mobile. Set timelines aside for a minute and assume the mechanical problems get solved.
• 23:07 — Why CMP is technically different — On paper it looks like the alternatives: render to a canvas, declarative UI. The difference is interop. It talks directly to Swift and Objective-C, in the same process, which has always been the fundamental distinction.
• 23:47 — The 80/20 UI — Mix Compose with SwiftUI or UIKit directly, share data objects, send messages back into KMP architecture. Users spend nearly all their time on a few core screens, so build those native and Compose almost everything else.
• 24:27 — No cliff, maybe a ledge — There’s always risk. But if a fully-Compose iOS app turns out to be something you regret, the fix isn’t a rewrite — you add native screens where they matter.
• 25:08 — iOS is the only cross-platform part — You’re building an Android app with Android tools. Android is just Android.
• 26:28 — Is this a team-Android thing? — I like good apps. If you can get a better app experience for comparable cost, that’s more room to make the thing good. Flutter would be fine too — I’m arguing about which one is the default, and I’m aware I’m making that argument at an Android conference.
• 27:51 — Optionality is the point — Most apps won’t add native iOS screens. But being able to removes the up-front risk, and that up-front decision — made with imperfect information, answered years later when it’s too late — is what stops teams from trying at all.

What has to happen

• 29:12 — Closer than most people think — Tech preview, 2023 alpha, 2024 beta, 2025. I like trends; extrapolate that one.
• 29:52 — The droidcon NYC app — In 2022 people said you couldn’t put Compose on a real iPhone. We tried one screen, it went fast, and it shipped — first in the App Store with Compose on iOS. There’s still a settings toggle to switch between the Compose and SwiftUI versions. In 2022 the comparison was not flattering. Try it now.
• 31:13 — The community is essential here — JetBrains is doing the core work and doing it well, but the surrounding ecosystem isn’t their job alone.
• 31:54 — Nobody knows about this — The Android community is vaguely aware. The Flutter and iOS communities aren’t and may not want to be. The general developer community — the people who most need to know — would have no idea what you’re talking about. I want the conversation to start at “Compose, unless you can argue for something else.”
• 32:35 — We need better framing — Senior decision-makers who weren’t senior during the native days hear “cross-platform” and think garbage. It’s also not accurate: it isn’t cross-platform on Android, and barely on iOS. Someone please coin a better term.
• 33:15 — KMP is open season for open source — Getting attention for a new Android library is very hard; that ecosystem is mature. KMP isn’t crowded, and it’s growing. It’s also a good place to make your first open-source mistakes.
• 33:56 — The gaps are mechanical — Wrap the native iOS component, host it, give it a sensible API you can call from Compose. We did exactly that for a map view on a live stream. Teams evaluating KMP see a library desert and pick Flutter instead. A decent contingent could fill those gaps in months.
• 35:17 — Extending beats starting from scratch — When people say Compose on iOS is years away, they’re misreading it. It isn’t starting from zero — it’s making an existing thing work well on another platform.
• 36:38 — Full circle on a decade-long obsession — Android and iOS are fundamentally sandbox containers, KMP is genuinely native on iOS in that it interops directly with the platform, and adding a blendable UI closes the loop.
• 37:18 — A specific possibility for a specific community — There’s no reasonable Swift version of this. The groundwork exists, major organizations are behind it, and this community is the only one positioned to take it anywhere.

The shadow of the web

• 37:59 — JavaScript infects everything — This has bothered me irrationally for years. The open web is good, but as an application platform the browser is a strange pile of committee-designed APIs. A sandbox container would be better — it’s what everything else is.
• 38:39 — You can share code, but not architecture — Cross-platform was all web for years because everyone was a web developer, so mobile inherited restrictions it doesn’t actually have. Live by browser rules or build multiple apps.
• 40:40 — If Kotlin/Wasm gets big — Expect many UI options: Wasm driving the DOM, other canvas UIs, whatever. KMP is flexible enough to carve out layers however you like.
• 41:20 — It doesn’t have to replace JavaScript — These debates go binary fast. Wasm just has to be productive — it can’t be more work than JS, which isn’t a high bar.
• 42:00 — Flash held up half the web forever — Different circumstances entirely, but being everywhere doesn’t mean staying everywhere.
• 42:41 — Watch Safari and Project Fugu — The last GC domino is close. Fugu’s premise is that web apps should be able to do anything iOS, Android, and desktop can — which is the same architectural homogeneity, in a funkier container.
• 43:22 — You don’t need one default language — Wasm is wide open, and the assumption that there must be a single language is a habit from living in a one-language world. Kotlin looks like a good option. Ask me in 2014 where we’d be and I’d have guessed all web. Native isn’t going anywhere — but it can be everywhere.