Why apply() Changed How I Initialize Objects

Early in my Kotlin journey, I found myself writing repetitive initialization code for UI components and data objects. Setting properties one by one felt verbose and obscured the intent of the code. Then I discovered the apply scope function, which transformed how I approach object configuration.

The apply function is part of Kotlin's standard library scope functions (let, also, run, with, and apply). What makes apply special is that it returns the original object after executing a block of code where the object is accessible as this. This makes it perfect for object initialization and configuration.

Real-World Scenario: Building a RecyclerView Adapter

Consider a common Android development task: creating a RecyclerView adapter. Without apply, you might write something like this:

val adapter = MyAdapter()
adapter.context = context
adapter.items = itemList
adapter.clickListener = clickListener
recyclerView.adapter = adapter

This works, but it's fragmented. The adapter creation and configuration are separated, making it harder to see the complete setup at a glance. With apply, we can keep everything together:

recyclerView.adapter = MyAdapter().apply {
    context = this@MainActivity
    items = itemList
    clickListener = clickListener
}

Notice how the configuration block is scoped to the adapter instance. Inside the apply block, we can access properties directly without repeating the adapter name. The this@MainActivity syntax disambiguates between the adapter's this and the activity's this.

When to Use apply() vs Other Scope Functions

Understanding when to reach for apply versus other scope functions is key to using it effectively:

  • Use apply when you want to configure an object and need the original object returned (for assignment or chaining).
  • Use also when you need to perform some action on an object but don't want to change the scope (it instead of this).
  • Use let when you want to transform an object and return something different.
  • Use run when you need both object scoping (this) and a return value from the block.

For initialization and configuration tasks, apply is often the clearest choice because it keeps the focus on the object being configured.

Production-Ready Example: Database Setup

Here's how I use apply in a Room database setup:

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao

    companion object {
        @Volatile
        private var INSTANCE: AppDatabase? = null

        fun getInstance(context: Context): AppDatabase {
            return INSTANCE ?: synchronized(this) {
                val instance = Room.databaseBuilder(
                    context.applicationContext,
                    AppDatabase::class.java,
                    "app_database"
                ).apply {
                    fallbackToDestructiveMigration()
                    addCallback(object : RoomDatabase.Callback() {
                        override fun onCreate(db: SupportSQLiteDatabase) {
                            super.onCreate(db)
                            // Initialize default data
                        }
                    })
                }.build()

                INSTANCE = instance
                return instance
            }
        }
    }
}

In this example, apply cleanly groups the database builder configuration. All the builder methods are called on the same instance, and we get the configured builder back to call build() on it. This is much cleaner than chaining methods or using temporary variables.

Why This Approach Works Well

The real power of apply comes from how it aligns with Kotlin's design philosophy:

  1. Reduces visual noise: Eliminates repetitive object references
  2. Groups related operations: Keeps configuration together where it belongs
  3. Maintains immutability options: Works equally well with val and var
  4. Clear intent: Immediately signals to other developers that this is initialization/configuration code

I've found that teams adopting apply consistently report cleaner initialization code, especially in Android development where View setup, adapter configuration, and builder patterns are prevalent. It's one of those small Kotlin features that, once internalized, significantly improves daily coding experience.

Remember: apply isn't about saving keystrokes—it's about making your code's intent immediately obvious to anyone reading it later (including your future self).