Sealed classes in Android Kotlin - Build, Publish & Deploy

Build & Publish - Sealed classes

Performance Impact of Sealed Classes

Sealed classes in Kotlin help the compiler know all possible subclasses at compile time. This allows for efficient when expressions without needing an else branch, improving code clarity and reducing runtime checks.

They have minimal impact on frame rate and memory because they are just a type system feature. The sealed class hierarchy is resolved at compile time, so no extra runtime overhead occurs compared to regular classes.

Battery usage is unaffected by sealed classes themselves; performance depends on how you use them in your app logic.

💻

How to Optimize Sealed Classes for 60fps Rendering

Use sealed classes to model UI states or events clearly. This helps avoid unnecessary runtime type checks and makes your UI code easier to optimize.

Keep sealed class hierarchies shallow and avoid heavy initialization in subclasses to reduce memory pressure.

Use when expressions exhaustively with sealed classes to enable the compiler to optimize branching, which can help maintain smooth UI updates.

Impact on App Bundle Size and Startup Time

Sealed classes add negligible size to your app bundle because they compile down to simple class files without extra metadata.

They do not affect startup time directly. However, using them to organize code can lead to cleaner, more maintainable code, which indirectly helps optimize startup by making logic easier to streamline.

iOS vs Android Differences for Sealed Classes

Sealed classes are a Kotlin feature primarily used on Android. iOS apps written in Swift use enum with associated values or protocols with restricted implementations to achieve similar behavior.

On Android, sealed classes integrate tightly with Kotlin and Jetpack Compose or XML UI code. On iOS, you use Swift language features for similar sealed-type safety.

When sharing code via Kotlin Multiplatform, sealed classes can be used in common modules, but iOS code must handle them via generated Swift interfaces.

Relevant Store Review Guidelines and Requirements

Using sealed classes does not affect app store guidelines directly.

However, well-structured code using sealed classes can help avoid runtime crashes and unexpected behavior, which improves app stability--a key factor in app store approval.

Ensure your app complies with Google Play launch checklist and Apple App Store guidelines for performance and stability.

Self-Check: Your App Takes 5 Seconds to Load This Screen. What's Likely Wrong?

If you use sealed classes to represent UI states but the screen loads slowly, the issue is likely not the sealed classes themselves.

Check for heavy computations or blocking operations in the sealed class subclasses or in the when branches handling them.

Also verify if you are doing expensive work on the main thread instead of background threads, causing UI delays.

Key Result

Sealed classes in Kotlin provide efficient, compile-time checked type hierarchies with minimal runtime overhead, helping maintain smooth UI performance and clean code structure without impacting app size or startup time.

Practice

1. What is the main purpose of a sealed class in Kotlin?

easy

A. To replace interfaces completely

B. To allow unlimited subclassing from any package

C. To create anonymous classes only

D. To restrict class inheritance to a fixed set of subclasses

Solution

1. Step 1: Understand sealed class inheritance

   A sealed class restricts which classes can inherit from it, limiting subclasses to those defined in the same file.

2. Step 2: Compare with other class types

   Unlike open classes, sealed classes do not allow unlimited subclassing, ensuring all subclasses are known at compile time.

3. Final Answer:

   To restrict class inheritance to a fixed set of subclasses -> Option D

4. Quick Check:

   Sealed class = fixed subclass set [OK]

Hint: Sealed classes limit subclasses to known types only [OK]

Common Mistakes:

• Thinking sealed classes allow any subclass anywhere
• Confusing sealed classes with abstract classes
• Assuming sealed classes create anonymous classes

2. Which of the following is the correct syntax to declare a sealed class named Result in Kotlin?

easy

A. sealed Result class {}

B. sealed class Result {}

C. class sealed Result {}

D. sealed interface Result {}

Solution

1. Step 1: Recall sealed class declaration syntax

   The keyword sealed precedes class followed by the class name and braces.

2. Step 2: Check each option

   sealed class Result {} matches the correct syntax. Options B and C have wrong keyword order. sealed interface Result {} declares a sealed interface, not a sealed class.

3. Final Answer:

   sealed class Result {} -> Option B

4. Quick Check:

   sealed class syntax = "sealed class Name {}" [OK]

Hint: sealed class always starts with 'sealed class' keywords [OK]

Common Mistakes:

• Swapping 'sealed' and 'class' keywords
• Using 'sealed interface' instead of 'sealed class'
• Omitting braces after class name

3. Given the sealed class and when expression below, what will be printed?

sealed class Response {
  object Success : Response()
  object Error : Response()
}

fun handle(response: Response) {
  when(response) {
    is Response.Success -> println("Success")
    is Response.Error -> println("Error")
  }
}

handle(Response.Success)

medium

A. Nothing is printed

B. Error

C. Success

D. Compile-time error

Solution

1. Step 1: Identify the passed object type

   The function is called with Response.Success, which matches the first when branch.

2. Step 2: Check the when branches

   The when expression prints "Success" for Response.Success and "Error" for Response.Error.

3. Final Answer:

   Success -> Option C

4. Quick Check:

   Response.Success triggers "Success" print [OK]

Hint: Match sealed subclasses exactly in when to get correct output [OK]

Common Mistakes:

• Confusing Success and Error outputs
• Forgetting to call the function with correct subclass
• Expecting compile error due to sealed class

4. What is wrong with this sealed class declaration?

sealed class State {}
class Loading : State()
class Success : State()
class Error : State()

medium

A. Subclasses must be declared inside the sealed class file

B. Sealed classes cannot have subclasses

C. Subclasses must be objects, not classes

D. Sealed class must be abstract

Solution

1. Step 1: Recall sealed class subclass rules

   All subclasses of a sealed class must be declared in the same file as the sealed class.

2. Step 2: Analyze the code snippet

   The subclasses Loading, Success, Error are declared separately after the sealed class. This violates the rule because direct subclasses of a sealed class must be declared in the same file as the sealed class.

3. Final Answer:

   Subclasses must be declared inside the sealed class file -> Option A

4. Quick Check:

   Sealed subclasses must be in same file [OK]

Hint: Keep all sealed subclasses in the same file [OK]

Common Mistakes:

• Declaring subclasses in different files
• Thinking sealed classes cannot have subclasses
• Confusing sealed classes with abstract classes

5. You want to represent a network request state with a sealed class NetworkState having Loading, Success with data, and Error with message. Which is the best way to define Success and Error subclasses?

hard

A. Use data classes with properties inside the sealed class

B. Use object declarations for all subclasses

C. Use abstract classes for Success and Error

D. Use interfaces for Success and Error

Solution

1. Step 1: Understand subclass data needs

   Success needs to hold data, and Error needs to hold a message, so they require properties.

2. Step 2: Choose subclass type

   Data classes are ideal for subclasses with properties because they provide equals, hashCode, and toString automatically.

3. Final Answer:

   Use data classes with properties inside the sealed class -> Option A

4. Quick Check:

   Data classes hold data in sealed subclasses [OK]

Hint: Use data classes for sealed subclasses with data [OK]

Common Mistakes:

• Using object for subclasses needing data
• Using abstract classes unnecessarily
• Using interfaces instead of sealed subclasses