[MUSIC PLAYING] Márton MÁRTON BRAUN: Hi. I'm Márton Braun, a
Developer Relations Engineer on the Android team. I'm joined by James Ward, a
product manager for Kotlin at Google. Today, we'll cover what's new in
the world of Kotlin for Android and give you a sneak peek into
how we use Kotlin at Google. We'll take a look at
the Kotlin 2.0 compiler, using Kotlin for
Gradle builds scripts, Kotlin Symbol Processing,
and Kotlin Multiplatform. But before we get into
those updates, let's just quickly recap where
we are with Kotlin. Kotlin has been an officially
supported language on Android since 2017. Last summer, we celebrated
five years of Kotlin on Android with a
series of interviews, talking to several people who
made Kotlin for Android happen. If you haven't read them
yet, these interviews are a great way to learn
more about this story. On top of supporting
Kotlin, Android development has now been Kotlin
first for four years. This means that our libraries,
documentation, and content are all designed
primarily for Kotlin. We love Kotlin for its
conciseness, type safety, and expressive
language features. And our data shows that
professional Android developers also prefer using Kotlin. Today, over 95% of the top
thousand apps on the Play Store use Kotlin. This includes indirect
use through dependencies. Looking only at applications'
own code, over 70% of the top thousand apps have
Kotlin in their code base. Coroutines are a
recommended solution for asynchronous
programming on Android, are used in the code base of
55% of apps that use Kotlin. We can't talk about
Kotlin without mentioning Jetpack Compose, our
modern toolkit for building UI across all form
factors of Android and our greatest commitment
to Kotlin so far. Compose has been built with
Kotlin from the ground up. And it makes great use of
many of its language features, such as coroutines,
lambdas, and extensions. It also wouldn't be possible
without Kotlin's rich compiler API, which allows us to
generate all the logic related to Compose estate
management for you. If you're looking to get
started with Compose, we have a Jetpack Compose
for Android developer scores. And our full Android
basics with Compose course is also available
now, for those looking to learn Kotlin, Android,
and Compose from scratch. I'll now hand it
off to James to talk about how we use
Kotlin at Google and to get into
some of our updates. [MUSIC PLAYING] JAMES WARD: At Google, we use
Kotlin extensively ourselves. It's been generally available
for Android projects in Google since 2019 and for
server-side use since 2022, joining only four other fully
supported server languages. Thousands of Google
engineers write Kotlin, and we have more than 15
million lines of Kotlin code in our source control
system, which so far has been doubling year over year. Most of our apps are
written in Kotlin. We have over 70 Android
apps using the language. We also participate in
the Kotlin Foundation, funded together by
JetBrains and Google, which ensures that the
language evolves nicely, for example, by
reviewing new features and any potential
break-in changes. We're happy to welcome
three new silver members to the foundation this year-- Gradle, Shopify, and Touchlab. Now, let's get into what's new. JetBrains and Google have been
rebuilding the Kotlin compiler to enable better build
and ID performance. This new compiler, codenamed
K2, will be the default compiler in Kotlin 2.0. Compilation speed
with Kotlin 2.0 is up to twice as fast as
the current Kotlin compiler. And the new compiler will also
enable more Kotlin language feature advancements
in the future. So we are very excited about
the new Kotlin compiler and hope that it will
enable even higher developer productivity in Kotlin. The goal is to make the compiler
a drop-in replacement for most code, so you shouldn't have
to change your Kotlin source. Compiler plugins, on the other
hand, will need to add support. We are working to enable
experimental use of Compose and KSP with the new compiler
around the Kotlin 1.9 time frame. Internally, in Android Studio,
we use the Kotlin compiler for code intelligence,
refactoring, and other features. These will also need to be
rebuilt on the new compiler. That work has begun and
should be in a stable release in the next year or so. To make the migration
seamless, we'd love you all to start trying
the Kotlin 2.0 compiler as soon as possible to verify
that it works correctly on your code base. In the latest
Kotlin releases, you can try out the new compiler
just by setting the language version to 2.0. Once your required compiler
plugins have added support, please, try it out,
either manually or with parallel continuous
integration builds. And file bugs if you
encounter any issues. Next up some news about
Kotlin and Gradle. I'm a huge fan of Kotlin
for my app and UI code. But I love that I
can also use Kotlin to define my Gradle builds. The familiar declarative
syntax and power helps me to find my
builds in a way that is maintainable and extensible. Until now, our templates use
the Groovy DSL for new projects and modules, but we are
now switching the default to use the Kotlin DSL, starting
in Android Studio Giraffe. Using Kotlin for build scripts
brings several improvements. Let me show you some examples. The new Project Wizard now
includes both Kotlin and Groovy for build scripts with
Kotlin as the default. The Kotlin build scripts
use statically-typed values, so code hinting is more
precise and more helpful. Syntax errors are more
accurate, and they're displayed while editing
Kotlin build scripts, instead of when trying
to sync the project. You also get type and
method documentation. And if you need
more details, you can control-click through into
the underlying source code. In addition to
Kotlin build scripts, we're also adding
Gradle version catalogs as an experimental
option, which gives you a centralized, scalable way
of defining your project's dependencies. These are just some
of the examples of how Kotlin build definitions
improve developer productivity. To get started with the Kotlin
DSL or version catalogs, download the Android
Studio Giraffe preview and use the published
migration guides. For a great example of
using Kotlin build scripts and version catalogs in action,
check out the Now in Android sample application. Now back to Márton to talk
about code generation in Kotlin. [MUSIC PLAYING] MÁRTON BRAUN: Code
generation for Kotlin began with KAPT, the Kotlin
Annotation Processing Tool, which enables the use of
annotation processors written for the Java programming
language with Kotlin code. KAPT works by generating Java
stubs from your Kotlin files that the processors
can then work with. This stub generation is a
time consuming operation and has a significant impact
on the build speed of projects that use annotation processing. This is why we built Kotlin
Symbol Processing, or KSP, which is a Kotlin-first
alternative to KAPT. KSP analyzes Kotlin
code directly, which has several benefits. It's up to twice as
fast in clean builds, as there's no stub
generation required. It has a better understanding
of Kotlin's language constructs and type system,
such as nullability. And it supports
multiplatform projects, as it doesn't depend on Java. For these reasons, we recommend
migrating your dependencies from KAPT to KSP
wherever possible. We have a full migration
guide on developer.android.com that covers all the details,
but here are some of the basics. To get started, add the
KSP plugin to your project in your root-level build file. Make sure that the
version you use matches your project's
Kotlin version. Then apply the KSP
plugin in your module, and change your dependencies
declared with KAPT to use KSP instead. You can do this one by one, as
you can run both KAPT and KSP together in your project. You might not be able to
migrate all your usages of KAPT yet, as it's up to
individual libraries to add support for KSP. However, many popular
libraries already support it, such as Room, Glide, and Moshi. You can also find a list
of supported libraries in the KSP documentation. We know that many of you are
waiting for Dagger and Hilt to support KSP. This work is in
progress, and you should monitor the
Dagger Releases page for the latest updates,
if you use these libraries. Even if you can't migrate
all annotation processors you use yet, we recommend
starting the adoption of KSP today. As every usage of
KAPT migrated to KSP is a step in the
right direction. The migration can be
performed incrementally, library by library
and module by module. Keep in mind that you'll see
the most significant build speed improvement when
KAPT is completely removed from a module. As that's when stub generation
is no longer required. Again, check out the migration
guide for the full details, and start using KSP today. For our last topic, let's
take a look at multiplatform. Kotlin Multiplatform can
enable sharing business logic between Android and iOS by
writing Kotlin code once, and then compiling it
for both platforms. This technology is
developed by JetBrains, and it's currently in beta. We are experimenting with
Kotlin multiplatform ourselves. In Google Workspace,
we're adopting it to share business
logic and to deliver consistent experiences to all
clients across Android, iOS, and web. We've been doing this
using the Java language for more than a decade. But now we're experimenting
with Kotlin multiplatform as a long-term, code-sharing
strategy in these products. As part of our
experiments, we're also bringing some
Jetpack libraries to multiplatform,
which you can make use of if you're already using
Kotlin Multiplatform to build your mobile apps. Our first three multiplatform
Jetpack libraries, which are Annotations,
Collections, and DataStore, have now moved from experimental
previews to offer releases. We look forward to your
feedback on these libraries. For an example of Multiplatform
DataStore in action, you can find our Dice
roller sample app on GitHub. To learn more, check out
our new documentation page about Kotlin Multiplatform. That's it for our updates. To recap, here's all the things
you can try after this session. As soon as the compiler
plugins you use support it, check that the
Kotlin 2.0 compiler can build your projects. Give the Gradle Kotlin
DSL and version catalogs a go using Android
Studio Giraffe. Migrate from KAPT to Kotlin
Symbol Processing for libraries that support it, and if you
use Kotlin Multiplatform, try our Multiplatform
Jetpack libraries. Finally, to learn more about
what we're doing with Kotlin, you can catch up on our
talks from KotlinConf. These cover our work
on Multiplatform in Jetpack, Android,
and Google Workspace, provide more details on our
internal usage of Kotlin, give you advice for using
coroutines, and more. Thanks for joining us,
and have a nice Kotlin. [MUSIC PLAYING]
