Top 30 Advanced Mobile Dev Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   What is the primary effect of enabling inline requires in a React Native app?

   • aIt defers a module's evaluation until the first time it is actually used
   • bIt removes unused exports from the bundle through tree shaking
   • cIt moves all module loading onto a background thread automatically
   • dIt compiles JavaScript to native machine code ahead of time
   Show the answer

   Answer: a · It defers a module's evaluation until the first time it is actually used

   Inline requires transform top-level imports so a module is evaluated lazily on first use, cutting startup work. It does not compile to machine code (that is closer to Hermes bytecode) nor perform tree shaking, which is a separate bundler concern.

   Read the full bite: Improving React Native startup time

2. Question 2 of 30

   When a native module method reads a live device value to return to JavaScript, why should it use a Promise or callback rather than a direct return?

   • aBecause Promises are required to register the module in the package list
   • bBecause native code cannot return primitive values to JavaScript at all
   • cBecause synchronous returns are blocked by the Metro bundler
   • dBecause crossing the native-to-JS boundary is asynchronous, so results are delivered via promise or callback
   Show the answer

   Answer: d · Because crossing the native-to-JS boundary is asynchronous, so results are delivered via promise or callback

   Values crossing from native into JavaScript are delivered asynchronously, so a Promise or callback is the correct pattern. Native code can return constants synchronously via getConstants, and package registration is unrelated to whether methods are async.

   Read the full bite: Building a native module from scratch

3. Question 3 of 30

   Why does indexing a Swift String by an integer like myString[5] not compile, unlike in many other languages?

   • aInteger subscripting was removed only for security reasons and may return later
   • bString.Index is just an alias for Int but Apple hid the operator
   • cCharacters are variable-width grapheme clusters, so an integer offset cannot give O(1) or unambiguous access
   • dSwift strings are immutable, so any subscript access is disallowed
   Show the answer

   Answer: c · Characters are variable-width grapheme clusters, so an integer offset cannot give O(1) or unambiguous access

   Swift Characters are extended grapheme clusters of varying byte length, so an integer offset is neither constant-time nor meaningful, which is why String.Index is opaque. Immutability is unrelated, and String.Index is not an Int alias.

   Read the full bite: Why can't you subscript a Swift String with an Int?

4. Question 4 of 30

   What is the primary effect of marking a Swift function parameter with @autoclosure?

   • aIt wraps the argument expression in a closure so it evaluates lazily only when the function invokes it
   • bIt automatically retains the argument to prevent deallocation
   • cIt forces the argument expression to evaluate before the call for thread safety
   • dIt allows the parameter to accept any type without generics
   Show the answer

   Answer: a · It wraps the argument expression in a closure so it evaluates lazily only when the function invokes it

   @autoclosure defers evaluation by wrapping the expression in a closure the function may or may not call, as with assert and ??. It does not force eager evaluation, manage retention, or relax type checking.

   Read the full bite: What is @autoclosure and when is it useful?

5. Question 5 of 30

   When a variable is declared as dynamic, why does calling toIntOrDefault on it fail to compile?

   • aBecause Dart resolves extensions at runtime using the receiver's actual type, and dynamic receivers have no determinable runtime type
   • bBecause extension methods are resolved statically and dynamic bypasses static type information
   • cBecause dynamic variables must be cast to String before any extension methods can be invoked
   • dBecause extensions mutate the original class definition, and dynamic instances are excluded from such mutations
   Show the answer

   Answer: b · Because extension methods are resolved statically and dynamic bypasses static type information

   The card explains that extension methods are static sugar resolved at compile time based on the declared type, so dynamic variables bypass static extension resolution. Option A is tempting because it uses precise-sounding terminology, but it incorrectly claims runtime resolution, which contradicts the fundamental static nature of Dart extensions.

   Read the full bite: What are Dart extension methods? Implement toIntOrDefault on String.

6. Question 6 of 30

   To model a state machine where each state might carry unique, type-specific data (e.g., a success state holding a user object, an error state holding a message), which Kotlin construct is most appropriate?

   • aAn enum class
   • bA sealed class
   • cAn interface
   • dAn abstract class with a private constructor
   Show the answer

   Answer: b · A sealed class

   Sealed classes are specifically designed for representing restricted hierarchies where subclasses can be distinct types (like data classes or objects) and hold different associated data. Enum classes cannot hold different types of data for each constant, making them unsuitable for states with unique payloads.

   Read the full bite: When to use a sealed class instead of an enum?

