Qualities of great iPad and iPhone apps on Macs with M1

Hello, my name is Nils Beck, and I welcome you to "Qualities of great iPad and iPhone apps on Macs with M1." More than a million iPad and iPhone apps are already available on the Mac App Store. The experience is great on macOS Big Sur, and we've further improved it in macOS Monterey. In this video, we'll discuss how we mapped several iOS APIs to the corresponding Mac features, some general best practices to keep in mind that will also help your app shine on Macs with M1, improvements that we made in macOS Big Sur software updates, as well as in macOS Monterey, and then we'll finish off with Mac App Store deployment considerations. iPad and iPhone apps on Macs with M1 are the easiest way to expand your existing app's reach to the Mac. This is your unmodified iPad or iPhone app, as submitted and approved for the iOS App Store, offered through the Mac App Store to anyone with an M1 Mac. To make this possible, we focus heavily on compatibility. System APIs are mapped to their natural Mac equivalents wherever possible. Our aim is to ensure a smooth app experience on the Mac without you making any changes. And most existing apps work great! This includes everything from small iPhone utilities to cutting-edge iPad games and Pro Apps. A variety of extensions are also supported. For example, share extensions, WidgetKit widgets, photo editing extensions, VPN network extensions, audio units, and more. So, it's very likely that your existing iPad or iPhone app already works well on the Mac, right out of the box. Of course, we support all basic functionality, such as text interactions, copy and paste, a Mac menu bar, and so on, but there is also a lot of advanced functionality, like background app refresh, user notifications, camera access, Siri intents, and more. Many of these topics are discussed in the video, "iPad and iPhone apps on Apple silicon Macs," so check that out for more details. And when you want your app to take advantage of even more of what the Mac has to offer, consider building a Mac Catalyst version of your app. You can learn more about that in the videos, "Qualities of a great Mac Catalyst app" and "What's New in Mac Catalyst." Now, let's dive into more detail for some of the APIs I just mentioned. You are likely already using these to make your app great on iPad and iPhone, and we've bridged them to seamlessly give you the same great features on the Mac. Naturally, you can use the Mac keyboard for text input into text fields, as well as for UIKeyCommand keyboard shortcuts. But if you need more control and want to write your own keypress handling, you can do that with the UIPress API on UIResponder. All Macs have a physical keyboard, so apps that have taken the time to add support for physical keyboards on iPad and iPhone are greatly improved on the Mac at the same time. Next, let's talk about the menu bar. As a reminder, the Mac menu bar is intended to help with the discoverability of app features and keyboard shortcuts. The menu bar structure is determined at launch, and should remain more or less constant after that. Items are not added or removed, but rather, they get enabled or disabled, depending on whether they currently apply.

We automatically populate your app's menu bar, taking into account your app's features. For example, we might add menu items to create a new window, to work with rich texts, or to change the device orientation. Note that UIKeyCommands that are directly attached to UIResponders through the keyCommands property do not appear in the menu bar, but their keyboard shortcuts will take priority over the shortcuts of menu items, whenever they apply. You might already be using the more recent UIMenuBuilder API that we introduced in iOS 13. This adds semantic structure to your UIKeyCommands. This structure is visible in the Keyboard Shortcuts menu that appears when you hold down the Command key on an iPad with a keyboard. On the Mac, the default structure that gets passed into the builder will be different, but your customizations to the structure will be reflected in the main menu. UIKeyCommands rely on the responder chain to find an applicable target for their action, and this determines whether or not a menu item is enabled. For much more on this, check out the videos, "Take your iPad apps to the next level," "Focus on iPad keyboard navigation," and "Qualities of a great Mac Catalyst app." For apps that use drag and drop on iPad and iPhone, using UIDragInteraction and UIDropInteraction, this automatically carries over to the Mac as well. This lets people seamlessly drag content between your app and others, like in this example, where I'm dragging a QR code from Qrafter to my desktop. And for apps that print with UIPrintInteractionController, this is automatically bridged to a Mac print dialog when printing is initiated in your code. Even better, when you adopt the new Info.plist key "UIApplicationSupports PrintCommand" and implement the corresponding standard print action, the Print and Export as PDF menu items will be added to your app's menu bar automatically. For more details on this new API, check out "What's new in Mac Catalyst." Many apps use a settings bundle, and we will automatically generate a Mac-style preference panel from this. It is also common to put credits in the settings bundle, and we identify such cases and move that text to the About box for you. But if you want more control over what is shown in the About box on the Mac, you now also have the option to add a credits file to your bundle. You can use RTF, RTFD, or HTML files, the same way Mac apps do this. There are a number of iPad-centric APIs that will help make your app a great iPad app. These all come across wonderfully on the Mac.