What's new in Mac Catalyst

Hello and welcome to WWDC.

Welcome to what's new in Mac Catalyst. My name is Jason Beaver, and I'll be joined later by my colleague Brycen Wershing. As you all know, Mac Catalyst is the infrastructure that allows us to bring iOS applications to macOS.

We introduced Mac Catalyst in macOS Catalina as public API, and the developer community has used this technology to bring some amazing iPad apps to the Mac. The apps can take advantage of the much larger display, and many have added custom toolbars and menus.

They get a great deal of the macOS look and feel automatically, making them feel right at home on the Mac.

In macOS Big Sur, I'm excited to announce a number of improvements to Mac Catalyst that will make it easier for you to bring your iOS application to macOS and help you make your app an even better experience on the Mac. One of the biggest challenges developers have faced when trying to bring their iOS applications to the Mac is that many iOS frameworks weren't available to Mac Catalyst apps.

We've worked hard over the past year to bring dozens of additional iOS frameworks to Mac Catalyst, or to bring over missing functionality so that your applications are even more compatible with macOS.

We've even brought over frameworks that aren't available on macOS to make it easier for you to bring your application to Mac Catalyst without having to conditionally exclude code when compiling for the Mac.

For example, if your application is dependent on ARKit, previously, you would need to remove the framework from your macOS target and conditionalize your code so that you didn't reference ARKit symbols when building for macOS.

Now, if you're targeting macOS Big Sur or later, your iOS code can work exactly the same way it would on an iOS device that doesn't support AR.

You can link ARKit and use runtime checks to determine whether your AR features should be enabled.

This, of course, goes for dozens of other frameworks that are now available in the macOS SDK for Mac Catalyst apps.

Now let's focus on some of the new APIs we've added in the past year.

We recently added support for handling physical keyboard events in iOS, and these are available to Mac Catalyst applications in the latest macOS Catalina update.

These can be added to your application by implementing the methods pressesBegan, and pressesEnded on one of the responders in your responder chain. Games can especially benefit from this as an alternative to multi-touch. See the "support hardware keyboards in your apps" session where this will be covered in-depth.

In addition, the focus engine APIs from tvOS are now available to apps in Mac Catalyst. This allows you to set focus group identifiers on your views to control which views are related, and receive callbacks when the focus is changed to allow you to update your UI.

See the technical documentation for details on how to customize what can be focused in your application.

UICollectionView and UITableView allows the selection to follow the keyboard focus. For example, users can use the arrow keys to navigate between the cells in a sidebar. If you're navigating a table or collection view in a detail view though, keyboard navigation acts more as a highlight. In this case, hitting enter or space would trigger the selection of the focused cell.

You can override this default behavior by changing selectionFollowsFocus. UISceneActivationRequestOptions. CollectionJoinBehavior allows you to specify the window creation behavior. By specifying the collection join behavior when activating a scene, you can control whether it appears as a new tab in an existing window, or it appears as a new top-level window.

In an update to Catalina, we exposed the AppKit class NSCursor to Mac Catalyst app. This allows you to hide the cursor in your app, for example, when starting to play a full-screen video.

NSCursor also allows you to change the cursor's image.

Here are some of the cursor images that are available to you. These cursor images can be used over certain regions of your application to help your users understand how to interact with it.

UIKit now includes a color well and a color-picker view controller. In Mac Catalyst apps, this automatically brings up the standard system color-picker that is provided by AppKit.

UIDatePicker now uses the AppKit-provided inline date-picker to make Mac Catalyst apps feel even more at home on the Mac. UIButtons now support bringing up pull-down menus. And on macOS Big Sur, they are regular Mac pull-down menus. You can find more about all of these controls at the "UIKit Menus, Pickers, and Controls" session.

Sheets are now presented in their own separate NSWindow.

These windows are resizable but default to the preferred content size of the modal view controller. Using Autolayout will ensure that your content resizes well.

Popover presentations are now presented in NSPopovers, which have their own separate windows that extend outside of the presenting view controller's window. And finally, UISplitViewController now supports three columns, and the leading column can be a sidebar. Of course, sidebars were supported by Mac Catalyst apps in Catalina, but with Big Sur, we have made them even more Mac-like. In macOS Big Sur, UIKit and AppKit fully support SF Symbols, and they are heavily utilized in the system applications.

