Lessons from a production Android codebase

Cancellation in Kotlin Coroutines looks simple: cancel the Job, and the coroutine stops. In production, it is rarely that clean.

Cancellation is cooperative. Every suspend function, exception handler, callback bridge and child scope must carry the signal. Break one boundary, and work may continue after its owner is gone.

We saw the result in production: false error logs, empty results, stale Bluetooth work and a final save lost during logout. Nothing crashed. The app simply continued with the wrong state.

Cancellation is cooperative

Kotlin uses CancellationException to stop a coroutine. Functions such as delay and await check the Job and throw when it is cancelled.

val job = scope.launch {
 delay(5_000)
 updateState()
}
job.cancel()

Here, delay observes cancellation, so updateState is not called. Regular Kotlin code does not check automatically. It keeps running until the next cancellation point.

When cancellation becomes a failure

return try {
 repository.fetchNotifications()
} catch (error: Exception) {
 logger.error("Failed to load notifications", error)
 emptyList()
}

If the user leaves the screen, viewModelScope is cancelled and fetchNotifications throws CancellationException. The broad catch records a normal lifecycle event as a failure. It also returns emptyList, so the caller cannot distinguish cancellation from a successful query with no data.

runCatching has the same problem because it also catches CancellationException. Rethrow cancellation before handling other failures.

catch (error: CancellationException) {
 throw error
} catch (error: Exception) {
 logger.error("Failed to load notifications", error)
 emptyList()
}

In production, normal navigation becomes error telemetry. Empty values can appear as missing documents, notifications or time cards. Support sees missing data while the app reports a completed request.

Callback bridges can outlive the caller

suspend fun loadMessages() = suspendCoroutine { continuation ->
   chatClient.loadMessages { messages ->
   continuation.resume(messages)
 }
}

The function is suspend, but the bridge is not cancellable. If the SDK never calls back, the coroutine keeps waiting after its Job is cancelled.

Use suspendCancellableCoroutine and cancel the underlying request. A cancellable continuation alone is not enough; an Rx subscription or SDK callback can still run in the background.

suspendCancellableCoroutine { continuation ->
   val request = chatClient.loadMessages { messages ->
   if (continuation.isActive) {
     continuation.resume(messages)
    }
   }
   continuation.invokeOnCancellation {
     request.cancel()
   }
}

In production, chat, form or document work may outlive its screen and keep memory, network or database resources. The app remains open, but one workflow can hang or show stale state.

Blocking code can ignore cancellation

withContext(Dispatchers.IO) {
 repository.loadNotifications().blockingGet()
}

Dispatchers.IO moves the blocking call off the main thread. It does not make that call cancellable. The thread stays occupied until blockingGet returns.

Prefer a suspend API such as await. If unavoidable JVM code responds to thread interruption, runInterruptible can connect it to coroutine cancellation.

In production, the work continues after its result is useless and consumes IO capacity. If a blocking boundary reaches the main thread, it can become an ANR.

Work with no owner

fun onPacketReceived(bytes: ByteArray) {
   CoroutineScope(ioDispatcher).launch {
     packetChannel.send(Packet(bytes))
   }
}

Each packet creates a scope that is immediately discarded. Nothing can cancel the work on disconnect. Independent coroutines may also try to send at the same time.

Use one scope owned by the connection manager, then serialize sends with a Mutex.

private val packetSendMutex = Mutex()

fun onPacketReceived(bytes: ByteArray) {
   ownerScope.launch {
     packetSendMutex.withLock {
       packetChannel.send(Packet(bytes.copyOf()))
     }
   }  
}

The second coroutine waits while the first send holds the mutex

The mutex allows only one send at a time, even when send suspends. It does not preserve callback order: packet 2 may reach the lock first. If the protocol requires strict arrival order, enqueue packets before launching asynchronous work.

In production, work can continue after disconnect, and concurrent state changes can affect reconnect. The user sees an unreliable Bluetooth connection long after the callback that caused it.

Timeout as normal completion

withTimeout(timeout) {
   startBluetoothDiscovery()
   delay(timeout)
}

withTimeout ends by throwing TimeoutCancellationException. When timeout is expected, withTimeoutOrNull makes the result explicit. A callbackFlow should also use awaitClose to unregister the receiver when collection ends.

val device = withTimeoutOrNull(timeout) {
 discoverDevice()
}
if (device == null) stopDiscovery()

In production, discovery can stop without a clear result or recovery action. An expected timeout then looks like a connection failure.

Cancellation at the final step

During an account switch, the old user’s tokens had to be saved before logout changed the session. The original flow launched the save, then dispatched logout.

viewModelScope.launch {
 tokenStore.save(currentTokens)
}
dispatchLogout()

Logout cancels the scope before the token save completes

Keep both operations in the same coroutine. tokenStore.save suspends, so logout is dispatched only after the save completes.

viewModelScope.launch {
 tokenStore.save(currentTokens)
 dispatchLogout()
}

In production, a logout race can lose authentication state or unsynced data. The failure appears in the next session, far from the cancellation that caused it.

A cancelled scope stays cancelled

private val scope = CoroutineScope(SupervisorJob() + dispatcher)
fun clear() = scope.cancel()
fun startAgain() = scope.launch {
 syncData()
}

After clear, `startAgain()` launches into a cancelled scope, so syncData never runs. If the object is reusable, cancel its children or create a new scope for the next lifecycle.

private val parentJob = SupervisorJob()
private val scope = CoroutineScope(parentJob + dispatcher)
fun clear() = parentJob.cancelChildren()
fun startAgain() = scope.launch {
 syncData()
}

cancelChildren stops the current work but leaves parentJob active, so later launches can run. If clear ends the object’s lifecycle, keep scope.cancel() and create a new owner for the next lifecycle.

In production, one background subsystem can stop while the rest of the app remains healthy. Missing backend data appears later, with no crash pointing to the cause.

What these bugs cost

Cancellation bugs create two costs. False failures pollute reliability data. Silent cancellations stop one workflow while the rest of the app continues.

They also separate cause from symptom. A scope is cancelled during logout; the missing state appears at the next login. A packet survives disconnect; the failure appears during reconnect.

A static review cannot prove that a pattern caused an incident. It can show where the same failure is possible and where runtime tracing should begin.

Reviewing cancellation in production

• Can this catch receive CancellationException?
• Can cancellation return a valid-looking value?
• Who owns this scope, and when is it cancelled?
• Does cancellation stop the underlying callback or subscription?
• Does important work depend on a screen scope surviving?
• Can this object reuse a scope after cancelling it?
• Is blocking code hidden inside a coroutine?
• Is timeout an error or normal completion?
• Does serialization preserve the order required by the protocol?

References

Kotlin cancellation and timeouts; Kotlin suspendCancellableCoroutine; Kotlin callbackFlow; Kotlin channels; Kotlin limitedParallelism; Android coroutine best practices

The Ghost Work Left Behind by Cancelled Coroutines was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Jetpack Compose, we often see ViewModels that manually manage UI state, call load() from init, and update several properties whenever data changes.

This approach works, but it can introduce unnecessary boilerplate. As an application grows, keeping multiple pieces of state synchronized becomes increasingly difficult.

Kotlin Flow offers a more declarative alternative. By combining Flow operators with stateIn, we can define how UI state is derived from its inputs and let the stream handle updates.

ViewModel における stateIn の実力

The Hidden Cost of Manual State Updates

Consider a typical ViewModel:

class MyViewModel(
    private val repository: MyRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow(UiState())
    val uiState = _uiState.asStateFlow()

    init {
        load()
    }

    private fun load() {
        viewModelScope.launch {
            val items = repository.loadItems()

            _uiState.update {
                it.copy(items = items)
            }
        }
    }
}

This is a perfectly valid implementation. It is easy to understand, especially when loading data involves a one-time operation.

However, the ViewModel is responsible for several things:

• Starting the initial load.
• Updating the state after loading.
• Preserving unrelated state fields.
• Keeping the UI state consistent as more inputs are added.

As the screen becomes more complex, these responsibilities can lead to repetitive state-management code.

What if the repository already exposes a Flow of items? Do we still need to collect it manually and copy every update into another state holder?

Often, we do not.

Do We Really Need to Call load()?

A common Compose pattern is:

LaunchedEffect(Unit) {
    viewModel.load()
}

Another option is to call load() from the ViewModel’s init block.

Both approaches have legitimate uses. A user-triggered refresh, a one-time operation, or a request that depends on a specific event may need an explicit command.

But when the screen simply reflects data that is already represented by a Flow, manually initiating and synchronizing every update may be unnecessary.

The important distinction is between commands and state:

• Commands express what should happen.
• State describes what is currently true.

stateIn is particularly useful when UI state can be derived from an existing Flow rather than maintained through repeated imperative updates.

The Evolution of Flow Collection in Jetpack Compose

Let stateIn Turn a Flow into UI State

Suppose the repository exposes a stream of items:

interface MyRepository {
    val items: Flow<List<Item>>
}

The ViewModel can derive its UI state directly:

class MyViewModel(
    repository: MyRepository
) : ViewModel() {

    val uiState: StateFlow<UiState> = repository.items
        .map { items ->
            UiState(items = items)
        }
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5_000),
            initialValue = UiState()
        )
}

Notice what disappeared:

• No private MutableStateFlow for manually updating the same UI state.
• No init block to start collection.
• No explicit load() call just to copy repository emissions into UI state.
• No manual synchronization between repository data and the UI model.

Instead, the relationship is expressed directly:

Repository Flow

 ↓

map
 
 ↓

UiState

 ↓

stateIn

 ↓

StateFlow<UiState>

Whenever the repository emits a new list, the Flow produces a corresponding UiState.

