At the end of the previous post in this unexpected series about iOS Safari’s tab control design, I wrote:

This is how interaction systems slowly fall apart. […] It is likely that Safari’s exception will now be treated as “blessed,” and start spreading further. Given enough time, more and more pills will go in whatever direction they want when dragged – and people will learn not to trust any of them.

I didn’t quite get this right, as it seems this has already happened. It might have been Safari that used a “blessed” interaction from elsewhere. Conversations with a few readers helped me piece together a larger story of how we got here. I fired off some of my old iPhones and emulators to verify them, and so let’s go back in time all the way to 2007.

Step 1: These rotary controls for timers have been here since the first iPhone. Note how you drag the background, not the selection, but that works because the background is styled as a physical object, you see the options extending in both directions, and the selection remains fixed in place.

Step 2: In iOS 7 in 2013, the camera app adopts a similar treatment, but on a horizontal plane. This is roughly as above, flattened, but with the background still extending in both directions, showing adjacent options. This also made some skeuomorphic sense because this control is very “mechanical” – you could imagine such a wheel on a real-life camera.

Step 3: In 2023, Safari follows in those footsteps for its tab groups (which originally was a more traditional menu). It might have felt like the right thing to reuse, but the control doesn’t feel as refined as the Camera’s. It also introduces the problems where tapping no longer scrolls to the initial position (mentioned in part 1) and the too-eager tab group creation overflow (mentioned in part 2).

Step 4: This is where the trouble begins. Camera gets redesigned for iOS 26 and liquid glass. The team decides to rearrange and simplify the control visually, but at a price of making the interactions feel more complex: there are now only two items visible by default (the background doesn’t extend to hint at other options in its resting state), the current selection no longer stays in place, and the control generally suggests tab-like interactions but doesn’t provide them.

Step 5: At some point in the beta process, the Camera team perhaps realizes the same thing I found challenging in part 2 – these now look like pills, and elsewhere the system taught us finger drag moves pills rather than the background. In iOS 26 beta 4, the direction is reversed compared to all previous versions of the app.

Step 6: Seemingly almost immediately, people complain, since many years of motor memory are now compromised. So, in beta 5, Apple adds a setting called “classic mode switching” – similar to natural scrolling years before, on macOS side.

Step 7: However, not long after that, in beta 6, Apple removes the setting and reverts to the original direction from steps 3–4.

Things that come to my mind:

• Inverting the control to go the other way in step 5 was where the consequences of previous steps reared their ugly head. I imagine perhaps the strength of complaints surprised Apple, which found itself without a backup plan, between the rock and a hard place: earning either the immediate ire of power users (whose motor memory was disrespected) or the future ire of other users (who will experience no consistency between pilled controls going forward).
• Adding a setting would be kicking the can down the road, but so is – as I hoped to establish in part 2 – leaving things as they are: There’s still a systemic problem where controls in Camera and Safari are now at odds with other pilled controls.
• What makes a control a control is not paper principles, but a collection of details working together. Removing the extended background, restyling the control, and making the selection no longer stay in place might feel like small changes in isolation, but at some point Theseus would like a word. I see this sometimes in other surfaces, where individual UX changes compound over time, become basically dead reckoning, and result in a boiled frog.
• I wonder if Apple succumbed somewhat to the “dumb consistency” problem: often it’s better to be inconsistent in a smart way than consistent in a dumb way. It might feel good for all the tabs and the pills and the toggles to look the same visually, but that feels like dumb consistency if they behave differently. It might seem good for Safari to reuse Camera’s toggle, but the Camera is generally a one-of-a-kind, bespoke app, so it has some leeway here. Safari doesn’t really get to play by those rules.
• I am curious why the Camera team didn’t invert the direction and the ordering of things. In this case, two wrongs would make a right, and this would keep the motor memory intact. (I imagine the reason is that this would trip up people who remembered things cerebrally, rather than “in their fingers.”)
• I feel the team wasn’t given or didn’t give itself enough time, which jibes with how unpolished the entire liquid glass effort was in its first year. In a perfect world, the camera control would probably have been redesigned again before launch to avoid tricking the motor memory – or perhaps the whole original iOS 26 change reverted.

That’s Camera. Where’s Safari in all that? Just where it started: Safari’s control today again seems just like a cheaper, more hurried, less thoughtful version of what Camera does. The Camera toggle doesn’t have the jarring “swipe to the left to create a new space” flow, doesn’t need to support tap to top, shows you the background affordance more readily, uses haptics, feels less buggy, and even only allows you to swipe one notch at a time, so the control feels precise and never runs away from you.

In the just-released iOS 27, the Camera is even slightly improved – it again shows more of its surroundings even before any swipes.

I haven’t noticed any updates to the Safari control.

The story of this entire system now appears to be this:

• The Camera team made mistakes that could have been avoided; changes to deep motor memory do take years and have to be planned and approached with patience.
• The Safari tabs have been drafting behind the Camera tabs, but still introducing smaller mistakes of their own: continuing to prioritize strange interactions in lieu of intuitive ones, and forgoing some of the nuance.
• Both look like pills and, when dragged, go in the opposite direction as other pills in the system.

In all these screengrabs, I’m dragging my finger to the right:

I don’t, of course, know all the details, and I realize I am harsh in my assessment. I sympathize with the depth of the challenge not just for the team – motor memory can be brutal, and established interaction systems are really hard to evolve – but also in coordinating with other teams in a closed-off culture like Apple’s.

Then again, these are iPhone’s top-tier surfaces so I think it’s fair to expect excellence, and this is also not the first time Safari team has made some puzzling design choices. Perhaps most importantly, Apple is also the platform owner and they set the tone for other apps, which we’ve seen recently in their indirect influence over CleanShot’s settings.

I hope you found some interesting things in this long post. As a reminder why it all matters, and why protecting systems of interactions like tap to top (part 1), or slide on an object to move it in a predictable way (part 2) is important, this is a quote from one of the readers:

It’s actually worse [in Camera], because often you are in a bit of a hurry to take a picture and it behaving unexpectedly is the last thing you need. I had this once or twice: suddenly it was in video mode and by the time I had it back in regular photo mode, the train I was trying to photograph was long gone.

I’ll be curious if we see more evolution of these spaces, and hopeful Apple resolves the problems. But now, I’m ready to stop talking about Safari’s tabs for a while.

Thank you to Nikita Prokopov, Daniel Dickison, Jeremy Kanter, and Martin Hoffman.