Custom Segmented Controls for iPhone

The Devil is in the Details

by Petter Silfver Reading time 3 minutes
Custom Segmented Control for iPhone

First of all, I need to warn all readers that the type of user-interface nerdery that is the subject of this short article might actually be unhealthy.

It happens to be that I am currently working in an application project where we have been putting a lot of time polishing the visual details of a custom segmented control. Of course — as a part of the design process — we have been exploring the landscape and looked at designs of other applications to get inspired. This article is in no way an analysis of the graphical design that I encountered, they were all looking really great. No, this is about one tiny detail in the interaction with the standard segmented controls in iOS that either no one thinks of, or everyone ignores when they implement customized design solutions.

The standard segmented controls in iOS

The first time I did some evaluation and user testing with an application that contained a segmented control, I was a bit worried on how it was going to be perceived and used. To my great satisfaction the standard segmented controls works almost flawlessly as an interaction paradigm for iOS applications. Be it filtering a list, using it for different perspective on a data set or dividing one function set into smaller integral sub-functions; the segmented controls simply gets the job done. iOS provides three kinds of look and feel for the segmented controls, and should be used dependent on the UI that you are designing.

The standard segmented controls in iOS

Figure 1 — Left: Segmented control in the navigation bar. Middle: Segmented control as mean of filtering (also known as Scope bar). Right: Segmented control in an input form.

So, what is the fuss all about really? Well, I will no longer keep you in suspense! A while ago, a colleague of mine (@fwilliamsson) made me aware of the fact that the standard segmented controls in iOS – as opposed to almost every other tappable UI element – switches instantly as the user touches the screen, and not as the user releases the finger. Every custom implementation I could find on my iPhone has failed to conform to this fact, even Apple’s own Game Center application.

Gowalla, Game Center and PositionApp

Figure 2 — Left: Gowalla’s customized segmented control, Middle: Game Center’s customized segmented control, Right: PositionApp’s customized segmented control.


Which way is the right way? One could absolutely argue that it is weird that almost all buttons and controls in iOS listens to when the finger is released, except for the segmented controls. My theory is that Apple designed it this way because when a segmented control is used in the right way and in accordance with human-interface guidelines, it should not interrupt or navigate the user in any way. Since this is a pre-requisite of its basic function, it might actually be that they felt it would be perceived as a bit snappier if it did not wait for the finger to be released.

Does it really matter? Naturally, it is almost impossible for me to answer that question without having access to any information about Apple’s design rationale of the iOS user-interface. But, I am sure you have read a bunch of articles by user experience enablers like myself that every detail contributes to the perceived experience. In this case, my gut feeling tells me that making the switch on touch and not on release is the way to go when you decide to implement a customized segmented control.

The details are not the details. They make the design.

Charles Eames

If you have any kind of feedback or input for improvements, just hit me back or via .