At WWDC 2018, Apple announced a slew of new apps that were ported from iOS to macOS: News, Stocks, Home, and Voice Memos. These apps are interesting because Apple also announced that these apps are not using AppKit, the native framework that Apple provides for developing macOS applications. Instead, they use UIKit, the equivalent but more modern framework for iOS. Apple is working extending UIKit to be able to run on macOS and provide some translations from UIKit-style widgets to something that feels more natural on the Mac. In the future, this will available to third-party apps as well.
Various people observed that this provides an interesting alternative to Electron. Many companies build their iOS apps using native UIKit, but rather than invest in an AppKit app for macOS, they’ll build one web app and then use Electron to package the web app as a desktop app for the various platforms they need to support. I’m not super fond of this approach for various reasons, and I do think that developers being able to port their iPad apps to macOS will be nicer than using Electron. That said, I want to talk about one particular thing that’s always irked me when using Electron apps and that I’m worried will also be an issue when developers start being able to port UIKit apps to macOS.
Native Mac apps care about the menu bar. Non-native apps don’t.
What’s so great about the menu bar?
The menu bar is an important part of a Mac app for a pretty simple reason: it makes apps easier to use. Apple’s Human Interface Guidelines explain this better than I can:
People look in the menu bar when searching for app-specific commands, especially when using an app for the first time. Even when commands are available elsewhere in your app, it’s still a good idea to provide access to them via the menu bar. Doing so makes them easier for people to find, lets you assign keyboard shortcuts to them, and makes them more accessible to people using Full Keyboard Access. It can be appropriate to exclude infrequently used or advanced commands. Just keep in mind that you risk people missing commands that aren’t in the menu bar—even for experienced users.
By having a menu bar that accurately captures the capabilities of your app, you make it easier for users to discover what your app can actually do. The menu bar provides a map of your app in a way that is much more explicit and clear than any other UI you have.
Electron apps totally have a menu bar!
This is technically correct. It’s not like they just have the application menu and nothing else, like some old Java apps would do. But every Electron app I’ve used has had a very minimal menu bar. Here’s a few examples from Electron apps I use.
There’s definitely some customization happening in these apps: their menu bars are not identical, and there are a few menu items specific to each app. They mostly involve navigation between various areas of the app. But compare this to a native Mac app like Calendar.
Calendar has similarly few menus, but they contain most of the useful functionality that Calendar provides. The File, Edit, and View menus expose a bunch of functionality would be hard to discover otherwise.
Why does this happen?
Building a comprehensive set of menus for your Mac app is a non-trivial amount of engineering work. Even when you’re working with AppKit building a native app, nothing is going to force you to have amazing menus. I think we see better menus on AppKit apps for two reasons:
- Adding menu bar items is one of the most straightforward ways to add keyboard shortcuts to an AppKit app. While using menu items for keyboard shortcuts is also supported in Electron, most existing web apps probably have other ways to operate via the keyboard so that they work in a browser as well.
- Web apps expect to run in contexts where the menu bar is nonexistent (the browser) or where its importance is downplayed (Windows, Linux) in comparison to macOS. It’s just not as important to you if a large portion of your userbase won’t ever see it. AppKit apps have already embraced running on macOS and are therefore more likely to invest in blending in with the platform’s conventions.
Both of these reasons are exactly why I’m worried that UIKit apps running on the Mac will also put minimal effort into their menus.
- UIKit already has an API for adding keyboard shortcuts that has nothing to do with a menu bar.
- Apps using UIKit are expecting to run on iOS, which has no menu bar at all.
I’m not trying to make a moral argument that developers are wrong or bad if they don’t give their apps good menus. It’s a tradeoff, and engineering is full of them. I just think that apps embracing the menu bar is part of what makes a Mac nice to use, and it makes me a little sad to imagine less and less apps caring about it going forward. Consider this my plea to developers building Mac apps, regardless of toolkit: please consider the menu bar.