stateIn converts the upstream Flow into a hot StateFlow, shares its latest value, and provides an initial value. The ViewModel exposes a state stream that the UI can observe.

This is the key benefit: the code describes how state is derived, instead of manually synchronizing it after every change.

Multiple Inputs, One Consistent UI State

The benefits become clearer when a screen depends on more than one input.

Imagine a list screen with a search query. The visible items depend on both the repository data and the query.

With manual state updates, the ViewModel must coordinate changes to both.

With Flow, the dependency is explicit:

class MyViewModel(
    repository: MyRepository
) : ViewModel() {

    private val query = MutableStateFlow("")

    val uiState: StateFlow<UiState> =
        combine(
            repository.items,
            query
        ) { items, query ->
            UiState(
                items = items.filter {
                    it.matches(query)
                },
                query = query
            )
        }.stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5_000),
            initialValue = UiState()
        )

    fun onQueryChanged(query: String) {
        this.query.value = query
    }
}

The UI action updates only the query input. It does not directly mutate the public uiState.

The derived state updates automatically when either input changes:

• The repository emits new items.
• The user changes the query.

There is no need to remember every place where the visible list must be recalculated.

The dependency is defined once, in code.

Keep Commands Explicit, State Declarative

This does not mean every operation should be represented as a Flow.

For example, submitting a form, deleting an item, or refreshing data in response to an explicit user action may require a command handled by the ViewModel.

The useful design principle is to avoid using imperative commands merely to keep derived state synchronized.

If UI state depends on several observable inputs, express that relationship with operators such as map and combine, then use stateIn when the UI needs a StateFlow.

The result is a clearer separation:

• Inputs represent data and user intent.
• Flow operators describe the relationships between inputs.
• stateIn exposes the derived result as a state holder.
• Compose renders the state.

This makes the ViewModel easier to reason about because dependencies are visible rather than hidden inside a sequence of state mutations.

Choose the Right Sharing Strategy

stateIn requires a sharing strategy. One common choice is:

SharingStarted.WhileSubscribed(5_000)

This starts upstream collection when the first subscriber appears and stops it five seconds after the last subscriber disappears.

The timeout can help avoid stopping and restarting the upstream stream during brief gaps in UI subscription.

However, stopping collection is not the same as guaranteeing that a network request will be repeated when the screen returns. Whether a request runs again depends on how the upstream Flow is implemented.

Also, stateIn does not fetch data by itself. It shares and retains values emitted by its upstream Flow.

Choose the sharing strategy based on the lifecycle and behavior you want, not simply because it is a common pattern.

Mutable State Still Has Its Place

MutableStateFlow remains useful for inputs and state that genuinely needs to be changed imperatively.

For example:

private val query = MutableStateFlow("")

The query is an input controlled by user interaction. Updating it is appropriate.

The derived uiState, on the other hand, does not need to be independently mutable when it can be calculated from the repository data and query.

A practical rule is:

• Use MutableStateFlow for mutable inputs.
• Use Flow operators to derive state from those inputs.
• Use stateIn to expose the resulting stream as StateFlow.

This is not about eliminating mutable state. It is about putting mutability where it belongs.

Conclusion: Let stateIn Do the State Management

stateIn is more than a convenient way to convert a Flow into a StateFlow. Used with operators such as map and combine, it helps make the ViewModel’s state model declarative.

Instead of manually collecting data, copying values, and synchronizing related fields, we can express the dependencies between inputs and UI state directly.

The approach is especially valuable when a screen’s state is derived from multiple observable sources.

Keep commands explicit. Keep state declarative. Let Flow define the dependencies, and use stateIn to expose the result as UI state whenever that is the right fit.

• 10 Flow Operators for Building a Declarative UiState
• The Beauty of stateIn in ViewModel

Enjoyed this article? Here’s how you can support my work:

• 👏 Clap (up to 50 times!) if you found this insightful.
• 👤 Follow me and turn on notifications (🔔) so you never miss the next deep dive.
• 📧 Subscribe to get my latest stories delivered directly to your inbox.

You can find all my articles on Android architecture, Jetpack Compose, and Kotlin in this curated reading list.

The Power of stateIn in ViewModel was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

When a user at Tilt says “my bid didn’t go through”, what actually happened? The app read the current user, sent a GraphQL mutation, maybe retried it, maybe refreshed a token, and the backend called two more services. Before this summer I could see pieces of that in different tools, but never the whole thing as one story.

This article is about how I designed and shipped mobile distributed tracing for Tilt’s Android and iOS apps, using OpenTelemetry in a Kotlin Multiplatform module and Grafana on the other end. The short version: the trace root is the business operation, not the HTTP call, and because of the pipeline from Part 1, opting a function into tracing costs one argument:

.buildOnce(ShopperTracedOperation.MakeBid(roomId, auctionId, bidValue))

The longer version includes an alpha SDK, a coroutine context that will not move, and a few bugs that nobody would have found without traces.

What I could not see

Tilt is a live shopping app. Sellers run live auctions, and an auction often lasts only a few seconds. If placing a bid hangs, the bid does not count, and the user does not care whether it was their network, the app or the backend.

When complaints like “the auction froze” came in, diagnosing them was slow and largely guesswork. The app had a small per-request performance tracker that emitted start, end and error events. It was a flat list of timings: no parent and child, no trace ID, no link to anything the backend saw. And by then nothing was consuming it anyway.

The deeper problem was the unit of measurement. In the shared module, business operations live in repositories, and a single repository function often combines several queries and subscriptions. Tracing each GraphQL operation on its own would give me accurate numbers for the wrong thing. Tracing a whole app session would give me one giant trace that nobody can investigate.

So the goal became: one trace per business operation. Placing a bid, loading the home feed, sending a phone verification code. Each one should be a single waterfall, from the moment the app starts the work to the last backend service that touched it. And it should carry the IDs people actually ask about: the user, the room, the auction.

I also set myself one constraint early on. Other developers would add tracing to their own features, and if they had to think about where to start a span or how to nest it, the result would be a mess. They needed an abstraction that was more intuitive than spans.

Why OpenTelemetry and Grafana

I did not run a vendor bake-off, and I will not pretend I did. Two facts made the choice for me.

First, the backend already used Grafana, and backend teams were introducing tracing at the same time. A mobile trace is only half as useful if it stops at the app’s edge. With OpenTelemetry and the W3C traceparent header, a span started on the phone and the spans the backend creates for the same request land in one trace. No other option gave me that end-to-end view with the stack we already ran.

Second, OpenTelemetry now has a Kotlin Multiplatform SDK, opentelemetry-kotlin, which came to the project as a donation earlier this year. One implementation in commonMain covers both platforms. It is alpha, and I accepted that deliberately. As you will see, alpha has a price.

On the Grafana side, traces go to Tempo and are explored with TraceQL. A self-hosted stack is also far cheaper than sending every span to a SaaS vendor, which mattered because I wanted to store everything at first, without sampling.

For local work, one container is enough: grafana/otel-lgtm bundles a collector, Tempo, Loki, Prometheus-compatible storage and Grafana. I ran it on my laptop and pointed the Android emulator and the iOS simulator at it. Being able to tap a button and see the span in Grafana seconds later made the design work much faster.

Architecture at a glance

The trace root is the business operation

When I started, spans and traces were new to me. I had a hunch that the pipeline framework could carry tracing, but I almost talked myself out of it. Combining the two turned out to be the best decision in the whole project.

Look at what the pipeline already gives you. Every business operation ends in build() or buildOnce(), which is exactly where the operation begins and ends. Every network call goes through source(apolloCall), which is exactly where a GraphQL operation begins and ends. The seams I needed were already there. So the API became: name the operation at the terminal, and the framework does the rest.

Step one is a typed operation in a catalogue:

class MakeBid(roomId: String, auctionId: String, bidValue: Int) : ShopperTracedOperation(
    name = "makeBid",
    attributes = mapOf(
        TraceAttributes.ROOM_ID to roomId,
        TraceAttributes.AUCTION_ID to auctionId,
        TraceAttributes.BID_VALUE to bidValue,
    ),
)

Step two is passing it to the terminal:

suspend fun makeABid(...): TiltResult<AuctionBidTiming> = source(currentUserStore.currentUser)
    .transformToSource { user -> source(apolloClient.mutation(AuctionMakeABidMutation(...))) }
    .transform { data -> /* map timing */ }
    .buildOnce(ShopperTracedOperation.MakeBid(roomId, auctionId, bidValue))

That is the whole developer-facing API. I rejected the obvious alternative, buildOnce("makeBid", mapOf("room_id" to ...)), because sooner or later someone writes room.id in one place and room_id in another, and every query in Grafana breaks quietly. Attribute keys live in one object of constants, and their types are kept, so TraceQL can compare numbers as numbers.

Under that one argument, a trace looks like this:

biz op: makeBid                    root, opened by buildOnce
  operation: AuctionMakeABid       one span per pipeline source
    attempt: AuctionMakeABid       one span per HTTP request, carries traceparent
      hasura /v1/graphql           backend spans, same trace

The attempt layer came from a mid-project pivot. A span above the retry logic cannot see individual retries, so I added an Apollo interceptor below retry and auth that opens one span per physical request and injects traceparent into each one. A retried bid now shows up as two attempts under one operation, and the backend sees two distinct requests.

The pipeline gave me one more thing for free: error capture. Every operator turns exceptions into a typed TiltResult.failure, so the terminal sees every failure, whether it came from the network, a converter or a checkNotNull in a transform. The root span records it once, with the error type and code.

Later I added opt-in spans for steps that are not network calls but still matter, like a local data source or a heavy transform. My first version added a separate traced operator. I threw it away in review, because it made the existing operators second-class the moment tracing was on. The rule I settled on: tracing must be invisible in the operators. An existing transform takes an optional name. Unnamed, it behaves exactly as before. Named, it emits a span. Nothing else in the pipeline changes.