7. Question 7 of 30

   To model a network request's state—`Loading`, `Success` (with data), or `Error` (with a message)—which Kotlin construct is most suitable?

   • aAn enum, because it represents a fixed set of constants, which is what these states are.
   • bA sealed interface, because it provides maximum flexibility if the states need to inherit from other classes.
   • cAn enum with nullable properties for both data and an error message to accommodate all states.
   • dA sealed class, because each of its subclasses can carry different data types specific to that state.
   Show the answer

   Answer: d · A sealed class, because each of its subclasses can carry different data types specific to that state.

   A sealed class is ideal because its subclasses can represent states with different associated data (e.g., data for Success, a message for Error) in a type-safe way. An enum is a set of constants of the same type and cannot elegantly model states with different data requirements.

   Read the full bite: When would you use a sealed class instead of an enum?

8. Question 8 of 30

   When modeling a closed set of UI states where Loading needs no data, Success carries a User, and Error carries a String, why is a sealed class preferable to an enum?

   • aEnums cannot implement interfaces or hold properties, limiting them to simple constant values
   • bEnum constants share a single constructor signature, making it awkward to attach different data to each state, whereas sealed subclasses can define their own parameters
   • cA plain data class hierarchy solves the same problem more simply, since sealed classes add unnecessary restrictions on inheritance
   • dSealed classes guarantee that when expressions do not need an else branch, while enum-based when expressions always require one
   Show the answer

   Answer: b · Enum constants share a single constructor signature, making it awkward to attach different data to each state, whereas sealed subclasses can define their own parameters

   The correct answer captures the core structural distinction: enums force all constants into one uniform signature, while sealed subclasses can each carry heterogeneous state. Option C is tempting because data classes appear to model payloads well, but without the sealed modifier the hierarchy is open, so when expressions lose compile-time exhaustiveness and external code could add unhandled states.

   Read the full bite: When would you use a sealed class instead of an enum?

9. Question 9 of 30

   You must convert a nullable `user` into a `Session`, logging the user's ID first. Which implementation is the most idiomatic and correct for the function body?

   • auser?.let { log(it.id) }; return Session(user!!)
   • breturn user?.let { log(it.id); Session(it) }
   • creturn user?.apply { log(this.id); Session(this) }
   • dif (user != null) { log(user.id); return Session(user) } else { return null }
   Show the answer

   Answer: b · return user?.let { log(it.id); Session(it) }

   `let` is ideal as it executes a block on a non-null object and returns the lambda's result, which is the new `Session` object. The `apply` function is a tempting but incorrect alternative because it would return the original `user` object, not the `Session`.

   Read the full bite: Compare and contrast Kotlin's `apply` and `let` scope functions

10. Question 10 of 30

    Given val result = name?.apply { trim().length } where name is String?, what is the inferred type of result and why?

    • aUnit because apply is intended for configuration and does not propagate lambda results
    • bInt? because the lambda's last expression is an Int and the safe call preserves nullability
    • cString? because apply always returns the original receiver object, ignoring the lambda's final value
    • dString because the safe call on a non-null execution path eliminates the nullability of the returned receiver
    Show the answer

    Answer: c · String? because apply always returns the original receiver object, ignoring the lambda's final value

    apply returns the context object itself, so the expression yields String?, not the lambda's Int result. Option B confuses apply with let, which returns the lambda's final value.

    Read the full bite: Compare Kotlin apply and let scope functions

11. Question 11 of 30

    Which Kotlin scope function is most idiomatic for configuring an object's properties and then returning the configured object itself?

    • aapply
    • balso
    • crun
    • dlet
    Show the answer

    Answer: a · apply

    apply is specifically designed for object configuration; it executes a block of code on the receiver (available as 'this') and returns the receiver object itself. In contrast, let returns the result of its lambda, making it unsuitable for directly returning the configured object.

    Read the full bite: Compare and contrast `apply` and `let` scope functions

