Design

How to make absolutely any app look like a macOS app

If you’re interested in translating or adapting this post, please.

What makes a native macOS app …look like a native macOS app? In this article, we’ll analyze this question and look at some practical ways you can adopt the design conventions of macOS apps in your own apps. You’ll be able to make design decisions so that your apps fit right in, thus, offering a more seamless experience as well as other potential benefits—read on!

Although this article deals primarily with the “native macOS look”, it’s important to note at the outset that many of the features and concepts below also apply to Windows apps. And further, it’s also worth mentioning that since in recent years the line between websites and desktop apps has become more and more blurred, meaning many of these conventions apply for web apps, too.

This issue recently came up when we worked with the httpie team on their app—we wanted to make it look like a native desktop app.

So, now that we have a shared understanding about what we’re shooting for, the question is—why might one want their app to look like a native app in the first place? Well, beyond the obvious fact that having similar design conventions allows for a more “seamless” experience for our users, I think the consistency of appearance that comes from an app which appears to have a “native” design also carries a more “credible” feel. The design seems more thoroughly considered, and overall, the application also somehow feels more stable in terms of performance.

If you’re developing a UI for pros (think Figma, Codepen, or xCode) check out this article: how to design interfaces for developer tools

These benefits should be an important consideration when thinking about the user experience that your application offers, and, in my opinion, are some pretty compelling reasons to incorporate native-looking design conventions into your work. So, let’s jump in and start looking at some specifics!

What makes a native desktop app a native desktop app?

Use the default cursor, not a pointer

While the pointer cursor (the finger version 👆) is ubiquitous in many contexts on the web, native desktop apps use it for one particular purpose: links opening a page in a browser. Usually, the links are styled as real text links.

We see how the cursor changes to a finger when over links that open the browser in macOS apps

But even this simple rule is often broken.

For example, in the Resources subsection of About This Mac, some links open a web page, but they still use the default cursor to maintain consistency with the other list items:

The cursor to finger rule is broken often, as we see on the Mac's resources page

So, it’s up to you how strictly to follow the “link rule”.

Make text non-selectable by default

Users can only select text in labels that the developer has explicitly made to be selectable. But how can we decide what should actually be selectable? Well, this is another gray zone that requires a deep understanding of your user workflow.

Simply put, everything that users might want to select should be selectable. Here’s an example case: in the About This Mac window, you can clearly select the OS version, model name, SN, and other “content”—but you can’t select the technical labels themselves.

As we see on the About this Mac menu, the text of the main heading is not selectable, while the details are

Don’t make styled buttons, dropdown menu, or checkboxes react on a hover

This is a quick tip. In terms of how they react to hovers, there are two types of buttons used in native apps. In short, styled buttons, dropdown menus (more on dropdown menu items in a bit), and checkboxes don’t react to mouse hovers, while ghost buttons (plain text or icon) do.

We see how different artifacts handle hover effects within MacOS. styled buttons, dropdowns, and checkboxes do not react, but ghost buttons do

Don’t give menus and tables hover effects

Menu and table items don’t have a hover effect.

In Apple music, we see the no hover effect in action

And this is true even if a menu item or a table row has a secondary action button revealed on hover—the item background doesn’t react. This technique, combined with the previous one, makes the interface seem quiet and less verbose.

We see how actions can happen on hover, like a submenu appearing inside Apple music

However, let’s note that dropdown menu items do react on hover. This is done for keyboard navigation purposes–users using a keyboard should see which option they are about to select.

We see the background color of a dropdown menu item change as it is being hovered on

In addition, app menus and lists highlight the selected item. This provides users with visual anchors to allow for quicker orientation and navigation within the interface.

Ensure that pressed states are either subtle or glaringly obvious

Like in the example of the 3D map below, if a button turns on or toggles an obvious mode the button background is subtly highlighted.

Inside Apple maps, it is clear the the 3D effect is toggled on because it is subtly highlighted in the user interface

On the other hand, if it’s not obvious that a mode might be toggled or turned on, the button applies the active color for the foreground.

In the notes app, the filter is clearly toggled on because the color change indicating this is dramatic

Put RMB contextual menus everywhere

On the web, custom handling for RMB (Right Mouse Button) clicks is exceedingly rare, and, I’d even go so far to say, unexpected. But in the desktop world, it’s completely natural to have RMB handling. Menus and lists have it for quickly deleting or editing an item.

But, there’s a catch. Once you override standard RMB click handling (in the browser or Electron), you’ll have to re-implement all the standard actions like copy, cut, paste, and so on.

Summing it up

Let’s recap. For an interface (web-based included) to look like a native macOS app, consider:

  1. Dropping pointer cursors
  2. Prohibiting non-content text selection
  3. Reducing hover effects
  4. Not overusing the accent color
  5. Adding RMB contextual menus

By the way, if you have a project and need some Martian assistance, talk to us! Evil Martians are primed and ready to supercharge or kick off your digital products, solve your problems, and deliver results.

Humans! We come in peace and bring cookies. We also care about your privacy: if you want to know more or withdraw your consent, please see the Privacy Policy.