I want to understand the rationale behind Apple's design decision of not using Pointing Hand Cursor on clickable areas such as Toolbars or Tabbars of applications' user interfaces, and even buttons.

  • Why isn't the cursor choice on clickable areas a Pointing Hand Finger which suggests an area to click on?

  • Should I opt for that or stick with Arrow cursor on my own applications user interfaces?

  • If the applications' UIs are heavily customised (ie. skinned-themed), should cursor choice differ or stick with OS defaults?

Thank you

  • Why are you singling out Apple in this question? Windows does the same thing (arrow not becoming something else when it's over a button or control).
    – wootcat
    Commented Sep 6, 2013 at 18:07
  • I have no experience with Windows. I'm sorry if it sounded as if I was singling out.
    – Phil
    Commented Sep 6, 2013 at 19:49

3 Answers 3


First, I think a better name for what you are asking about is mouse pointer, not mouse cursor. For me cursor evokes the mouse-unrelated text input positioner (as in the Terminal or text editor cursor that you move around with the cursor keys).

Why isn't the pointer choice on clickable areas a Pointing Hand Finger which suggests an area to click on?

Apple wants to reserve custom pointers (other than the text input pointer and the resize window or element pointers) to significate modes within your app, not clickable areas. I guess that the hand pointer is still ubiquitously used in web because at the beginning it was hard to tell hyperlinks from regular text.

From OS X Human Interface Guidelines (I suggest you read them on their entirety before starting to code apps for OS X):

Clearly indicate the current mode. If users can enter different modes in your app, make it easy for them to tell at a glance which mode they’re in. For example, a graphics app might use different pointer styles to indicate whether the user is currently in drawing, erasing, or selection mode. A segmented control can also show which mode the user is in; for example the View segmented control in the Finder toolbar indicates whether users are in icon, list, column, or Cover Flow view. And a popover offers a very strong visual indication of a self-contained task. (To learn more about using a popover in your app, see “Popovers.”)

My best guess is that Apple believes (correctly in my opinion) that the user does not perceive things like toolbars or tab bars. The user perceives tasks he wants to accomplish within your app. The app provides means to accomplish these tasks. Apple doesn't want your user to think that he is using buttons. Apple wants them to use the buttons instinctively.

Now you could say: "But this change in pointer helps the user knowing where he can click on and where he cannot". To that I respond: launch iTunes 11, Xcode 4, Final Cut Pro X, or even Finder. Look at all of these apps and try to decide where the pointer should show a hand and where it should show an arrow. My guess is that you won't reach a satisfactory answer.

There is a myriad of conceptually different clickable elements:

  1. regular toolbars with buttons
  2. sidebars in which you change the main view by changing the sidebar selection
  3. informative displays (labels mostly, but sometimes they become compounded controls) which the app updates when it is performing an operation. They become clickable only when there is an operation going on; clicking gives you more information about this operation.
  4. navigation-bar/drop-down-menu hybrids (e.g., Xcode scheme selection and file selection nav bars)
  5. tabs
  6. ...and more.

After looking at all this some possible "solutions" could be:

Show a hand for all clickable elements! 

Then you show a hand most of the time, why show an arrow at all? In addition, a little arrow is better for pointing than a little hand. See below for more comment on this.

Show a hand only for toolbars (or only for type Y of clickable elements)!

In Apple's mind there are no toolbars, there is your application that does things in different modes. Maybe toolbars make sense for one kind of application but not for others. The fact that toolbars are not mandatory at all precludes for a feature like this to be an OS-wide UX guideline.

Add a new different custom cursor for each different type of clickable area!

This is more confusing than helpful and breaks the "custom cursors significate distinct app modes" model.

Should I opt for that or stick with Arrow cursor on my own applications user interfaces?

I would not opt for what you suggest. Users accustomed to the OS X way will wince at your app if you do this.

If the applications' UIs are heavily customised (ie. skinned-themed), should cursor choice differ or stick with OS defaults?

I would not for the same reason as above.

But I still want to show the clickable areas of my app with a different cursor.

If you want to go for this, what I would do is keep the arrow pointer for everything. Just dim it slightly (maybe 10% opacity loss or a similar effect) on non-clickable areas. I have never implemented nor used an app that does this. I would need to use this to see how it feels before fully endorsing this solution. If implemented properly I can see it being a subtle and elegant way of hinting at clickable elements.

  • Your insistence that a text-input cursor is supposed to be called a "pointer" is incorrect. It's a cursor either way. Only when in text entry can it also be called a "Caret". But other than that, the name for it is a "Cursor". "Pointer" is more of a colloquial term.
    – Arman
    Commented Sep 6, 2013 at 16:51
  • Hmm, I re-read my message and your edit and I think there is a misunderstanding. I am not calling pointers to text-input cursors. I meant to say that I believe mouse pointers should be called pointers and not cursors. Commented Sep 6, 2013 at 16:57
  • Also, being rude was not my intention at all. Sorry if my tone reflected that. Commented Sep 6, 2013 at 17:03
  • 1
    Discussion about semantics of cursors and arrows, I find this an excellent, enlightening and a thoroughly prepared answer. Thank you very much for sparing your valuable time to compose this, @RicardoSánchez-Sáez. It has helped me, and it will help many others greatly. If you had a blog, I'd follow. ;-)
    – Phil
    Commented Sep 6, 2013 at 19:54
  • @Phil You make me blush! Very glad to be helpful. ;-) Commented Sep 7, 2013 at 10:26

Apple design guidelines state:

Discoverability. Encourage your users to discover functionality by providing cues about how to use user interface elements. If an element is clickable, for example, it must appear that way, or a user may never try clicking it.

The idea is that clickable elements should be recognised as such without hover. This is even more important with the growing popularity of touch devices.

See this question for more.

And you should try to adhere to the platform guidelines, unless it makes no sense in your particular case.

  • Thank you very much @Izhaki for the quotation and the clear reply.
    – Phil
    Commented Sep 6, 2013 at 19:55
  • This is insightful. I missed this bit on my answer but I endorse this advice as well. ;-) Commented Sep 7, 2013 at 10:33

If I look at my screen, pretty much everything is clickable. Pushbuttons, scroll bars, sliders, icons, menu titles, window edges, browser tabs, list items, column headers. Text can be dragged in to select and copy parts, in some cases even to edit it. Window titles and bottom bars can be dragged to move the windows.

So my explanation would be that the information density on the typical computer UI is so high that you'd have the hand cursor everywhere, which is effectively just like it is now, just that an arrow is used instead of a hand. It would make more sense to show a special "un-clickable" cursor over areas that can't be clicked.

But I wouldn't even do that, as the UI itself (according to Apple's Human Interface Guidelines, even) should be designed so it is obvious which parts are clickable and which aren't. That makes sense, as otherwise the user would have to wave the mouse over the screen like a metal detector to find clickable hotspots, like the dreaded "mystery meat mouse-over navigation" on some web sites.

That only web links use the hand cursor approach makes sense because there is ambiguity. Underlined text could be just underlined text, so this way you can verify that something is clickable in this degenerate case.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.