SF Symbols integrate seamlessly with the San Francisco system font, so the symbols automatically ensure optical vertical alignment with text for all weights and sizes.

Adopting SF Symbols will make your app work and feel even better on iOS and macOS.

Podcasts uses SF Symbols in the sidebar so that it can adapt well to different sizes without having to include image assets for each supported size.

Now I'd like to hand it over to my colleague, Brycen, to take you through some additional changes to Mac Catalyst. Thanks, Jason. Hello. I'm Brycen Wershing from Core Darwin, and I'm going to take you through a few more of the new features in Mac Catalyst this year. First, a short peek at the new ways that you can optimize UI.

"Optimized for Mac" is a new Mac Catalyst mode that you can choose for your apps that lets you take that extra step towards a truly refined Mac experience.

It changes the default scaling from the 77% we have today, to 100%, which will yield more crisp text and graphics at the cost of potentially disturbing your application's layout.

This change is particularly noticeable for text, such as the word "tarte" in our sample app.

By increasing the default scaling, "tarte" will look more clear and crisp.

Optimized for Mac also allows various controls to change your app's metrics and behaviors to match the Mac. There's also some additional API for access to things like checkboxes, which have not previously been available to Catalyst apps. This is the largest new addition to Mac Catalyst this year. And you can check out the "Optimizing Catalyst UI for the Mac Idiom" session to learn all about it, and how to adopt “Optimized for Mac” in your apps. Next up, let's take a look at SwiftUI. If your app is written in SwiftUI, you don't need Catalyst. But if you're using SwiftUI alongside UIKit in an iPad app, the same code will also work in the context of Mac Catalyst. This year, SwiftUI has a number of new features that will work wonderfully with Catalyst.

Looking at some examples, commands in SwiftUI work delightfully for Mac Catalyst apps. This integrates seamlessly with Mac features, such as the main menu.

The new toolbar support in SwiftUI will work just as expected in Mac Catalyst. With the use of semantic placement, toolbar items can be automatically placed in the Mac toolbar with no extra adoption needed.

SwiftUI works exceedingly well when apps are optimized for Mac, which is expanded on in the "Optimizing Catalyst UI for the Mac Idiom" session.

Generally, the parts of a UIKit iPad app that use SwiftUI will continue to work in Mac Catalyst.

For more information about SwiftUI, check out "What's New in SwiftUI." Now let's take a look at something different: Application Lifecycle.

Application Lifecycle in UIKit revolves around a few states that your application can be in depending on where the user's focus is. There are some big changes to this in macOS Big Sur. As a quick refresher, on both iPad and Mac, an app, when in front of the user, is in the foreground active state.

When the app moves to the background, such as when you switch to another app on the iPad, it will transition through the foreground inactive state to the background state. On Mac, when the user quits the app, the app will terminate.

When transitioning between app states, the delegate calls and notifications on Mac, and the sequences thereof, are the same as on an iPad. If you want to learn more about what happens during a state change, take a look at "Taking iPad Apps for the Mac to the Next Level" from WWDC 2019. Although what happens during a state change is the same on iPad and Mac, there's not a direct parallel for when state changes occur. That being said, there are some approximations that can be made. This year, we've added more scenarios where a scene may transition to the background state, even while the app is perceived to be running. It's worth mentioning that the overall app state in a multi-window app depends on the activation state of the individual scenes. Considering this, you will likely want to handle state changes per scene. A scene will enter the background states when the user no longer perceives the window that contains that scene to be part of an active space. For example, when a window becomes minimized, or the space with the window moves out of view, or the app is hidden, the scene will transition to the background.

In addition, the app as a whole will be foreground whenever at least one window is foreground, or if the app has control over the menu bar.

Let me be clear, your app will not transition to the background when it gains or loses the menu bar while in an active space, or when a window becomes occluded. In summary, we've made Mac Catalyst Application Lifecycle more iOS-like, so that your apps can more easily get the behavior that your users expect.

Looking at an example, say your app is a game. Depending on how that game interacts with the user, you may or may not wish to have that game pause when it moves to the background. Typically, you'll want the same behavior as on iPad. But consider carefully the best behavior for your app on a Mac. Be aware that while Mac Catalyst apps do get all the benefits of AppNap, they do not get the benefit of being suspended, even when in the background.

Now let's take a look at what's new for Mac Catalyst Extensions.

