How I made a perfect recording button. Simple yet complex thing.

Intro

From the start of :



iOS 26.5

As you can see, the button becomes disabled while it starts recording. This makes me feel slightly uncomfortable every time I press it. I feel unresponsiveness and heaviness. And I need to wait before I can stop recording.

Talat 0.11.5

MacWhisper 13.21.1

The button is locked during start.

XSpeak 3.7

Implementation

I'll not write a book here about all the approaches I considered and tried. Instead, I'll go from a naive approach to the solution I implemented.

Let's agree that we want instant feedback from the button and will not disable it during our startup chain. Also, let's declare our states:

In the end, we have S_ui = stopped and S_real = started.

We have to linearize this pipeline to prevent such races. The first thing that would help is to prevent start and stop operations from running simultaneously. We'll use a queue for that:

When we want to start or stop recording, we submit an operation to the queue. This way no two operations overlap and each operation waits for its time. As a result, we always have S_ui equal to the S_op of the last operation.

However, this results in delayed work that doesn't start immediately. We still want to give immediate feedback to the user. To achieve that, we'll work with S_ui from MainActor and with S_real from Queue. This means that when we press the button, S_ui changes immediately, and the work is submitted afterward. The solution gives us the following challenges:

1. When the actual queue operation starts, the world could have changed, and the operation might not be necessary anymore.


2. If the queue grows, there might be significant delay. Imagine a situation when the button is pressed 100 times in a row. We'll have 100 operations 0.5s each, resulting in 50 seconds of work.

The world could have changed during the time we waited for the operation to start. It means the user could have stopped the recording, started it again, or even in a corner case, done it several times. To determine if the operation still makes sense, we should compare each operation's S_op with the current S_ui and S_real. If S_op is started and S_ui is stopped, we shouldn't start anymore, so we just exit. The same is true when S_op is stopped, but S_ui is started. Additionally, if S_op already equals S_real, the work is already done, so we exit as well.

This means that the first and the earliest operation whose S_op equals the current S_ui and not equals S_real will perform the work. This change results in a significantly reduced delay between submission and actual work start.

There's one more thing we should do to improve performance further. Imagine the following order of operations:

At every suspension point we re-check the target state. If it changed, we drop and return.

In practice, there are more complexities because sometimes we have non-standard user flows. But this architecture, where every audio manipulation goes through the queue, allows us to maintain a consistent and reliable state and gives us a good background to improve the app.

All product names, logos, and brands are property of their respective owners. Use of these names, logos, and brands does not imply endorsement.