12. Question 12 of 30

    What is the primary advantage of using a sealed class instead of an enum for exhaustiveness-checked state machines in Dart 3?

    • aSealed classes guarantee exhaustiveness through runtime exception throwing rather than static analysis.
    • bSealed classes are just performance-optimized abstract classes with no additional type safety over enums.
    • cSealed classes let each subtype carry distinct constructor parameters and fields while keeping exhaustive switch safety.
    • dSealed classes allow subtypes to be declared in any library while preserving compile-time exhaustiveness.
    Show the answer

    Answer: c · Sealed classes let each subtype carry distinct constructor parameters and fields while keeping exhaustive switch safety.

    Sealed classes enable algebraic data types where each variant holds distinct payload data while the compiler verifies exhaustive handling, unlike enums which share a single shape. Distractor A is wrong because sealed subclasses must remain in the same library for the compiler to prove exhaustiveness; adding them elsewhere breaks that guarantee.

    Read the full bite: Explain Dart switch exhaustiveness for enums versus sealed classes

13. Question 13 of 30

    What is the fundamental reason `reified` type parameters can only be used with `inline` functions in Kotlin?

    • ainline functions guarantee that the generic type parameter is always known at compile-time, which reified then uses to generate specific type-safe bytecode.
    • binline functions prevent the creation of lambda objects, which would otherwise block reified from accessing type information.
    • cinline allows the compiler to substitute the concrete type argument for the generic parameter directly into the bytecode at the call site, bypassing JVM type erasure.
    • dreified types require the performance benefits of inline to efficiently perform type checks at runtime without significant overhead.
    Show the answer

    Answer: c · inline allows the compiler to substitute the concrete type argument for the generic parameter directly into the bytecode at the call site, bypassing JVM type erasure.

    Option C correctly identifies that inline enables the compiler to replace the generic type with its concrete type at the call site, thus preserving it from JVM type erasure for runtime access. Option D is a common misconception; while inline offers performance, its necessity for reified is about enabling type information availability, not just optimizing checks.

    Read the full bite: What problem does `inline` solve, and how does `reified` relate?

14. Question 14 of 30

    Why must a Kotlin function be declared `inline` to use a `reified` type parameter?

    • aTo ensure the function call avoids creating a lambda object, which would otherwise interfere with runtime type checks.
    • bBecause `reified` checks are computationally expensive and require the performance optimizations that `inline` provides.
    • cTo prevent the JVM's type erasure from removing the generic type information from the function's signature in the compiled class file.
    • dBecause inlining moves the function's bytecode to the call site, where the compiler can access the concrete type argument.
    Show the answer

    Answer: d · Because inlining moves the function's bytecode to the call site, where the compiler can access the concrete type argument.

    The `reified` keyword needs to know the actual type at runtime, which is normally erased by the JVM. The `inline` keyword enables this by copying the function's code to the call site, where the compiler knows the concrete type (e.g., `String`) and can substitute it directly into the bytecode. Option C is incorrect because `inline` doesn't prevent type erasure in general; it provides a clever workaround for a specific call.

    Read the full bite: Explain `inline` and `reified` in Kotlin

15. Question 15 of 30

    In a Dart isolate, what is the consequence of a microtask that keeps rescheduling new microtasks recursively?

    • aThe event queue is starved until the recursive microtask chain ends
    • bThe recursive microtasks are moved to the event queue to prevent starvation
    • cThe event loop alternates between one microtask and one event queue task
    • dThe isolate crashes with a stack overflow after 1000 recursive microtasks
    Show the answer

    Answer: a · The event queue is starved until the recursive microtask chain ends

    The event loop always drains the entire microtask queue before processing any event queue tasks, so a self-rescheduling microtask chain blocks the event queue indefinitely. Option C is wrong because Dart does not interleave the two queues one-for-one.

    Read the full bite: Explain Dart's event loop, microtask queue, event queue, and await behavior

16. Question 16 of 30

    Why does a reified type parameter require the enclosing function to be marked inline?

    • aBecause reified parameters implicitly create a Class reference, which inline functions can pass without allocation overhead.
    • bBecause the JVM preserves generic type information only for methods flagged as inline by the Kotlin compiler.
    • cBecause inlining copies the body to the call site so the compiler can substitute the concrete type into bytecode despite JVM erasure.
    • dBecause inline functions execute faster, and reified type checks would otherwise be too slow at runtime.
    Show the answer

    Answer: c · Because inlining copies the body to the call site so the compiler can substitute the concrete type into bytecode despite JVM erasure.

    Inlining copies the function body to each call site, letting the compiler replace the type parameter with the exact type argument in the generated bytecode and bypass JVM erasure. Distractor D is wrong because reified does not merely inject a Class reference; it performs compile-time type substitution to enable runtime type checks.

    Read the full bite: What does inline solve for higher-order functions, and what is reified?