Streams are different

One-shot operations map neatly onto a trace: it starts, it ends. A live room is not one-shot. It is a set of subscriptions that can run for an hour.

The tempting answer is one long span per subscription. That is the session-trace anti-pattern again, just one level down: a root that never closes, a waterfall nobody can read. I chose bounded roots instead. build(operation) opens a root when the stream is collected and closes it at the first real combined state, the moment the screen has data to show. What I trace for streams is setup: how long it takes from opening the room to seeing the auctions.

Why not also trace each emission? I tried to design it and kept hitting the same wall. A Flow’s coroutine context is fixed when collection starts, and the conversion runs upstream of the terminal. Starting a fresh trace per emission would need machinery that knows which phase the stream is in, everywhere in the chain. And the signal would be weak. Many subscriptions emit once and then stay quiet for minutes, which is perfectly normal. I did not want to flood Tempo with traces that mostly say “nothing happened”. So per-emission tracing is deferred on purpose, and I wrote down why.

The pipeline’s shape forced a few other decisions:

• Context crosses into Apollo explicitly. My first version passed the parent span through the coroutine context with withContext inside a flow {} builder. The unit tests passed. On a device it crashed with "Flow invariant is violated", because a flow may not change its context from inside. The parent span now travels in Apollo's ExecutionContext, which is designed for exactly that.
• Placeholders do not count. startWith(emptyList()) unblocks the UI before data arrives. If it closed the setup root, every stream would report a perfect setup time. startWith always takes a value, never a source, so I mark it as synthetic and the root waits for real data.
• WebSocket connections are their own traces. A socket connection has no business operation that owns it, so ws: connect is a standalone root, named after the client it belongs to. To join backend spans, traceparent rides in the connection_init payload, because the subscription protocol has no header slot per message.

Living with an alpha SDK

The Kotlin Multiplatform OpenTelemetry SDK let me write tracing once for both platforms. It also made me a part-time SDK maintainer.

I kept a thin wrapper of my own (Tracer, Span, SpanContext) between the module and the SDK. Not to hide the platform, but to isolate churn: when an alpha API changes, one file changes, not every repository.

That wrapper earned its keep. Three SDK defects reached me in practice, and each one was worked around in the module’s own code:

1. Exporting while offline crashed the app. A transport failure escaped the exporter. A small wrapper around the HTTP engine now turns it into an ordinary failed export.
2. A non-protobuf error body crashed the exporter. When an error response came back with a body that was not protobuf, decoding it threw. The same wrapper now empties non-2xx bodies before the SDK reads them.
3. The batch span processor was not thread-safe. On iOS it caused a native crash under load that became one of the app’s most frequent crashes. A teammate diagnosed it and replaced the processor with one built on a coroutine Channel.

Two more gaps shaped the design:

• No metrics. The SDK has scaffolding for a Meter but no instruments and no metric exporter. Instead of faking metrics with extra spans, I left that to the backend: rate, errors and duration can be derived from spans in the OpenTelemetry Collector with the spanmetrics connector. Until that is in place, dashboards use TraceQL metrics in Tempo, which only cover a short time window.
• Phones have bad clocks. The first end-to-end traces showed backend spans starting visibly after the client span that caused them. The SDK takes timestamps from the device clock, which can drift. The app already had a server-synced clock, so I passed that to the SDK instead.

Would I choose the alpha SDK again? Yes. Every one of these problems had a contained workaround, and the alternative was two separate native implementations that would drift apart. But I would plan for it from the start, wrapper first.

Running it in production

Shipping the code was half the work. The other half was deciding how tracing behaves once real users generate it.

Gate it from the app, read it once. Tracing is switched on per user by a feature flag that lives in the apps, not in the shared module. The module only receives a tracingEnabled lambda and does not know which flag service is behind it. The flag is read lazily on the first span and cached for the process, so it never flips halfway through a trace. Without a configured endpoint, the tracer is a no-op and the SDK is never even created.

Store everything, roll out by cohort. There is no sampling on the device. Sampling on the phone would make it impossible to later capture specific users on the collector side. Volume is controlled by how many users have the flag on, and I raised that gradually, Android first, then iOS.

One mobile service. Both apps report as a single service.name, with the platform as an attribute. I rarely care about Android or iOS alone, because almost everything worth tracing involves the backend too. And service.name is the one attribute Grafana treats as first-class, in the service graph and the default views.

Recovered is not failed. A failed attempt followed by a successful retry produces a child span with an error under a root that succeeded. If alerting looked at any error span, every recovered retry and every token refresh would fire a false alarm. Error rates key on the root span’s status only.

Cancelled is not success either. If the user leaves the screen mid-bid, the operation is cancelled, not failed. Early on, those looked like successful bids in the trace list. Now the root carries an explicit cancelled marker.

A digest beats a pager. My first plan was alerts on slow or hung operations. In practice a single user on a dead network can trigger them, and that is noise. What I actually wanted was to know, every day, how bids are doing. So the alerting idea turned into a daily digest.

Make it self-serve. The project was done when another developer could add tracing to their query or mutation and see the trace in Tempo without asking me. I wrote a tracing guide and an interactive agent skill: it picks the right catalogue, proposes attributes, generates the TracedOperation, compiles once, and ends with ready-to-paste TraceQL queries plus a check that the backend joins the trace. When I announced it, I added one warning: do not add tracing everywhere just because you can. Add it deliberately, where you need to diagnose an operation.

What the traces revealed

Tracing paid for itself before it reached production.

During the spike I put the app through airplane-mode stress tests with a local Grafana, and the waterfalls showed problems I had no way to see before:

• A bid could hang for a long time when the network dropped mid-request, and longer still with a retry, because the retry reused a dead pooled connection.
• A zombie WebSocket. After a network change, the socket could stay half-open: no error, no data, frozen until the next network change. That became its own fix project.
• Phantom bids. A cancelled bid looked like a success in the trace list, which is how the cancelled marker was born.

I made a deliberate call not to fix these before shipping tracing. Only production traces could tell me whether real users actually hit them, and how often. The bid traces later kicked off a separate project to improve the bidding experience and client-side timeouts.

In production, traces changed how investigations go:

• Complaints that were not what they seemed. When users reported that bids “did not go up”, the traces for that room showed bids completing quickly and without errors. The real problem was how fast the other clients saw the new price, not the bid itself. Without traces, I would have been tuning the wrong path. One caveat surfaced too: older app versions do not emit traces, so a missing trace is not a missing bid. Check the app version first.
• A backend bug, seen from the phone. Setup traces for the live room had a long tail. It came from one subscription that, in a specific case, completed without sending any data. The client saw no error, so nothing retried, and the room waited. I could hand the backend team trace IDs and the exact query to reproduce it.
• Stale state behind “late” bids. Correlating bid traces with analytics showed that some bids were rejected because the bidder’s app was one price step behind, not because they were slow. That led to a design where the bid response itself returns the updated auction, so the bidder’s screen is never behind their own bid.

None of these were exotic bugs. They were simply invisible until each step of an operation had a start, an end and a parent.

What I would tell myself in June

1. Pick the unit before the tool. The most important decision was not OpenTelemetry or Grafana. It was that a trace is a business operation, bounded, with the IDs people ask about. Everything else followed from that.
2. Hide spans behind your own seams. Developers should name an operation, not place spans. If your codebase has a natural boundary for business operations, hook into it. If it does not, that is worth fixing first.
3. Tracing must be invisible where it is not asked for. Unnamed steps cost nothing and look exactly like before. Named steps emit a span. No parallel API.
4. Design for retries and cancellation on day one. Recovered is not failed, cancelled is not success. Getting those wrong turns a dashboard into a noise generator.
5. Budget for the alpha. A young SDK is still the right call if it removes a whole second implementation. Wrap it, and expect to patch around it.
6. Observe first, then fix. Shipping tracing before fixing what the spike found told me which problems real users have. Some mattered a lot, and I would not have guessed which ones.

And one lesson that spans both parts of this series. The pipeline framework was built to make data code safer for people who do not live in coroutines. Months later, the same structure turned tracing into one argument per function. Small, boring infrastructure that you own compounds.

If you skipped it, Part 1: Everything Is a Source tells the story of that framework.

Tracing Business Operations, Not HTTP Calls — Part 2 was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Tilt, the Android and iOS apps share one Kotlin Multiplatform module that owns networking, caching and business logic. A year ago, every repository function in it was a small, hand-rolled piece of coroutine plumbing. Today almost every new one is a single expression that reads like a sentence:

source(apolloClient.query(ProductQuery(id)))
    .transform { converter.toDomain(it) }
    .buildOnce()

This article is about the roughly 1,600 lines of Kotlin behind that expression: why I built them instead of adopting a library, the first design I threw away, and the one idea that survived every refactor: everything is a source.

There is also a twist I did not plan for. I built the framework as guardrails for developers who did not know Flows well. It turned out to be exactly the guardrails AI coding agents needed too.

The problem: more contributors, less Flow experience

In late 2025, iOS developers started contributing to the shared module. That was the point of Kotlin Multiplatform, and it was great. But coroutines and Flows have plenty of sharp edges: when a flow completes, what flatMapLatest cancels, where an exception ends up, why you must never swallow a CancellationException. These are not obvious if Swift is your daily language.

The bigger issue was not knowledge of Flows. It was error handling that was quietly skipped. A typical repository function looked like this:

return flow {
    emit(executeDataCatching(apolloClient.query(BundlesConfigQuery(roomId))) { /* map */ })
}.flatMapLatest { configResult ->
    if (configResult.isSuccess) {
        val config = configResult.getOrThrow()
        if (config.sellerId != null && config.enabled) {
            combineTiltResult(
               apolloClient.subscription(BundlesSubscription(config.sellerId)),
                apolloClient.subscription(AddressSubscription(roomId)),
            ) { bundles, address -> converter.toDomain(bundles, address) }
        } else {
            flowOf(TiltResult.success(ShippingBundleState.Inactive))
        }
    } else {
        flowOf(TiltResult.failure(configResult.exceptionOrThrow()))
    }
}.retryUntilChanged(LIVE_MODEL)

It works. But the isSuccess / getOrThrow / flowOf(failure) ladder is written by hand every time. Each time, someone can forget a branch, call getOrThrow() one line too early, or wrap a runCatching around something that should have stayed typed. An audit of the codebase at the time found exactly that: errors wrapped inconsistently, and at least one call that skipped the wrapper altogether.

The second problem was combining. The existing helper, combineTiltResult, only understood Apollo calls, plus a few hand-picked mixes with Flows. Every new combination of arity and input type needed a new overload. There were 11 of them, each repeating the same body. I needed to combine anything: a query with a subscription, a local store, a cached value, a settings flow.

One thing was not up for debate: TiltResult, Tilt's own result type. It existed before any of this, because Kotlin's Result does not bridge to Swift. Whatever I built had to speak TiltResult end to end.

Build or adopt?

I did not go shopping for a library. That was a deliberate choice, not an oversight.

What I needed was small: wrap a few kinds of input into one shape, combine them, transform them, and handle errors the same way everywhere. That does not justify an external SDK with its own release cycle, its own opinions about caching, and its own learning curve. I also wanted full control. This would sit under every repository in the module. When it needed to change, I wanted to change it that afternoon, not open an issue upstream.

That decision paid off later in a way I could not have predicted. More on that at the end.

Attempt one: a DSL nobody could discover

The first version, in November 2025, was a builder DSL. It looked tidy on a slide:

dataPipeline {
    addSource<UserData>(observe(apolloClient.subscription(UserSubscription())))
    addSource<RoomData>(observe(apolloClient.subscription(RoomSubscription(roomId))))
    combine<UserData, RoomData> { user, room -> converter.toDomain(room, user) }
}.build()

In practice it was painful to use. IDE auto-completion barely helped: inside the builder lambda, you had to already know what to type. It was not clear from the code how the pieces fit together, or which calls were legal in which order. Under the hood, combine checked at runtime that you had registered the right number of sources, and cast them unchecked. The compiler could not help you either.

There was also a split between fetch(...) for one-shot calls and observe(...) for streams. It sounded clear. But Apollo already emits once for queries and mutations and keeps emitting for subscriptions. The second vocabulary only added a way to pick the wrong one.

In January 2026 I replaced the whole thing. That rewrite is where the real idea showed up.

The idea that stuck: everything is a source

The rewrite dropped the builder and kept one concept: a PipelineSource<T>. Under the hood it is just a Flow<TiltResult<T>>, so a failure is a value that travels down the chain instead of an exception that escapes it. You never touch that flow directly. You build sources, connect them, and close the pipeline with a terminal.

There are three kinds of building blocks.

1. One factory for every input. source(...) has overloads for an Apollo call (query, mutation or subscription), a Flow<T>, a plain value, or a TiltResult you already have. Whether it emits once or many times is a property of the input, not something you declare.

2. Operators, named by intent. transform, transformToSourceLatest for dependent calls, validate, distinctUntilChangedBy, timeout. Error operators follow one naming rule: with* changes the stream (withFallbackValue, withFallbackSource), on* only observes it (onSuccess, onFailure). Every operator catches exceptions and turns them into a typed failure. A checkNotNull inside a transform becomes a parsing error the caller can handle, not a crash.

3. Combining, with types the compiler checks. sourceCombine(a, b, c) { a, b, c -> } is a plain function with fixed arities. It short-circuits on the first failure, so the lambda only runs when every input succeeded and its parameters are never wrapped in a result. For a dynamic number of inputs there is combineSources(list).

Then you pick a terminal. build() returns a Flow<TiltResult<R>> for long-lived streams and adds retry with backoff and de-duplication. buildOnce() is a suspend function returning TiltResult<R> for one-shot reads.

Here is the function from the previous section, rewritten:

val configSource = source(apolloClient.query(BundlesConfigQuery(roomId)))
    .transform { data -> data.toConfigParams() }

val bundlesSource = configSource.transformToSourceLatest { config ->
    if (config.sellerId != null && config.enabled)
        source(apolloClient.subscription(BundlesSubscription(config.sellerId))).asNullable()
    else emptySource()
}
val countrySource = source(apolloClient.subscription(AddressSubscription(roomId)))
    .transform { it.address?.country }
return sourceCombine(configSource, bundlesSource, countrySource) { config, bundles, country ->
    converter.toDomain(bundles, config, country)
}.build()

The ladder is gone. Nobody writes isSuccess or getOrThrow, because short-circuiting on failure is the framework's job. Each source is a named value you can read in isolation. And all 11 combineTiltResult overloads were eventually deleted.

The idea grew past repositories. The in-memory stores now expose fooSource(): PipelineSource<T> instead of a suspend fun getFoo(). A repository that needs the store's state just composes it into its own pipeline, with no flow { emit(store.getState()) } trick in between. Before landing there, I considered letting a core operator accept suspend lambdas so the trick would not be needed. I rejected it, because it would invite network calls and delay() inside lambdas instead of modelling them as sources. If something produces data, it is a source.

Failures propagate. Degradation is a decision.

The most important rule in the framework is not in any operator. It is a default: a failure reaches the consumer unless someone decides otherwise.

This sounds obvious until you watch it erode. When one of three combined sources can fail, the easy fix is to wrap each of them in .asNullable().withFallbackValue(null). Nothing blocks, the screen renders, and everyone moves on. But now the data can be stale, and the place that observes it and would log the problem never hears about it. I pushed back on exactly this pattern more than once.

The opposite mistake is just as real. When I migrated the live auction stream, one failed product lookup could suddenly fail the whole live room. Before, it only dropped one auction from the list. That is not acceptable, and it is precisely what fallback operators exist for. So the rule has two halves:

1. Propagate by default. A plain source has no fallback.
2. Degrade on purpose, where the domain says one part must not take down the whole. Make that decision visible in the code, and log before you swallow the error.

The home feed shows both halves in one function. It fetches two things in parallel: the user’s country from their settings, which only fine-tunes the results, and the feed itself. A slow or failed settings call must never block the feed. A failed feed must reach the caller. Before the migration, that took hand-rolled coroutines:

): TiltResult<ContentGroupPage> = coroutineScope {
    val getUserCountryDeferred = async {
        withTimeoutOrNull(USER_SETTINGS_TIMEOUT) {
            userRepository.getUserSettings()
                .onSuccess { logger.i { "User settings: $it" } }
                .onFailure { logger.e(it) { "Failed fetching user settings" } }
                .getOrNull()?.country
        }
    }
    val feedDeferred = async {
        executeDataCatching(apolloClient.query(PersonalFeedQuery(/* … */))) { data -> data }
    }
    val userCountry = getUserCountryDeferred.await().also { userCountry = it }
    return@coroutineScope feedDeferred.await().map { data -> /* convert */ }
}

The degradation is there, but it is buried in withTimeoutOrNull and getOrNull(). Nothing says which of the two fetches is allowed to fail. Here is the same function on the pipeline:

val userCountrySource = userSettingsStore.userSettingsSource()
    .onFailure { logger.e(it) { "Failed fetching user settings" } }
    .transform { it.country }
    .asNullable()
    .timeout(USER_SETTINGS_TIMEOUT.inWholeMilliseconds, null)
    .withFallbackValue(null) // settings may never block the feed

val feedSource = source(apolloClient.query(PersonalFeedQuery(/* … */)))
return sourceCombine(userCountrySource, feedSource) { country, data ->
    /* convert */
}.buildOnce(ShopperTracedOperation.GetFeedContentGroups(/* … */))

Now the decision reads off the code. The settings source degrades on purpose: it logs, times out and falls back to null. The feed source has no fallback, so its failure reaches the caller. And because the settings store exposes a source, it composes like any other input.

One more distinction lives in this rule: absent is not failed. “This user has no active bundle” is a successful response with a null field. “The bundle could not be fetched” is a failure. Mixing those up is how fallbacks start hiding outages.

A migration story: when “the stream is the cache” was too clever

The best test of the framework was the busiest stream in the app: the auctions in a live room. Each auction references a product, so the old code subscribed to auctions, collected product IDs, and fetched missing products into a hand-maintained cache:

private val productsCache = mutableMapOf<String, Product>()
apolloClient.subscription(AuctionsSubscription(roomId))
    .mapToTiltResult { auctions ->
        val ids = auctions.productIds()
        cleanupUnusedProducts(ids)
        productsCache.putAll(fetchProductsConcurrently(ids - productsCache.keys)) // async + awaitAll
        AuctionsWithProducts(auctions, buildRelevantProductsMap(ids))
    }

The first migration looked beautiful. A new combineSources(list) operator fanned out one source per product. distinctUntilChangedBy { ids } skipped work when the product set had not changed. The manual cache and three helper functions were deleted. The cache was no longer a data structure but a live subscription. The stream was the cache.

Then code review found the catch. distinctUntilChangedBy held back the whole stream, so auction updates that did not change the product set never reached the screen. And any change to the set re-fetched every product, not just the new one.

The agent working with me proposed a new generic operator, combineKeyedSources, complete with tests. I stashed it. It solved the problem by adding a framework primitive for one call site. The fix I shipped was smaller: a plain cache that hands out sources.

