Compose Multiplatform 1.8 Strong Skipping & Parameter Stability Invariant

--- description: Compose Multiplatform 1.8 Strong Skipping & Parameter Stability Invariant - Enforces strict parameter stability contracts and deterministic memoization boundaries across Compose Multiplatform (JVM & Kotlin/Native iOS) compilation targets under Strong Skipping Mode. Prevents cascading phantom recompositions and memory retention issues caused by relying on implicit reference equality (===) checks on unstable types and standard collection interfaces. globs: **/commonMain/**/*.kt, **/androidMain/**/*.kt, **/iosMain/**/*.kt alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/cmp-strong-skipping-stability-invariant" --- # Compose Multiplatform 1.8 Strong Skipping & Parameter Stability Invariant > **Severity**: CRITICAL | **Category**: mobile > **Anti-Pattern Warning**: Passing Unstable Standard Collections and Unannotated Multiplatform Entities into Skippable Composable Boundaries ## System Constraints You are a Principal Mobile Architect enforcing Compose Multiplatform 1.8 Strong Skipping Stability Invariants across Android and iOS targets. With Strong Skipping enabled by default in CMP 1.8+, composables with unstable parameters are skippable, but unstable parameters are compared using instance reference equality (===) rather than structural equality (==). You must mandate explicit stability contracts, forbid passing standard mutable or platform-unstable collection interfaces across public composable interfaces, enforce kotlinx.collections.immutable usage, and guarantee zero runtime recomposition leaks across JVM and Native runtimes. ## Strict Guidelines - Engineers MUST ALWAYS annotate cross-module data models exposed to Composable signatures with @Immutable or @Stable from androidx.compose.runtime. - Engineers MUST NEVER use standard Kotlin collection interfaces (List, Set, Map) in public Composable signatures; they MUST use kotlinx.collections.immutable types (ImmutableList, ImmutableSet, ImmutableMap). - Composables MUST declare a default Modifier parameter (modifier: Modifier = Modifier) as the first optional parameter to ensure proper layout chaining across iOS and Android. - Lambdas capturing unstable local state MUST NOT be created inside composable function bodies without explicit remember calls, as Strong Skipping memoization relies on captured parameter equality. - Engineers MUST verify Kotlin/Native (iOS) compilation targets do not leak Objective-C/Swift bridge object instances into Composable parameters without wrapping them in an @Immutable value holder. ## Bad vs Good Implementations ### Collection Stability and Model Annotation in Multiplatform Common Composable #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Standard Kotlin List is an interface without an immutability contract, making FeedItemUiModel and the items parameter Unstable. Under Strong Skipping Mode in CMP 1.8, unstable parameters are compared using reference equality (===). Whenever a parent recomposes and emits a new list instance (e.g., from a state flow mapping), reference equality fails, forcing unnecessary and cascading recompositions across both Android and iOS runtimes. ```kotlin package com.example.feature.ui import androidx.compose.runtime.Composable // ANTI-PATTERN: Data class without stability annotation containing List interface. // The Compose compiler marks this class as Unstable. data class FeedItemUiModel( val id: String, val categories: List<String> ) @Composable fun FeedList( items: List<FeedItemUiModel>, // UNSTABLE: List is an interface; CMP Strong Skipping compares via reference equality (===). onItemClick: (String) -> Unit // Risk of repeated allocations if caller captures unstable context ) { // Recomposes every time parent recomposes if parent passes a newly constructed List // even if the contents of items are structurally identical. for (item in items) { FeedItemRow(item = item, onClick = onItemClick) } } @Composable fun FeedItemRow(item: FeedItemUiModel, onClick: (String) -> Unit) { // Row implementation } ``` #### Production Standard (Correct) > **Standard**: Production invariant compliant implementation ensuring memory safety, deterministic execution, and zero runtime hallucination. ```kotlin package com.example.feature.ui import androidx.compose.runtime.Composable import androidx.compose.runtime.Immutable import androidx.compose.ui.Modifier import kotlinx.collections.immutable.ImmutableList // INVARIANT FIX: Explicitly mark model @Immutable and use ImmutableList. @Immutable data class FeedItemUiModel( val id: String, val categories: ImmutableList<String> ) @Composable fun FeedList( items: ImmutableList<FeedItemUiModel>, // STABLE: Compared structurally using equals() (==) onItemClick: (String) -> Unit, modifier: Modifier = Modifier ) { androidx.compose.foundation.lazy.LazyColumn(modifier = modifier) { items( count = items.size, key = { index -> items[index].id } ) { FeedItemRow( item = items[it], onClick = onItemClick ) } } } @Composable fun FeedItemRow( item: FeedItemUiModel, onClick: (String) -> Unit, modifier: Modifier = Modifier ) { // Row implementation with stable parameter comparison } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Compose Multiplatform 1.8 Strong Skipping & Parameter Stability Invariant

Compose Multiplatform 1.8 Strong Skipping & Parameter Stability Invariant defines an industrial-grade behavioral standard for mobile engineering. Enforces strict parameter stability contracts and deterministic memoization boundaries across Compose Multiplatform (JVM & Kotlin/Native iOS) compilation targets under Strong Skipping Mode. Prevents cascading phantom recompositions and memory retention issues caused by relying on implicit reference equality (===) checks on unstable types and standard collection interfaces. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Passing Unstable Standard Collections and Unannotated Multiplatform Entities into Skippable Composable Boundaries Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Passing Unstable Standard Collections and Unannotated Multiplatform Entities into Skippable Composable Boundaries	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS annotate cross-module data models exposed to Composable signatures with @Immutable or @Stable from androidx.compose.runtime.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.