17. Question 17 of 30

    Why does a nested Text inherit color and fontSize from its parent while a nested View inherits nothing?

    • aBoth inherit equally, but View inheritance only applies to backgroundColor
    • bReact Native implements the full CSS cascade but disables it for Views to save memory
    • cText maps to platform attributed-text where spans inherit attributes, while Views are independent boxes with no general style cascade
    • dView inheritance is simply a bug that has not been fixed yet
    Show the answer

    Answer: c · Text maps to platform attributed-text where spans inherit attributes, while Views are independent boxes with no general style cascade

    Text inheritance reflects native attributed-text systems where text runs cascade attributes; Views are deliberately independent layout boxes with no cascade. React Native does not implement a general CSS cascade, so the first and last options are wrong.

    Read the full bite: Why Text inherits styles but View does not

18. Question 18 of 30

    When implementing Copy-on-Write for a custom Swift struct, what must happen inside a mutating method before modifying the backing reference?

    • aChange the backing storage to a struct so that the compiler automatically enforces value semantics without a uniqueness check
    • bVerify isKnownUniquelyReferenced on the backing instance and clone it if the result is false
    • cDeep copy the backing buffer whenever the outer struct is assigned to prevent sharing from the start
    • dCheck isKnownUniquelyReferenced and clone the buffer only when the check returns true, because that indicates multiple owners
    Show the answer

    Answer: b · Verify isKnownUniquelyReferenced on the backing instance and clone it if the result is false

    Before mutating, you must check isKnownUniquelyReferenced and clone when it returns false, indicating shared ownership. Answer A dangerously inverts the boolean logic, while C and D reflect common misconceptions that either defeat reference sharing or eliminate the optimization entirely.

    Read the full bite: Explain Copy-on-Write in Swift and implement it for custom structs

19. Question 19 of 30

    Under the New Architecture, what is the most accurate primary reason StyleSheet.create outperforms inline literal styles in long lists?

    • aIt sends styles synchronously while inline styles are always asynchronous
    • bIts numeric bridge IDs eliminate all serialization, which is still the dominant factor today
    • cIt provides stable object references, avoiding per-render allocations and reducing diff and GC pressure
    • dIt compiles styles into native code that bypasses JavaScript entirely
    Show the answer

    Answer: c · It provides stable object references, avoiding per-render allocations and reducing diff and GC pressure

    The durable benefit is referential stability that cuts allocations and garbage during frequent list re-renders. The bridge-ID serialization story is much diminished under Fabric and JSI, so attributing the gain primarily to it today overstates the mechanism.

    Read the full bite: How StyleSheet.create reduces styling overhead

20. Question 20 of 30

    In Swift structured concurrency, what distinguishes a Task started with Task.init from a child task created via async let?

    • aThey differ only in syntax; both produce the same underlying closure-based execution model
    • bTask.init inherits the parent's priority and cancellation, while async let tasks are detached and independent
    • cTask.init runs on a dedicated OS thread, while async let tasks share the cooperative thread pool
    • dTask.init creates an unstructured task without parent-child cancellation propagation, while async let creates a structured child task
    Show the answer

    Answer: d · Task.init creates an unstructured task without parent-child cancellation propagation, while async let creates a structured child task

    Task.init creates an unstructured task outside the parent-child tree, whereas async let creates a structured child task bound to its parent's scope and cancellation. Claiming they differ only in syntax repeats the common misconception that async/await is mere syntactic sugar, ignoring the runtime contract of structured concurrency.

    Read the full bite: How does Swift async/await improve on completion handlers?

21. Question 21 of 30

    In Dart, given class C extends S with M1, M2 where all define foo(), if C overrides foo() and calls super.foo(), which implementation does the call reach?

    • aIt reaches M2's implementation because the rightmost mixin becomes the immediate superclass.
    • bIt reaches M1's implementation because Dart applies mixins left-to-right.
    • cIt produces a compile-time ambiguity error since both mixins define the same method.
    • dIt reaches S's implementation, bypassing the mixins entirely.
    Show the answer

    Answer: a · It reaches M2's implementation because the rightmost mixin becomes the immediate superclass.

    Dart applies mixins left-to-right, so the last mixin becomes the immediate superclass and shadows earlier ones; thus super.foo() from C resolves to M2. Distractor B confuses application order with inheritance priority, but left-to-right application means M2 is layered on top of M1, not beneath it.

    Read the full bite: How does Dart resolve mixin method conflicts and application order?