private fun productSource(id: String): PipelineSource<Product?> {
    productsCache[id]?.let { return source(it) } // hit: a value source, no network
    return source(apolloClient.query(ProductQuery(id)))
        .transform { it.toProduct() }
        .onSuccess { productsCache[id] = it }
        .onFailure { logger.w(it) { "Failed to fetch product $id" } }
        .withFallbackValue(null)
}

A side effect I did not expect: the onFailure line logs the cause of a failed product fetch. The old imperative code used getOrNull() and threw it away silently.

The lesson for me: deleting state in favour of an elegant stream changed behaviour in ways no type caught. The right answer was not a cleverer operator. It was a boring cache that speaks the framework’s language.

Guardrails for people turned out to be guardrails for agents

I designed the framework for a developer who does not know every nuance of Flows and might skip error handling under deadline pressure. A few months later, the team was writing a large share of its code with AI agents. An agent fits that description surprisingly well.

Agents are fluent in coroutines in general and unreliable in the specifics. Left alone, they reach for whatever pattern they saw most often in training. With the framework, the specifics are narrowed down to a small vocabulary: make sources, combine them, end with build() or buildOnce(). I wrote that vocabulary into the agent guides as the mandatory pattern for repository methods, and a pipeline framework guide sits next to the architecture docs.

The mistakes I still catch are telling, because they are almost always a step away from the framework:

• Abandoning sourceCombine for hand-written async/awaitAll, convinced the pipeline broke parallelism. It did not. For one-shot sources, combine runs them concurrently and cancels them together. The real culprit was a test mock server that answered requests in order. The pipeline version was about 10 lines instead of 30.
• Using the wrong terminal, like build().first() instead of buildOnce(). That quietly adds retry and de-duplication meant for long-lived streams.
• Adding fallbacks by reflex, which is the failure-propagation problem from earlier.

Each of these is easy to spot in review because the framework makes the correct shape so recognisable. A deviation stands out. The team took to it well, and with the guides in place, agents built new features on top of the pipeline quickly and consistently. Today more than 50 files in the module build on source(...). Older code still uses the previous helpers, and it moves over function by function, which was a design goal from day one.

What I would tell myself in November 2025

1. Discoverability beats elegance. The DSL looked better in a design doc. Free functions on plain values won because your IDE can complete them and a newcomer can read them top to bottom.
2. Defaults matter more than features. The operator list grew over time. The thing that actually changed code quality was one default: failures travel to the consumer unless someone opts out, in writing.
3. One concept scales further than many. fetch vs observe, builders, special-purpose operators: each was a second way to say the same thing. "Everything is a source" kept absorbing new cases, from stores to caches, without new vocabulary.
4. The framework got simpler as it matured. Months later I seriously considered going back to a DSL-first build { } shape. An analysis showed it would change nothing at runtime, touch over 180 call sites, and leave two vocabularies to maintain. I kept the boring version.
5. Own your small infrastructure. Because the code is mine, I can change a core operator the day I need it, with no workaround on top of a library.

That last point is where Part 2 begins. This summer I set out to add distributed tracing for business operations like placing a bid, across both apps. In most codebases that means touching every call site. In this one, every business operation already ended in build() or buildOnce(), and every network call already went through source(...). So tracing a function cost one argument:

.buildOnce(ShopperTracedOperation.MakeBid(roomId, auctionId, amount))

In Part 2: how I built mobile OpenTelemetry tracing on top of the pipeline, what Grafana revealed that had been invisible before, and what it is like to run an alpha OpenTelemetry SDK for Kotlin Multiplatform in production.

Everything Is a Source — Part 1 was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In 2026, creating a cross-platform mobile app with shared business logic and UI between Android and iOS is fairly straightforward thanks to Kotlin Multiplatform and Compose Multiplatform. However, sooner or later we might need a platform-specific library that cannot be added to commonMain, and suddenly things aren’t as straightforward as we would expect.

Google Nearby Connections is a good example. Its iOS SDK is distributed as a Swift package, but downloading and compiling it doesn’t necessarily mean that its APIs will be accessible from Kotlin. There are a few additional pieces involved, and Kotlin 2.4.0 made the configuration easier thanks to built-in SwiftPM import.

In this article, I’ll describe how I migrated an existing spm4Kmp integration to this approach, what could be removed and why some Swift code still had to stay.

Offline messaging and audio calls with Flight Chat

Flight Chat is a peer-to-peer offline messenger built with KMP and CMP. It allows iOS and Android devices to exchange text messages and make audio calls without an Internet connection or a server in between. Google’s Nearby Connections SDK handles communication, while the application shares its business logic and UI.

You can try Flight Chat on Google Play or the App Store.

The native SDK integration sits behind platform-specific implementations, which is quite convenient for this migration — changing how the iOS dependency is built doesn’t require changes in ViewModels or Composables.

Swift interop — there is still Objective-C underneath

The original integration used the spm4Kmp Gradle plugin to handle Swift package dependencies and the build configuration needed to make compatible APIs available to Kotlin. Moreover, it supported local Swift bridge code, which was crucial for integrating the Nearby SDK.

The important word here is “compatible”. Kotlin/Native’s Objective-C interoperability doesn’t expose arbitrary Swift APIs, so a Swift package can compile successfully while the generated Kotlin bindings contain almost nothing useful. For someone used to simply adding a third-party dependency and using its classes, this was a somewhat unpleasant surprise. I encountered exactly this situation and opened an issue, where François (the plugin’s author) helped me understand the interoperability limitations. The discussion also became the plugin’s first FAQ entry, so hopefully it saved someone else a similar surprise.

The Nearby SDK includes a Swift-facing NearbyConnections product and a lower-level NearbyCoreAdapter module. You can see how Google’s Swift API uses that module in its Advertiser implementation. My local Swift wrappers also call NearbyCoreAdapter directly, while exposing Objective-C-compatible APIs to Kotlin. For example, my advertiser wrapper inherits from NSObject and uses @objc and @objcMembers to expose its compatible declarations. Its advertising methods then call GNCCoreAdapter.

The package we depend on and the APIs we call are not quite the same thing. This distinction matters because replacing the package integration doesn’t remove the need for Objective-C-compatible APIs. The wrappers remain necessary with either build setup.

Kotlin 2.4.x — missing module & SwiftPM import

Unfortunately, after upgrading from Kotlin 2.3.20 to 2.4.0, the Swift package still compiled, but the subsequent cinterop task failed with:

fatal error: module 'NearbyCoreAdapter' not found

The generated Swift header referenced NearbyCoreAdapter, yet the cinterop configuration didn’t include the path needed to resolve that transitive module. Adding its build directory to compilerOpts worked around the problem, although maintaining a path into another tool’s build output wasn’t particularly appealing.

I reported the issue, but we couldn’t reproduce it in the plugin’s example project. Thankfully, the same Kotlin release introduced an alternative integration, so I decided to try it.

And just a side-note — SwiftPM import and Swift export are separate features:

• The former imports compatible APIs from Swift packages into Kotlin.
• The latter exposes Kotlin APIs to Swift.

The Swift export alpha announcement doesn’t mean that Kotlin can suddenly call every Swift API. Objective-C is still alive.

Build configuration — a local Swift package

With spm4kmp, the swiftPackageConfig block declared the Nearby dependency, configured the Swift bridge and prepared the package consumed by Xcode. With the new integration, the wrappers became a regular local Swift package with their own Package.swift.

The manifest declares a library product called nearbyIos, a target containing the existing Swift files and a dependency on Google’s repository. The target then depends on the NearbyConnections product from that package.

There are two concepts worth distinguishing here: a SwiftPM product is what another package consumes, while a target describes the source module and its dependencies. In this local package, both are named nearbyIos, which makes the configuration fairly straightforward.

On the Gradle side, we point to that package and select the module to import:

You may notice that products and importedClangModules contain the same name. They serve different purposes: the former selects the SwiftPM product, while the latter selects the Clang module whose APIs should be imported. Setting discoverClangModulesImplicitly to false makes that selection explicit instead of automatically discovering available modules.

Xcode integration — Gradle is only part of the setup

Having Kotlin bindings available doesn’t finish the integration. The iOS application also needs the corresponding native code linked into it.

Kotlin’s tooling generates an intermediary package called KotlinMultiplatformLinkedPackage. In this project, it depends on the local nearbyIos package and replaces the previous exportedNearbyIos reference in Xcode. The official integration guide describes the :integrateLinkagePackage Gradle task, which generates the package and updates the Xcode project.

The generated package, updated Xcode project and the SwiftPM resolution lock can be committed to version control. The lock records the resolved dependency revisions, including transitive ones.

On the Kotlin side, the generated package name changed as well:

-import nearbyIos.Advertiser
+import swiftPMImport.projectName.moduleName.Advertiser

One additional CI adjustment was to set rootProject.name explicitly in settings.gradle.kts. It’s worth checking this setting when applying the migration to your own project.

Was the migration worth it?

For this particular integration, definitely. The initial migration worked on the first try, and I could remove both the plugin and the temporary cinterop workaround while retaining the existing Swift bridge.

However, keep in mind that built-in support doesn’t mean every Swift package will work without additional effort — SwiftPM import is still documented as alpha. The migration used Kotlin 2.4.0; Kotlin 2.4.21 is available at the time of writing. Check the current integration docs for the Kotlin version you use.

If your existing integration works well, I wouldn’t migrate just for the sake of it. In my case, an unresolved integration issue and the opportunity to simplify the setup made it a worthwhile change. After all, spm4Kmp had already done the heavy lifting of making the original integration possible.

Hopefully these configuration examples save you some time when the next Swift dependency compiles successfully, but Kotlin still claims it has never heard of it!

Swift packages in Kotlin Multiplatform - built-in SwiftPM import with Kotlin 2.4.x was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey! So you want to learn Kotlin Flows? Grab a seat. I know the official documentation can sometimes feel like reading a microwave manual, but I promise you, once you get the mental model right, Flows are going to be your best friend.