Photo editing extensions are now available. You can bring your great photo-editing extensions to the Mac.

Mac Catalyst extensions now have a more iOS-like lifecycle. One example of this is that when not in use, rather than being terminated, extensions will be suspended, and they will be unsuspended immediately when needed. We've also brought iOS-style memory limits and memory pressure controls to the Mac, making sure that your extensions behave as expected when the system is under memory pressure.

When you put all this together, it means that more of your iOS extensions will work as expected right out of the box on macOS. There's nothing you need to do to get this behavior, it will apply automatically to all Catalyst extensions.

Great WidgetKit iPad widgets can also make great Mac widgets. Simply opt in to Mac Catalyst and your widgets will work just as expected on Mac.

Check out "Getting Started with WidgetKit" to learn all about how to create WidgetKit widgets for iOS and Mac Catalyst. Now let's take a look at a new feature this year, Universal Purchase. Now, when you bring your iPad app over to the Mac via Catalyst, your existing users on iOS no longer have to purchase your app a second time. In addition, the capabilities and App Store metadata of your app can be managed consistently in one place. In other words, any purchase of a Universal Purchase app will result in the user having access to the app across all platforms.

All new Mac Catalyst apps are opted in to Universal Purchase, and may opt out if they choose. To opt out, simply uncheck the "Use iOS Bundle Identifier" checkbox in your project settings.

If you have a non-Catalyst Mac app, or if you have an existing Catalyst app created in Catalina, and you want to adopt Universal Purchase with an iOS app, see the documentation on "Offering Universal Purchase" for instructions on how to enable this for your app. Next up, let's look at Mac Catalyst in the context of the New Look of macOS. Many of the new Mac UIs that have been introduced are also available to help make Catalyst apps. In fact, most of this will work automatically for your apps. Let's walk through a few examples of how your app can take advantage of this new UI.

One new feature this year is toolbar styles. You can experiment with this and make sure that you get a toolbar look that's right for your app. All these looks are now available to Catalyst applications via UITitlebarToolbarStyle. In addition, you can set the toolbar style per window on the UITitlebarForWindows. For more information on all the new toolbar styles on Mac, check out the "Adopting the New Look of macOS" session.

Next, let's take a look at separator items, a tool to help position toolbar items in Mac Catalyst.

When you're crafting the look of your toolbar items, you may want your items to appear in different areas of your app. UIKit provides separator identifiers to help you with this. When you add these separator identifiers to a toolbar, we will automatically create zones in the app bounded by the position of the divider. For example, in the Messages toolbar, from left to right, the compose icon is in the sidebar, then a sidebar separator item indicates a jump out of the sidebar. After that, the "To" field is displayed left-justified, then, a flexible space sidebar item indicates a change in justification. And finally, the Info icon, which ends up on the far right of the app.

The code that describes the Messages toolbar layout is simple and easy to understand. Separator Identifiers are simply added to toolbarDefaultItemIdentifiers method.

That's all that needs to be done to get this behavior automatic.

Now let's look at accent colors. This year, you have the ability to specify a brand color that is used for things like selection. This color will work just as well on both iPad and on the Mac. You simply create a symbolic color in the Assets catalog, and then set it as the accent color. UIKit will use this color for highlights in your user interface.

Use this accent color as an application-wide color. Essentially, it becomes the default tint color of your app. Of course, you can override it locally in specific parts of the UI.

Now let's look at the sidebar. There is now more flexibility for sidebars in your app available automatically. One example is automatic drag reordering for collection views. If you're using collection views in your app, your users will be able to drag and reorder the contained items.

There's no work that you need to do to get this behavior. In general, we're encouraging you to use collection views wherever possible, and with List Layout, adoption should be effortless.

Now, with new frameworks and APIs supported, more iOS code will work right out of the box on macOS.

If you choose to use SwiftUI, it will work wonderfully in your Catalyst app, giving you more options on how to write your app.

With improvements to application and extension lifecycle, at runtime, your Catalyst apps will run just like on iPad.

Now that we have Universal Purchase, app discovery and enablement will be even easier for your users.

And your Catalyst apps will automatically get all the UI improvements that have been introduced in macOS Big Sur.

We're really excited about all the improvements we've made to Mac Catalyst, and the impact it's going to have on your apps.

Thanks for watching, and enjoy WWDC 20.