22. Question 22 of 30

    Which statement accurately distinguishes the backpressure behavior of buffer(), conflate(), and collectLatest() in Kotlin Flow?

    • abuffer() creates a new thread for concurrent emission, conflate() cancels the collector, and collectLatest() drops values silently
    • bbuffer() drops the oldest values once full, conflate() suspends the emitter, and collectLatest() buffers emissions in a queue
    • cAll three operators suspend the upstream emitter by default, differing only in how they allocate coroutine dispatchers
    • dbuffer() suspends the emitter when full, conflate() silently drops intermediate values, and collectLatest() cancels the active collector
    Show the answer

    Answer: d · buffer() suspends the emitter when full, conflate() silently drops intermediate values, and collectLatest() cancels the active collector

    buffer() suspends the producer when its Channel is full rather than dropping values, conflate() silently discards intermediate emissions while the collector runs, and collectLatest() cancels the active collection block on each new emission. Option B is tempting because it uses the correct vocabulary but assigns the behaviors to the wrong operators.

    Read the full bite: How do buffer, conflate, and collectLatest manage Kotlin Flow backpressure?

23. Question 23 of 30

    When processing a rapid stream of UI events, where each event triggers an expensive, cancellable background task, which Flow operator ensures only the latest event's task runs, cancelling any prior in-progress tasks?

    • aconflate()
    • bRelying on Flow's default backpressure mechanism
    • ccollectLatest()
    • dbuffer()
    Show the answer

    Answer: c · collectLatest()

    collectLatest() is designed to cancel the processing block for a previous item if a new one is emitted, restarting the operation with the latest data. In contrast, conflate() only drops intermediate values, ensuring the collector receives the most recent value, but it does not cancel any long-running work already initiated for a prior item.

    Read the full bite: Explain backpressure in Kotlin Flows and its management operators

24. Question 24 of 30

    A Flow emits frequent updates, but the collector's work is slow. To ensure resources are only spent on the latest item by cancelling work on stale ones, which approach is best?

    • aUse `buffer()` to allow the producer to emit freely into a channel without waiting for the slow collector.
    • bUse no operator; the default suspension behavior will slow down the producer to match the collector, which is the most efficient backpressure.
    • cUse `collectLatest()` to cancel the collector's current work block as soon as a new item is emitted from the producer.
    • dUse `conflate()` to drop intermediate items, ensuring the collector only starts work on the most recent item when it becomes available.
    Show the answer

    Answer: c · Use `collectLatest()` to cancel the collector's current work block as soon as a new item is emitted from the producer.

    `collectLatest` is correct because it cancels the collector's ongoing work when a new value arrives, preventing wasted resources on stale data. `conflate` is a common misconception; it drops values on the producer side but does not cancel any ongoing work in the collector.

    Read the full bite: Explain backpressure in Kotlin Flows and its management operators

25. Question 25 of 30

    A coroutine executes a CPU-intensive `while` loop without any suspend function calls. If its job is cancelled, what is required for the coroutine to actually stop?

    • aThe loop must periodically check the `isActive` property of the coroutine context and manually exit.
    • bNothing; the `cancel()` call interrupts the underlying thread, which immediately terminates the loop's execution.
    • cThe coroutine will stop automatically once it finishes the current iteration of the `while` loop.
    • dA `CancellationException` will be thrown automatically on the next loop iteration, unwinding the stack.
    Show the answer

    Answer: a · The loop must periodically check the `isActive` property of the coroutine context and manually exit.

    Coroutine cancellation is cooperative, not preemptive. For code without suspension points, like a tight loop, the coroutine must manually check its `isActive` state to participate in cancellation.

    Read the full bite: How does coroutine cancellation work internally?