Forget about the code for a second. Let’s talk about air.

The Breakdown: The Air Compressor Analogy

Imagine you are painting a car using an Air Compressor and a Spray Gun.

• The Producer (The Compressor): This is where the air is generated. In Kotlin, this is your database, your network call, or a timer.
• The Flow (The Hose): This is the pipe connecting the compressor to your tool.
• The Operators (Valves & Filters): Maybe you have a moisture filter on the hose, or a pressure regulator. It modifies the air before it reaches you.
• The Consumer / Collector (The Spray Gun): This is your Android UI.

Here is the most important concept to understand about a standard Kotlin Flow: It is a COLD stream.

What does “Cold” mean? Imagine your air compressor is completely turned off and silent. It will not generate a single ounce of air until you pull the trigger on the spray gun. The moment you pull the trigger (in Kotlin, we call this .collect()), the compressor kicks on, air pushes through the filters, and paint comes out. When you let go of the trigger (cancel the coroutine), the whole system shuts down instantly.

Diagrammatic Mental Model:

Plaintext

[Air Compressor] ---> (Pressure Valve) ---> (Moisture Filter) ---> [Spray Gun]
   (Producer)           (Operator: map)       (Operator: filter)      (Collector)
   
Status: DEAD SILENT until someone pulls the trigger on the Spray Gun.

Let’s look at how this looks in code:

Kotlin

// 1. The Compressor (Producer)
val airFlow = flow {
    println("Compressor turned on!")
    emit("Air Burst 1")
    delay(1000) // Takes a second to build pressure
    emit("Air Burst 2")
}

// 2. The Trigger (Collector)
// If we don't write this code below, the "Compressor turned on!" is NEVER printed.
coroutineScope.launch {
    airFlow.collect { air ->
        println("Spray gun received: $air")
    }
}

Under the Hood: What happens internally?

How does the air actually move? When you call .collect(), you are passing a "Continuation" (a fancy word for a callback) up the pipe to the producer.

The emit() function is a suspend function. This means if the pipe gets clogged (maybe your UI is taking too long to draw the screen), the emit() function literally pauses the air compressor. It doesn't crash, it doesn't block the main thread; it just says, "Whoa, the pipe is full, let's suspend and wait until the spray gun uses up some air." It's a perfect pressure-regulated system.

The “Wait, But Why?” Section

Doubt: “Dude, why are we doing all this? If I just want a list of users from a database, why don’t I just return a List<User>? Why do I need a Flow?"

Answer: Great question. Think of a List as a bucket of water. You have to fill the entire bucket before you can carry it to the UI. If you have 10,000 users, your app will freeze while it fills the bucket. A Flow is a hose. As soon as the first drop of water (or puff of air) is ready, it travels down the hose to your UI. Your UI can start displaying the first few users while the rest are still being fetched. Plus, if the database updates, the hose just pushes the new data automatically. A bucket can't do that!

Doubt: “Okay, but what about LiveData? We’ve used that for years!”

Answer: LiveData is like an Android-branded bucket. It’s great for the UI, but it ONLY works on the Main Thread, and it doesn’t have good valves/filters (operators). Flow is pure Kotlin — it doesn’t care about Android. You can run it on background threads easily, filter it, combine it with other flows, and then only pass the final, polished result to the UI.

Tiered Interview Questions (What to expect)

Level 1: The Junior Developer (1–3 Years Experience)

• Question: What is the difference between a Cold Flow and a Hot Flow?
• How you answer: “A standard Kotlin Flow is cold. This means the code inside the flow { } builder does not run until a consumer calls .collect() on it. If there are no collectors, no work is done. A hot flow (like StateFlow) is always active, regardless of whether someone is listening."
• Question: Can you call emit() outside of a Coroutine?
• How you answer: “No. emit() is a suspend function, meaning it needs to be called within a Coroutine or another suspend function. This is what allows Flow to be non-blocking."

Level 2: The Mid-Level Developer (4–5 Years Experience)

• Question: What happens to a Flow if the Coroutine collecting it is cancelled? Does it leak memory?
• How you answer: “No memory leaks! Flow is perfectly tied to Structured Concurrency. When the collecting Coroutine is cancelled (for example, when a ViewModel is cleared), the collector stops listening. Because the Flow is cold, this cancellation propagates upstream, and the producer (flow { ... } block) is immediately cancelled and stops emitting."
• Question: How does Flow differ from RxJava’s Observable?
• How you answer: “Flow is built entirely on Kotlin Coroutines, making it much lighter. RxJava uses its own heavy threading model and complex backpressure management. Flow handles backpressure natively because emit() is a suspend function—if the collector is slow, the emitter naturally suspends, handling backpressure implicitly without extra callbacks."

Level 3: The Senior/Architect

• Question: How does Flow ensure Context Preservation, and why will the compiler yell at you if you use withContext inside a Flow builder?
• How you answer: “Flow guarantees Context Preservation, meaning the flow builder must emit in the same CoroutineContext as the collector. If you try to use withContext(Dispatchers.IO) inside the flow {} builder, it violates this rule and throws an IllegalStateException. To change the dispatcher for the upstream (the producer), you must use the .flowOn(Dispatchers.IO) operator. This architectural choice prevents downstream collectors (like the UI) from accidentally executing on a background thread."

Part 1: Kotlin Flows — The Air Compressor of Android (Fundamentals & Cold Streams) was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

When collecting a Flow in Jetpack Compose, the code can be as simple as this:

val uiState by viewModel.uiState.collectAsState()

But Android applications have a lifecycle. When an app moves to the background, should the UI continue collecting updates? What happens when the user returns?

Over the years, Android developers have used several approaches to handle these questions. Understanding how they evolved helps us choose the right API without adding unnecessary code.

Let’s walk through the key changes, from collectAsState()to collectAsStateWithLifecycle().

【Jetpack Compose】もう冗長なコードは不要！ collectAsStateWithLifecycle で Flow を安全に収集する

1. Compose 1.0: collectAsState()

July 2021

Jetpack Compose 1.0 introduced collectAsState() as a straightforward way to convert a Flow into Compose State.

val uiState by viewModel.uiState.collectAsState()

Whenever the Flow emits a new value, Compose updates the state and recomposes the relevant UI.

The code is simple, but there is an important distinction: collectAsState() does not automatically stop collection when the Android lifecycle falls below STARTED.

For example, when an Activity moves to the background, collection can continue as long as the composition remains active.

This isn’t necessarily a problem for every Flow. However, if the upstream Flow performs expensive work or maintains an active connection, continuing to collect while the UI is not visible may be undesirable.

2. Lifecycle 2.4.0: launchWhenStarted() and repeatOnLifecycle()

October 2021

Before lifecycle-aware collection became a simple Compose API, developers often managed the lifecycle manually.

One approach was launchWhenStarted():

lifecycleOwner.lifecycleScope.launch {
    lifecycleOwner.lifecycle.launchWhenStarted {
        viewModel.uiState.collect { state ->
            // Handle state
        }
    }
}

This approach tied execution to the lifecycle, but it had a significant drawback: when the lifecycle stopped, the coroutine could be suspended rather than cancelled. Upstream work could continue unnecessarily.

The Lifecycle 2.4.0 release introduced repeatOnLifecycle(), which provides a better approach:

lifecycleOwner.lifecycleScope.launch {
    lifecycleOwner.lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.uiState.collect { state ->
            // Handle state
        }
    }
}

The behavior is straightforward:

• When the lifecycle reaches STARTED, collection begins.
• When the lifecycle falls below STARTED, the collection block is cancelled.
• When the lifecycle returns to STARTED, the block runs again.

This is safer than suspending the coroutine while leaving its upstream work active.

However, there is still a problem: the code is verbose for something that Compose screens do frequently. We also have to manage how collected values reach Compose State.

3. Lifecycle 2.4.0: flowWithLifecycle()

Another option was to apply lifecycle awareness directly to the Flow.

val lifecycleOwner = LocalLifecycleOwner.current

val uiState by viewModel.uiState
    .flowWithLifecycle(lifecycleOwner.lifecycle)
    .collectAsState(initial = UiState())

flowWithLifecycle() allows us to keep the collection expression relatively compact.

Instead of manually calling repeatOnLifecycle(), we transform the Flow so that its collection respects the lifecycle.

But this still requires us to combine lifecycle handling with Compose’s state conversion. We must also provide an initial value when using collectAsState() with a regular Flow.

It works, but Compose can do better.

4. Lifecycle 2.6.0: collectAsStateWithLifecycle()

Introduced in Lifecycle 2.6.0-alpha01 in June 2022; stable in alpha04 in January 2023.

The lifecycle-aware Compose API brings these responsibilities together:

val uiState by viewModel.uiState
    .collectAsStateWithLifecycle()

That’s it.

The API collects the Flow when the lifecycle is active and exposes its latest value as Compose State.

For a StateFlow, the current value provides the initial state. You can also specify a minimum active lifecycle state or an explicit initial value when needed.

For most Android Compose screens, this is the clearest default.

It removes lifecycle-management boilerplate from the UI and makes the intended behavior explicit.

Collection Is Not the Same as Refreshing

There is one important detail worth understanding.

When collectAsStateWithLifecycle() stops collecting, it does not necessarily stop the entire upstream Flow. The actual behavior depends on how that Flow is constructed.

Consider a ViewModel:

val uiState = repository.observeItems()
    .map { items ->
        UiState(items = items)
    }
    .stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5_000),
        initialValue = UiState()
    )

The Power of stateIn in ViewModel

Here, WhileSubscribed(5_000) keeps the upstream Flow active for five seconds after the last subscriber disappears. If collection resumes within that window, the upstream does not need to restart.

