ProGuard, and similar tools like R8 and Redex, aim to shrink and optimize code as much as possible. What is a keep rule anyway and why do we need them? You’ll learn why you need to think in terms of Java when writing keep rules for Kotlin code, using examples from the Droidcon London 2021: Keep Rules in the Age of Kotlin ProGuard Playground you’ll also find the answers to the playground challenges there. In this post, we’ll dive deeper into one section of the Droidcon presentation: the complications of writing keep rules for Kotlin code.

I recommend you watch the full presentation for an overview of the potential hidden pitfalls in the Age of Kotlin as well as some ideas for mitigations. In my presentation at Droidcon London, Keep Rules in the Age of Kotlin, I laid out some potential security concerns, such as leaking data via Kotlin assertions, and the potential impact of Kotlin metadata on the size of apps. Kotlin is a much more modern language which has many features that Java does not. Though Kotlin was designed to be interoperable with Java from the start and designed to run on the JVM, much has changed in 20 years. ProGuard, which turns 20 this year, was originally created in the era of Java 1.4, Java Applets, J2ME and Sun Microsystems. Kotlin is used by over 60% of Android professional Android developers and it's estimated that 1 million professional software developers use Kotlin as 1 of their 3 primary languages.Ĭlearly, we are truly in a new age: the Age of Kotlin. Yet Kotlin is now the go-to language for Android development, and is becoming more popular for desktop and server application development.

Kotlin is relatively young – only 11 years old – and Android has only had official support for Kotlin for five years.

Kotlin any type