[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]