If no subscribers remain beyond that timeout, the upstream collection stops. When a subscriber returns, the upstream collection starts again.

Whether that restart triggers a network request depends on repository.observeItems().

For example, a cold Flow that performs an HTTP request on collection may fetch again. A Room Flow generally starts observing the database again; that does not necessarily mean it makes a network request.

The distinction matters:

• Collection resumes: The UI starts observing the Flow again.
• Upstream restarts: The Flow begins its upstream work again.
• Data refreshes: The application explicitly or implicitly fetches fresh data.

These are three different events.

10 Flow Operators for Building a Declarative UiState

Which API Should You Use?

For typical Android Compose screens, the choice is simple.

You don’t need to manage the lifecycle manually when all you want is to expose a ViewModel’s state to a Compose screen.

Start with:

val uiState by viewModel.uiState
    .collectAsStateWithLifecycle()

Use a lower-level API when you have a specific reason to do so.

Conclusion

The evolution of Flow collection in Compose has been about reducing boilerplate without sacrificing lifecycle correctness.

collectAsState() made Flow integration simple. repeatOnLifecycle() provided safer lifecycle-aware collection. flowWithLifecycle() made lifecycle handling composable. Finally, collectAsStateWithLifecycle() brought the common pattern into a single API.

The practical lesson is simple:

let Compose handle lifecycle-aware state collection, and let the ViewModel and repository determine what happens upstream.

That separation keeps UI code concise while making data-fetching behavior explicit where it belongs.

References

• Lifecycle | Jetpack | Android Developers
  https://developer.android.com/jetpack/androidx/releases/lifecycle
• State and Jetpack Compose | Android Developers
  https://developer.android.com/develop/ui/compose/state
• Use Kotlin coroutines with lifecycle-aware components | App architecture | Android Developers
  https://developer.android.com/topic/libraries/architecture/coroutines

Enjoyed this article? Here’s how you can support my work:

• 👏 Clap (up to 50 times!) if you found this insightful.
• 👤 Follow me and turn on notifications (🔔) so you never miss the next deep dive.
• 📧 Subscribe to get my latest stories delivered directly to your inbox.

You can find all my articles on Android architecture, Jetpack Compose, and Kotlin in this curated reading list.

The Evolution of Flow Collection in Jetpack Compose was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

For years, we used companion object to group class-level members (constants, factory methods).

However, companion objects are actual object singletons under the hood. This introduces memory overhead and causes friction when interoperating with Java (requiring @JvmStaticannotations).

data class User(val name: String, val age: Int) {
    companion object {
        
        @JvmStatic
        fun createDefault(): User = User("Guest", 18)
    }
}

Kotlin 2.5 introduces companion blocks and companion extensions:

1. Companion Blocks: Drop the object keyword. On the JVM, they compile down directly into high-performance native static members.
2. Companion Extensions: Let us attach new static-like methods or properties to any class from the outside, even classes inside external dependencies or standard Java SDKs we don’t control.

Companion Blocks vs. Companion Objects

• Under the Hood: A companion object creates a nested singleton subclass instantiation. A companion block compiles directly to static bytecode members on the parent class.

Interface Limitation: Companion objects are still required if static-scoped layer needs to implement an interface. Companion blocks cannot implement interfaces because they are not real objects.

• Java Interop: Java code can call companion block members directly via User.createDefault(). Companion objects still require User.Companion.createDefault() unless decorated with @JvmStatic.

Companion Extensions vs. Regular Extension Functions

• Call Site: Regular extensions require an existing instance (userInstance.isValid()). Companion extensions are invoked statically on the type itself (User.systemAdmin()).
• Use Cases: Regular extensions add instance operations (mapping, filtering, etc.). Companion extensions serve as third-party factories, cross-module configuration initializers, or domain constants.

Implementation

🛠️ Setting Up the project

• Companion Blocks and Extensions are arriving as experimental features in Kotlin 2.5.0-Beta1
• To try this out today, we need to configure two things: the JetBrains Bootstrap Repository and the Experimental Compiler Flags

Enable the Preview Plugin Repository

// settings.gradle.kts
pluginManagement {
    repositories {
        // Required for resolving preview & bootstrap Kotlin compiler artifacts
        maven("https://jetbrains.space")
        // ...
    }
}

Pass the Experimental Compiler Flags

// build.gradle.kts
plugins {
    // Target the 2.5 preview toolchain
    kotlin("jvm") version "2.5.0-Beta1"
}

kotlin {
    jvmToolchain(21) 

    compilerOptions {
        // 1. Opt-in to allow basic companion blocks inside classes
        freeCompilerArgs.add("-Xcompanion-blocks")
        
        // 2. Opt-in to allow writing static companion extensions from the outside
        freeCompilerArgs.add("-Xcompanion-blocks-and-extensions")
    }
}

The Old Way (Companion Object)

data class UserWithCompanionObj(val name: String, val age: Int) {

    companion object {
        val ANONYMOUS = UserWithCompanionObj("Anonymous", 12)
        fun getDefaultUser() = UserWithCompanionObj("Default", 19)
    }
}

UserWithCompanionObj.decompiled.java

public final class UserWithCompanionObj {
   
   @NotNull
   private static final UserWithCompanionObj ANONYMOUS = new UserWithCompanionObj("Anonymous", 12);
   
   public static final class Companion {
      private Companion() {
      }

      @NotNull
      public final UserWithCompanionObj getANONYMOUS() {
         return UserWithCompanionObj.ANONYMOUS;
      }

      @NotNull
      public final UserWithCompanionObj getDefaultUser() {
         return new UserWithCompanionObj("Default", 19);
      }

    
   }
}

The New Way (Companion Blocks & Extensions)

data class User(val name: String, val age: Int) {
    // Compiles down directly to native Java-like statics! No inner object allocation.
    companion {
        val ANONYMOUS = User("Anonymous", 0)
        
        fun createDefault(): User = User("Guest", 18)
    }
}

// Statically extending the User class from the outside (e.g., in a separate module)
companion val User.SYSTEM_ADMIN: User 
    get() = User("Admin", 99)

companion fun User.fromJson(json: String): User {
    val user = Json.decodeFromString<User>(json)
    return User("Parsed User", 25)
}

fun main() {
    // 1. Using Companion Block Members
    val anonymous = User.ANONYMOUS
    val guest = User.createDefault()
    
    // 2. Using Companion Extension Members (Looks completely native!)
    val admin = User.SYSTEM_ADMIN
    val parsed = User.fromJson("""{"name": "Nav", "age": 27}""")
}

User-decompiled.java

@Serializable
public final class User {

   @NotNull
   public static final User getANONYMOUS() {
      return ANONYMOUS;
   }

   @NotNull
   public static final User createDefault() {
      return new User("Guest", 18);
   }

}


// UserKt.java
public final class UserKt {

   @NotNull
   public static final User getSYSTEM_ADMIN() {
      return new User("Admin", 99);
   }

   @NotNull
   public static final User fromJson(@NotNull String json) {
      Intrinsics.checkNotNullParameter(json, "json");
      Json this_$iv = (Json)Json.Default;
      int $i$f$decodeFromString = 0;
      SerializersModule var5 = this_$iv.getSerializersModule();
      KType var10001 = Reflection.typeOf(User.class);
      MagicApiIntrinsics.voidMagicApiCall("kotlinx.serialization.serializer.withModule");
      User user = (User)this_$iv.decodeFromString((DeserializationStrategy)SerializersKt.serializer(var5, var10001), json);
      System.out.println("Decoded user: " + user);
      return user;
   }
   
}

References

https://blog.jetbrains.com/kotlin/2026/09/the-companions-to-come/

The Evolution of Statics: Say Goodbye to Kotlin Companion Objects? was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

For many developers, “dependency conflict” is a phrase that instantly causes a headache. This is especially true when moving from a familiar ecosystem like Gradle to a powerful but complex tool like Bazel.

A while back, I wrote about my experience building an Android app with Bazel (You can read about it here: Building a Modern Android Music Player App with Bazel…).

Recently, I decided to update some libraries in that project, most notably by moving to the Compose BOM (androidx.compose:compose-bom:2024.12.01).

🧨 The Problem Begins: A Simple Library Update

I updated my MODULE.bazel file with the new dependencies. The initial attempt looked something like this:

I ran the build, and… it failed. I was greeted by a long, cryptic error log, which boiled down to a classic dependency conflict.

Here’s just a small snippet of the dependency graph hell:

At its core, the problem was familiar. For example, looking at the log:

• androidx.activity:activity-compose:1.7.0 (which I was using) explicitly wants androidx.compose.ui:ui:1.0.1.
• But the new Compose BOM (2024.12.01) was pulling in androidx.compose.ui:ui:1.7.6 (a much newer version).

This threw me for a loop. In my time with Gradle, I rarely faced conflicts this severe. Gradle usually seems “smart” enough to just pick the newest version and move on.

🧠 Understanding the “Why”: Gradle vs. Bazel

After some digging, I realized the fundamental difference lies in how these build tools manage versions.

1. Gradle: “Newest Version Wins” (By Default)

Gradle, by default, uses a “Newest Version Selection” strategy. If it encounters a conflict, it simply picks the newest version of the dependency available in the graph.

• A → C v1.0
• B → C v2.0
• Gradle’s Result: C v2.0 (Chosen automatically)

2. Bazel (Bzlmod): “Minimal Version Selection” (MVS)

Bazel, with the introduction of Bzlmod, adopts the “Minimal Version Selection” (MVS) algorithm, which is also used by Go modules (you can read the official documentation on Bzlmod here).

MVS Principle: Bazel selects the minimum version that satisfies all constraints in the dependency graph. This algorithm is highly deterministic and reproducible.