26. Question 26 of 30

    Why does a CPU-intensive while-loop inside a coroutine ignore job.cancel() and keep running?

    • aThe suspend modifier on the function prevents cancellation from affecting non-suspending code
    • bThe cancel() call interrupts the underlying thread, which the loop ignores unless handled
    • cThe coroutine runtime defers throwing CancellationException until the current computation finishes
    • dThe loop never hits a suspension point where the coroutine checks its Job state
    Show the answer

    Answer: d · The loop never hits a suspension point where the coroutine checks its Job state

    Kotlin coroutine cancellation is cooperative, so a tight loop without suspension points never checks the Job's cancelling state and continues running. Distractor B is wrong because cancel() does not forcibly interrupt the underlying thread; it only sets a flag that standard suspend functions check at suspension points.

    Read the full bite: Describe coroutine cancellation mechanics and cooperative suspend functions

27. Question 27 of 30

    Which statement accurately describes how job.cancel() influences a running coroutine?

    • aIt blocks until the coroutine reaches a safe point and then gracefully shuts it down.
    • bIt sets a flag, causing cooperative suspend functions or explicit isActive checks to throw a CancellationException.
    • cIt forces the coroutine to yield its execution, allowing other coroutines to run until it is eventually garbage collected.
    • dIt immediately terminates the coroutine's execution by stopping the underlying thread.
    Show the answer

    Answer: b · It sets a flag, causing cooperative suspend functions or explicit isActive checks to throw a CancellationException.

    The correct answer (B) reflects that cancellation is cooperative: job.cancel() sets a flag, and the coroutine itself must check this flag (via suspend functions or isActive) to throw a CancellationException. Option (D) is a common misconception, as coroutine cancellation does not directly stop the underlying thread; it's an abstraction above threads.

    Read the full bite: How does coroutine cancellation work internally?

28. Question 28 of 30

    Why can a Reanimated and Gesture Handler animation stay smooth even when the JavaScript thread is blocked?

    • aReanimated pauses the animation until the JS thread is free, then fast-forwards it
    • bIt is identical to the Animated API native driver, which also runs all gesture logic in JS
    • cThe JS thread is given highest priority so it never actually blocks during animation
    • dGesture tracking and worklet-driven animation run on the native UI thread via shared values, independent of the JS thread per frame
    Show the answer

    Answer: d · Gesture tracking and worklet-driven animation run on the native UI thread via shared values, independent of the JS thread per frame

    Worklets and shared values let per-frame gesture and animation work run on the UI thread, so a busy JS thread does not stall it. The Animated native driver is more limited and does not provide gesture-driven worklets, so equating them is incorrect.

    Read the full bite: Gesture Handler and Reanimated on the UI thread

29. Question 29 of 30

    What is the fundamental reason Kotlin's `reified` type parameters must be used with `inline` functions?

    • ainline functions ensure that reified types are stored in a special runtime type information table accessible by reflection.
    • bThe inline mechanism enables the compiler to replace the generic type parameter with the actual type at the call site before JVM type erasure occurs.
    • creified parameters require inline to bypass the JVM's type erasure mechanism entirely, making generics available at runtime.
    • dinline functions allow the compiler to generate and pass a Class object for the reified type implicitly at runtime.
    Show the answer

    Answer: b · The inline mechanism enables the compiler to replace the generic type parameter with the actual type at the call site before JVM type erasure occurs.

    Correct answer (B) states that `inline` allows the compiler to substitute the generic type with its concrete type at the call site, effectively baking the type information into the bytecode before JVM type erasure. Option C is incorrect because `reified` does not bypass JVM type erasure; instead, the compiler works around it by substituting the type during inlining.

    Read the full bite: Explain Kotlin's `reified` type parameters and their use case

30. Question 30 of 30

    Why can a reified type parameter be checked with is T at runtime despite JVM type erasure?

    • aThe compiler passes the type's Class object implicitly as a hidden parameter.
    • bType erasure is globally disabled for functions declared with the reified modifier.
    • cThe compiler substitutes the concrete type into the inlined body at each call site.
    • dThe JVM retains generic type metadata specifically for reified parameters.
    Show the answer

    Answer: c · The compiler substitutes the concrete type into the inlined body at each call site.

    Inline expansion lets the compiler replace T with the concrete type at the call site, emitting a real instanceof check. Option A is tempting but wrong because reified does not rely on reflection or pass a Class object; it works by bytecode substitution during compilation.

    Read the full bite: What is a reified type parameter in Kotlin?