Kotlin Enum vs Sealed Class: Which One Should You Pick

Kotlin Enums and Sealed Classes both model restricted type hierarchies — but they differ in flexibility, memory behavior, and pattern-matching power. Pick the wrong one and you will fight your own code every time you add a new variant.

The Problem Both Solve

When modeling a fixed set of states, operations, or configurations in Kotlin, you need a type that guarantees exhaustiveness. The compiler should catch every case so that new values cannot slip through untested. Kotlin gives you two tools:

enum class

sealed class

when

This post breaks down exactly how they differ, where each shines, and how to choose with confidence in real Android projects.

Kotlin Enums: Strengths and Limitations

Enums are the simpler tool. Each constant is a single instance with a fixed name and optional properties.

enum class OrderStatus(val label: String) {
    PENDING("Awaiting confirmation"),
    SHIPPED("In transit"),
    DELIVERED("Completed"),
    CANCELLED("Refund issued");
}

Enums compile to a single class with static constants. You get built-in

values()

valueOf()

OrderStatus.values()

[!TIP] Use Enums when your set of values is truly fixed, each value carries only data (no behavior), and you need ordinal or name-based reflection.

Where Enums fall short is behavior. Every constant shares the same class body. You cannot override a function per constant without wrapping it in an abstract method, which forces every constant to implement it:

enum class PaymentMethod {
    CREDIT_CARD {
        override fun validate(): Boolean = true
    },
    PAYPAL {
        override fun validate(): Boolean = true
    },
    CRYPTO {
        override fun validate(): Boolean = false
    };

    abstract fun validate(): Boolean
}

This works, but the syntax is verbose. Each constant becomes an anonymous subclass behind the scenes, which increases bytecode size — a real concern in apps with many Enums.

[!WARNING] Enums with abstract methods create one anonymous subclass per constant. If you have 20 constants, you have 20 extra classes in your DEX file.

Enums also cannot hold different data per constant without pairing it with an abstract property, which adds boilerplate. They are value objects — simple, predictable, and limited.

Sealed Classes: Strengths and Limitations

Sealed Classes give you the same restricted hierarchy but with full class power. Each subtype can carry different data, override different behavior, and even be a

data class

object

sealed class Result<out T> {
    data class Success<T>(val data: T) : Result<T>()
    data class Error(val exception: Throwable) : Result<Nothing>()
    data object Loading : Result<Nothing>()
}

Look at that. Three subtypes, each with completely different fields and types. A

Result.Success

Result.Error

Result.Loading

when

else

Sealed Classes also work naturally with generics, inheritance hierarchies, and state-holding patterns in Jetpack Compose and MVVM architectures.

[!IMPORTANT] Sealed Classes are the default choice when each variant has different data or different behavior. They scale cleanly as your app grows.

The tradeoff is visibility. A sealed class must be either declared in the same file (for non-local declarations) or marked

sealed

Side-by-Side Comparison

values()

valueOf()

when

Use this table as a quick reference when you are starting a new model. If your variant needs data or behavior, go sealed. If you need reflection or iteration, go enum.

Real-World Example: Payment Processing

Consider a payment screen in an Android app. The user can select a method, and each method requires different input data.

sealed class PaymentOption {
    data class Card(
        val cardNumber: String,
        val expiry: String,
        val cvv: String
    ) : PaymentOption()

    data class PayPal(val email: String) : PaymentOption()

    data object CashOnDelivery : PaymentOption()
}

With this structure, your ViewModel accepts a

PaymentOption

fun processPayment(option: PaymentOption): String = when (option) {
    is PaymentOption.Card -> "Charging ${option.cardNumber}"
    is PaymentOption.PayPal -> "Redirecting to ${option.email}"
    is PaymentOption.CashOnDelivery -> "Cash on delivery"
}

No

else

PaymentOption.GooglePay

when

If you attempted this with an Enum, you would need an abstract property for every possible data shape, which quickly becomes unmaintainable.

[!NOTE] In MVVM architectures, sealed classes are ideal for UI states (

code Copy

UiState.Loading

,

code Copy

UiState.Content

,

code Copy

UiState.Error

) because each state carries exactly the data the composable needs.

For something like logging levels or network retry policies — where every value is behaviorally identical and carries only a label or integer — Enums remain the better fit. The simplicity is genuine, not forced.

How to Decide

Ask yourself three questions in order:

1. Does each variant carry different data? If yes, use a sealed class.
2. Do you need to iterate or reflect over all values at runtime? If yes, use an enum.
3. Are all variants behaviorally identical with only a name or simple value? If yes, use an enum.

Most modeling tasks in modern Android apps — navigation routes, UI states, network results, feature flags — involve variants with different data. That points strongly toward sealed classes. Reserve enums for genuinely simple, fixed sets where reflection or iteration matters.

Key Takeaways

• Pick Sealed Classes when variants have different fields or behavior — they give you type-safe, exhaustive
  code Copy

  when

  expressions with clean data carrying per subtype.
• Pick Enums when the set is fixed, behaviorally identical, and you need
  code Copy

  values()

  or
  code Copy

  valueOf()

  for reflection, iteration, or simple label mapping.
• Avoid adding abstract methods to Enums with many constants — each one generates an anonymous subclass and inflates your DEX count unnecessarily.
• In Jetpack Compose and MVVM, prefer Sealed Classes for
  code Copy

  UiState

  and
  code Copy

  Result

  wrappers because each state naturally holds different data for the composable to render.
• Always check module boundaries — Sealed Classes restrict subtypes to the same module unless you use
  code Copy

  sealed interface

  across package declarations carefully.
• Test every
  code Copy

  when

  expression over a sealed hierarchy with a unit test that asserts all cases are covered, especially after adding a new subtype.