Let’s look at the classic example from the Bazel documentation:

       A 1.0
      /     \
   B 1.0    C 1.1
     |        |
   D 1.0    D 1.1

In this case, Bazel will select D 1.1. Why? Because it's the highest version explicitly required by a module (C 1.1 needs it). It's "minimal" because D 1.1 is the earliest version that satisfies all requirements. Even if D 1.2 existed, MVS would not pick it unless another module explicitly asked for it.

Quick Comparison

| Aspect                     | Gradle (Default)         | Bazel (MVS)                                |
|----------------------------|--------------------------|--------------------------------------------|
| Algorithm                  | Newest Version Selection | Minimal Version Selection                  |
| Version Choice             | Newest version found     | Minimum version that meets all constraints |
| Example (D 1.0 vs 1.1).    | D 1.1 selected           | D 1.1 selected                             |
| If D 1.2 is available      | D 1.2 selected           | D 1.1 is still selected                    |
| Reproducibility            | Medium                   | Very High                                  |

My conflict was happening because MVS couldn’t find a single version that satisfied all the different version ranges being requested.

🧩 The Solution: Finding and Fixing the Conflicts

So, how do we fix this?

A lot of advice online (even from our new AI overlords like ChatGPT, Claude, Gemini, etc.) will tell you to just add version_conflict_policy = "pinned" to your maven.install.

However, this is not enough. This policy only tells Bazel to “pin” the versions it successfully resolves; it doesn’t actually solve the conflict itself. You will still get the same error.

After digging into the rules_jvm_external repository, I found the real solution: using maven.artifact to manually "force" or "override" the version of a specific library.

But… how do we know which versions to pick when the error log is so noisy?

Step 1: Debug and Pin Dependencies

The key is to run this command (from rules_jvm_external) to perform the pinning process and dump the full log:

bazel clean --expunge
bazel run @maven//:pin &> maven_pin.txt

This command runs the dependency resolution process and saves all output (including the detailed errors) to a file named maven_pin.txt.

Step 2: Analyze the Log

Now, open maven_pin.txt. Scroll up from the bottom (or search for "Conflicting dependencies") until you find the root of the problem. In my case, the log looked like this:

...
Resolution error: Conflicting dependencies:
androidx.collection:collection:1.0.0 or 1.1.0 or 1.2.0 or 1.4.0 or 1.4.2 or [1.2.0] wanted by

 androidx.activity:activity:1.7.0 wants 1.0.0
 ├─ androidx.activity:activity-ktx:1.7.0 wants androidx.activity:activity:[1.7.0]
...

The culprit was clear: androidx.collection:collection. Many different dependencies were requesting many different versions.

Step 3: Define a Version and Apply the Override

Now that we know the conflicting library, we can pick one version to rule them all.

1. The Strategy: Try picking the newest version listed in the conflict log (in this case, 1.4.2). The assumption is that this version is backward-compatible and will satisfy all modules.
2. If the newest version still causes errors, try the next-newest version and repeat.

Add this override to your MODULE.bazel file, before the maven.install block:

Step 4: Iterate and Repeat

Run the bazel run @maven//:pin &> maven_pin.txt command again. Check the maven_pin.txt file. If another conflict appears for a different library, repeat Steps 2 and 3 for that library.

For my project, I ended up needing to override several libraries:

After adding all the necessary overrides, the bazel run @maven//:pin command should finally run successfully with no errors.

✅ The Final Result

Now, I could run my project’s build commands as usual:

bazel build //app/src/main:app
adb install -r bazel-bin/app/src/main/app.apk
adb shell am start -n com.amary.my.music/.MainActivity

And… voilà!
The app built and ran perfectly with all updated dependencies 🎉

📦 Source code available here:
👉 github.com/amary21/my-music-bazel

💡Final Thoughts

Bazel’s MVS dependency resolution can feel “noisy” and rigid at first, especially when compared to Gradle’s “it-just-works” approach. However, its deterministic and reproducible nature is invaluable for build consistency in the long run. The solution is to be explicit and provide manual overrides when MVS can’t find a path.

One thing I’m still figuring out is the best way to manage updates to the Bazel rules themselves (like rules_android, rules_kotlin). Updating these often introduces significant configuration changes, sometimes even requiring a Bazel version bump. That's why I'm still using the 2024 version of the Compose BOM in this project; the 2025 version requires at least Kotlin 2, and its compiler has moved to JetBrains, which would necessitate a tricky update to rules_kotlin.

If you have any experience or tips on managing Bazel rule updates, I’d love to hear them in the comments below!

📫 Let’s Connect

• 📧 Email: taufik.amary@gmail.com
• 💻 GitHub: github.com/amary21
• 💼 LinkedIn: www.linkedin.com/in/t-amar

Taming Bazel Dependency Conflicts: An Android Case Study was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a mobile engineer, you’ve probably seen terms like SHA-1 and SHA-256 pop up everywhere—in your IDE warnings, API documentation, and app signing configurations. But what do they actually mean, and why should you care?

Think of a cryptographic hash function as a digital fingerprint generator. You can feed it any data — an entire APK, a user’s password, a simple string — and it will spit out a unique, fixed-size string of characters called a hash.

This article will break down what these hashes are, why the old standard (SHA-1) is dangerous, why SHA-256 is the current champ, and what the fast and exciting future looks like.

The 3 Golden Rules of Secure Hashes

A secure hash function is like a magical, one-way blender. You can put ingredients in and get a smoothie, but you can never turn that smoothie back into the original ingredients. This “magic” relies on three core security properties:

1. Pre-image Resistance (The One-Way Street): Given a hash, you can’t figure out the original input. This is why we store password hashes instead of the passwords themselves. If a database leaks, attackers get a list of hashes, not the actual passwords.
2. Second-Preimage Resistance (The No-Imposter Rule): If you have a file and its hash, nobody can create a different file that produces the same hash. This is crucial for verifying that an app update you’ve downloaded hasn’t been tampered with.
3. Collision Resistance (The No-Evil-Twins Rule): This is the big one. Nobody should be able to find any two different inputs that create the same hash. A failure here is catastrophic, as it means a hacker could craft a malicious file that has the same “fingerprint” as a legitimate one.

The Story of SHA-1: The Fallen Hero

For years, SHA-1 was the king. It was used for everything: signing apps, securing websites (SSL/TLS certificates), and verifying file integrity. It produces a 160-bit hash.

So, what went wrong? In short, it became too predictable.

The final nail in the coffin came in 2017 with the SHAttered attack. Researchers from Google and CWI Amsterdam proved it was practical to break SHA-1's collision resistance. They created two completely different PDF files that had the exact same SHA-1 hash.

Why this is terrifying for a mobile dev: Imagine if a hacker could create a malicious APK that has the same digital fingerprint as your legitimate app update. They could upload it somewhere, and systems that rely on SHA-1 for verification would see it as authentic. This is why your IDE screams at you if you use SHA-1 in a security context. It’s broken. Don't use it.

SHA-256: The Current, Secure Champion

Enter SHA-256. It's part of the SHA-2 family and is the modern standard for secure hashing. It produces a larger 256-bit hash and is structurally much stronger than SHA-1.

Here’s a simple breakdown of why it’s better:

Where you see SHA-256 today:

• App Signing: Modern Android app signing schemes (like v2, v3, and v4) rely on the security of SHA-256 to ensure the integrity of your APK.
• Blockchain: Bitcoin's famous proof-of-work algorithm uses a double SHA-256 hash. Its security is a testament to the algorithm's robustness.
• Networking Security: When you use libraries like OkHttp to communicate with servers, the TLS certificates that secure your connection are signed using strong hashes like SHA-256.

The Future: Faster Hashes and Quantum Threats

The world of cryptography never stands still. Here’s a look at what’s next.

The Need for Speed: Meet BLAKE3

While SHA-256 is secure, it's not the fastest. BLAKE3 is a modern hash function designed for insane performance.

Its secret weapon? Parallelism.

Think of it this way: Hashing a large file with SHA-256 is like one person reading a very long book from start to finish. BLAKE3 is like tearing the book into chapters and giving one to each of your friends to read at the same time. It's massively faster, especially on the multi-core CPUs in modern devices and servers.

For mobile devs, this could mean faster integrity checks for large game assets, quicker processing of large media files, and more.

The Sci-Fi Threat: Quantum Computers

You may have heard that quantum computers will "break" cryptography. For hashing, the threat comes from Grover's algorithm, a quantum search algorithm that makes finding a pre-image (guessing the input from the hash) easier.

• The Impact: It effectively halves the security level of a hash function. For SHA-256, its 256-bit security drops to a 128-bit level.
• Should you panic? No. A 128-bit security level is still considered computationally impossible to break for the foreseeable future. So, while SHA-256 is weakened by quantum computers, it isn't broken.

The crypto community is already preparing for this future by recommending SHA-512 for long-term security (which would have a 256-bit post-quantum security level) and developing entirely new quantum-resistant standards.

Key Takeaways for Mobile Engineers

1. Never Use SHA-1 for Security. It's broken. Listen to your IDE warnings. The same goes for MD5.
2. SHA-256 is Your Go-To Standard. It's secure, trusted, and the industry standard for everything from app signing to data integrity.
3. For High Performance, Keep an Eye on BLAKE3. If your app deals with hashing large files and speed is critical, BLAKE3 is the future.
4. Don't Lose Sleep Over Quantum Computers (Yet). SHA-256 is still safe for now, and the industry is already building the next generation of defenses.

Understanding which hash function to use is a small but crucial part of building secure and reliable applications. By choosing modern, robust algorithms, you're helping to protect your app, your company, and your users.

Follow to stay connected and get timely updates. 🙌🏻

What Every Android Engineer Needs to Know About SHA-1, SHA-256, and Beyond was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.