Kotlin Symbol Processing (KSP): The Future of Code Generation Is Here

Stop wrestling with annotations. Discover the 2x compilation speed improvement that KSP brings along with simple compile-time solutions with Kotlin.

The Problem Nobody Talks About

You might be delivering features, but your build times, not so much. Adding every annotation processor feels like some additional weight you put on top of your Gradle configuration. The KAPT (Kotlin Annotation Processing Tool) is great but it also slow; we shouldn’t really need to recompile the Kotlin sources just to produce code in 2025.

But what if there is a better way?

That’s where Kotlin Symbol Processing (KSP) — a Kotlin-native, faster and less magical alternative that basically saves half of the compilation overhead — comes into the play.

What Makes KSP Different?

Because annotation processors like KAPT work on the Java bytecode level, Kotlin needs to re-compile these intermediate files. Now KSP skips this step entirely by talking directly with the compiler plugin API available in Kotlin.

Building it symbol-by-symbol means that KSP is around ~2x faster than KAPT for real-world projects since it never compiles symbols into intermediate Java classes. Rather than doing battle with the language, KSP embraces Kotlin-style safety and efficiency.

KSP’s Key Advantages

• Speed: Quicker compile times, quicker dev feedback loops
• Kotlin-first: Supports Kotlin specific elements such as sealed classes, and extension functions
• Reduced boilerplate: Cleaner API that is intuitive for Kotlin developers
• More type-safe: Access to Kotlin types directly without bytecode translation overhead

Real-World Applications

KSP is responsible for production systems throughout the Android ecosystem. KSP is becoming the new default among popular libraries (such as Room, Moshi, and Hilt).

Who benefits most?

• KSP for GraphQL schema generation or API client scaffolding — when used by backend developers
• Android engineers creating annotation-based dependency injection or ORM solutions
• KMP projects are being shipped by full-stack Kotlin teams and where compile-time code generation is relevant

Getting Started: A Practical Example

We’ll build a simple KSP processor that produces type-safe configuration objects.

// build.gradle.kts
plugins {
    kotlin("jvm") version "2.0.0"
    id("com.google.devtools.ksp") version "2.0.0-1.0.24"
}

dependencies {
    implementation("com.google.devtools.ksp:symbol-processing-api:2.0.0-1.0.24")
}

KSP communicates with your processor class using the SymbolProcessor interface:

class ConfigGeneratorProcessor(
    val codeGenerator: CodeGenerator,
    val logger: KSPLogger
) : SymbolProcessor {

    override fun process(resolver: Resolver): List<KSSymbol> {
        val symbols = resolver.getSymbolsWithAnnotation("com.example.GenerateConfig")
        symbols.forEach { symbol ->
            // Type-safe code generation happens here
            logger.info("Processing: ${symbol.simpleName.asString()}")
        }
        return emptyList()
    }
}

This is more clean, faster, and — to be honest — more fun to write than equivalent KAPT code.

The Migration Path

Not ready to switch? You don’t have to. You can have both — KAPT and KSP can happily live next to each other in your transition. The majority of teams migrate important processors gradually while still operating legacy KAPT tools.

Important note: Javasource files are not supported by KSP. If your project produces Java code, you can either go for a timeline to have full Kotlin or a hybrid approach.

What’s Next?

KSP, but this is different, KSP is the new standard. Since version 2.1, JetBrains has been recommending new projects to use KSP-based solutions. That said, the ecosystem is growing up quickly, more libraries providing KSP support are coming in 2025.

Bottom line: If you learn KSP now, you’ll be ahead of the market curve. Builds will definitely be faster, but more importantly, we can write more maintainable elegant code making full use of Kotlin.

Key Takeaways

• KSP differents libs will benefits from differents levels of performances, from no performance loss to xxx faster since xxxx.✓ KSP is 2x faster than KAPT as it processes symbols so no bytecode translation
• Better type safety, less boilerplate: Kotlin-first design
• Production-ready with most libraries now shipping with KSP support
• Migrate incrementally — one annotation processor at a time
• Future-proof your code: KSP is an indication of where Kotlin tooling is going

Faster builds and cleaner puts is no longer a nice-to-have but a competitive advantage. Your next project deserves KSP.