Droidcon NYC iOS app with Compose

 Droidcon NYC is coming up in a couple of weeks! It’ll be great to see everybody in person again.

DROIDCON NYC DISCOUNT

We have a 25% discount code for tickets: “TOUCHLAB_COMMUNITY_DCNYC22”.
Go to https://nyc.droidcon.com/tickets and put that in the “Redeem a voucher” box.

For the past few years, we’ve been building the event app with KMP. We have a few announcements related to the app this year.

Back to open source​

Touchlab has been doing a lot of tooling work and research lately, mostly around iOS developer experience and KMP. We forked the Droidcon app into a private repo to dogfood some of that stuff and had intended to move changes back into open source pretty quickly. However, that took a little longer than planned, so for some of the events earlier this year, the version in the public repo wasn’t reflecting the latest changes. That’s mostly OK, though, as we hadn’t changed much at a fundamental level. If you had forked it for some reason, check for updates.

As of today, we’re back to open-source dev for the Droidcon app. Check it out here:

DROIDCONKOTLIN REPO
https://github.com/touchlab/DroidconKotlin

We also have another big announcement…

The iOS Droidcon App with Native Compose UI​

Jetbrains has been working on Native Compose UI, and I think most people who pay attention to these things have seen examples. Internally, we all figured it was still a ways off from being usable, but we wanted to check in on the status. So, we added some to this year’s Droidcon NYC app.

Touchlab ran the first Droidcon in North America, and we have been involved in Droidcon NYC ever since. If you’ve never been behind the scenes of a mobile dev conference, there’s one curious observation I’ll let you in on. Most of them write their own apps. It’s a weird, time-consuming tradition, but we all seem to do it. Generally speaking, it’s a great place to experiment with new mobile tech, as the audience is (generally) forgiving, as long as it’s interesting and open source. Anyway…

The goal was to maybe add a button or a small feature. However, through some great work by our team (shout out to JuliaJakubcova and TadeasKriz), it turns out you can do a lot with Native Compose UI. While not something I’d use in a regular production app today, the dev process went way better than I think anybody expected.

Originally we were going to stay on the safe side, default to Swift UI, and let you toggle a setting to try Compose. However, this week we decided it’s just Compose. It’s an Android conference, so we can roll the dice a bit with the iOS app, as long as it works (you can switch back to Swift UI in the phone settings if things aren’t going well).

The app is not in the store yet. It pushes to App Store Connect fine, but we’ll see how the review process goes.

Julia and Tadeas will be publishing a much more in-depth technical article about how things are set up, and how to code something with the current state of Compose UI on Native, but I wanted to take a minute to discuss the tech and frame how we’re thinking about it.

Shared UI vs Shared Logic​

I was watching a talk recently and one of my quotes came up as kind of a defense of avoiding shared UI:

“Shared UI is a history of failure. Shared logic is the history of computing.”

It’s a good quote for a talk. Fits neatly on a slide and gets tweets. However, it lacks nuance. Shared UI has many examples of bad attempts and compromise, and shared logic is all over the place. “The web is shared UI!” Yes, but 15 years into the “smartphone era”, native dev is still going strong ⏰. That is true, contrary to most people’s expectations, mine included.

We like KMP because it is designed to be optionally included. Out of the box, that’s just for logic. That means a much lower risk of adoption by any size team. Along with a number of other characteristics, we believe that means almost certain success for the KMP platform. KMP encourages efficiencies while discouraging non-native experiences.

However, it was clear from the start that KMP would have a UI story. When I describe KMP, in my “other” quotes, I don’t say “non-UI logic” but rather “not-necessarily UI logic”. That is the key distinction here, and why I’m excited about Compose on iOS and other platforms. Most “cross-platform” frameworks encourage an all-or-nothing approach. You build the UI and logic with the UI definition they provide, and in the language that they mandate (often a very different one). You can mix native and cross-platform with any of them, technically speaking, but they make it rather difficult and unproductive to do so at scale. That is because good interop is hard. KMP’s approach of focusing on interop and building up from there, while arguably more difficult and certainly a longer path, will pay off in the long term.

I see common pushback from native devs that, basically, iOS apps aren’t going to (re)write all of their screens with Compose. I agree. However, that’s the difference. You can have common screens in most of your app, then replace some of the main UI on iOS with native screens, still talking to the common Kotlin architecture. On Android, assuming Jetpack Compose is successful, everything is “native”, so no compromise.

Imagine an app with a bunch of settings screens and other data display screens that you only see occasionally, or never. It has a few main screens you use 90% of the time. On iOS, those main screens are fully native and communicate “under the hood” to a shared architecture. Everything else is a shared UI. Over time, maybe some screens that aren’t changing much get a native refresh. You can do that incrementally.

Can you do that with, say, another popular portable UI framework? Yes, you can create a transparent overlay and pass through click events, and communicate between platforms with IPC channels. That is “technically possible”, but in a word, it sucks 🔥. There’s a big difference between “technically possible” and “core use case”.

Optionally sharing code, and (arguably 🙂 screens, is core to KMP’s design rather than an exceptional case. It’ll make a huge difference in practice.

Of course, “UI story” isn’t accurate. It’s more than one. Come hear about Redwood at Droidcon NYC! That’s 2 UI options for KMP in one post.

⏰ If perhaps consolidating to one side of the chart…

🔥 I’m not saying the “popular portable UI framework” sucks. It’s doing quite well. I’m saying trying to mix a lot of “native” and that framework sucks. I’m sure its fans would disagree, but that’s the thing about opinions 🙂

-fin-