Discover how to tailor your Mac Catalyst app so that it looks and feels even more at home on the Mac by using the new “Optimize Interface for Mac” option in Xcode. Explore new layout and appearance options for Catalyst apps, and learn how they can provide you with graphical performance gains, sharper text, and an interface designed specifically for Apple's desktops and laptops. We'll show you how to take advantage of these options and provide best practices for organizing your code when developing for multiple platforms.
Developers actively working on a Mac Catalyst project will get the most out of watching this session. If you're new to Catalyst, we recommend watching “Designing iPad Apps for Mac” and "Introducing iPad Apps for Mac" for an introduction.
For more on working with Mac Catalyst, check out "What's new in Mac Catalyst”
Hello, my name is Nick Teissler and I'm a Cocoa engineer. Later, I'll be joined by my colleague Jake Carter.
Today we're going to tell you how to optimize the interface of your Mac Catalyst app.
The next level of Mac Catalyst app is what we call "optimized for Mac." Optimizing for Mac gives you Mac-like visuals and controls that aren't available to Catalyst apps scaled to match the iPad. Opting into Optimized for Mac is a build setting change that takes effect at launch time. An app optimized for Mac launches in the Mac idiom. Catalyst apps scaled to match the iPad launch in the iPad idiom. This particular setting won't have any compile time implications so you won't have build errors or framework issues if you're optimizing a Catalyst app scaled for iPad and we recommend you start with a Catalyst app that has already gone some work to bring into the Mac.
There's a lot you should do before optimizing for the Mac, like adding menu bar actions with keyboard shortcuts or handling right clicks in your interface with the UIContextMenuInteraction APIs. See these sessions from WWDC 2019 that review features you can enter your Catalyst app before optimizing the interface for Mac.
So let's look at what we mean when we say optimized for Mac. What exactly is getting optimized? Optimizing for the Mac is all about more Mac-like visuals.
So when you bring your iPad app over as an optimized Catalyst app we render that content one to one. Compare that to the 77 percent downscale when Catalyst apps are adjusted to match your iPad views. In that case 100 points in your code becomes 77 points on screen. When optimized for Mac, 100 points in your code is always equivalent to 100 points on screen. Not scaling your content paves the way for many more visual improvements throughout an app. If you use controls like UIButton, UISlider UISwitch, UIActivityIndicator and more these will render as MacOS system controls. Here, you see a system iOS button that will render as a system Mac button when optimized. These new control appearances will have sizes and metrics matching controls on the Mac. It's likely they won't be the same size as your iPad appearance, so your layouts might be a little bit altered. Catalyst optimized for Mac adjusts text style sizes like Body, Title and Call Out to match the Mac.
Unlike Catalyst apps scaled for iPad the rendered text is no longer scaled.
The text style sizes are different. For example, the Body Text style returns 17 points on Catalyst apps scaled to match the iPad whereas it returns 13 points on Catalyst apps optimized for Mac. The true font sizes will look noticeably sharper than the scaled font sizes. This also means if you have hardcoded font sizes, these will not be adjusted and your UILabel or UITextField might feel sad. A small part of it, probably about 23 percent won't feel home when it's on the Mac. A final more straightforward change to be aware of is that auto layout will use Mac spacing if you're building constraints with the system spacing methods. The system spacing is typically larger on the Mac than in iOS. So these are the high level features that you will get if you choose to optimize your Mac Catalyst app for the Mac.
It may take a minute to mentally position Catalyst optimized for Mac in the growing set of options available to you to bring apps to the Mac. Catalyst optimized for Mac is an alternative to Catalyst scale to match the iPad.
You can't have both. Let's compare the two more directly. So first one doesn't obsolete the other. Scaling to match the iPad might certainly be a better fit for your app and we'll continue to see great apps running in both idioms. The scaled option is a fast path to a Mac app. It will get your app running on the Mac. You shouldn't need to refactor all of your apps views to get a great version of your app on the Mac. And that's part of the philosophy behind scaled apps. So you make some tradeoffs to get your Mac app up and running quickly. The tradeoffs you make might be more or less desirable depending on the specifics of your app. Optimizing for Mac is a possible next step. A scaled app favors compatibility with your iPad app. Catalyst does everything it can do so you don't have to make app-wide code changes to get an appearance that fits in great on the Mac. An optimized app favors an authentic Mac look and feel. Catalyst swaps in Mac controls and unscaled text sizes to make an app's interface look its absolute best on the Mac. Because scaled apps favor its compatibility with the iPad version of your app, your layouts are preserved as much as possible.
Most times you don't have to make any changes for your view to lay out properly on the Mac. But given that optimizing gives you a completely different look for controls, you'll need to do some layout work where you've made implicit assumptions of the sizes of controls. Now that we understand what is optimized and the differences between the idioms, we should start thinking about which apps can gain the most from opting in; which apps want to be optimized to look their best. Apps that show lots of text can see noticeable visual improvements. This is because they get the true text sizes instead of scaled text. Swift Playgrounds is a Catalyst app optimized for Mac this year on Big Sur. The rich text editor in Swift Playgrounds drives the app's visual appeal. So it makes sense to undertake the work and see these benefits. Apps with certain emphases on graphics have potential for improvements too. Graphics intensive apps that use Metal or SceneKit saw significant improvement in our experience. Swift Playgrounds uses SceneKit in their Learn to Code series. After optimizing for Mac Swift Playgrounds saw higher frame rates and lower power consumption on Macs with both integrated and discrete graphics systems. Another type of graphics emphasis is highly custom, detailed artwork. The differences between scaled Catalyst assets and optimized ones is identical to the visual differences you see if you display a PNG scaled to fit a particular size rather than in its natural dimensions.
You can quickly evaluate how your app will look comparing the two versions side by side. The artwork in MapKit is a great example of this. MapKit has literally a world's worth of custom designs and icons. Looking at the magnified versions of the pixel-perfect iconography created for place marks, we can see the difference between scaled and unscaled artwork. On the left here is the scaled icon that the California Academy of Sciences uses. On the right is the unscaled image. See how you can count the windows and pillars at the front of the building. Some of that fine detail is lost in a scaled graphic.
Just down the road is the De Young Museum. Here too, the unscaled asset and even the text is sharper. Finally the Guggenheim Museum. The rounded architecture is represented more fully in the unscaled MapKit asset. Icons are rendered much smaller on the screen. So the visual differences aren't as obvious to users as we've displayed them here.
But this still generalizes throughout MapKit. In dense cities like Paris at a low zoom, having that resolution to show detailed road networks is a strong motivator for optimizing your Catalyst app if you use MapKit prominently.
Another trait that can make an app a good candidate is having many control views, like a popover showing some adjustable value. That view would likely fit in better if optimized for Mac. Maps takes advantage of this using the checkbox here, which fits in better than a sliding switch might. Finally the state of your third party dependencies could be a limiting factor for your apps candidacy. For all of you framework developers out there, supporting a Catalyst target might not be enough especially if your framework is UI-focused. You likely need to support optimizing for the Mac, so you don't limit your clients. Jake will show you how to make changes to your code to support the Mac idiom later. Now we'll look at how optimizing for Mac affects a view from an app scaled to match the iPad. On the left is a simple view showing the beginning of a recipe for a tart. The layout is built with stack views and contains five elements. A button, a label, a slider, an image, and a text view. Watch closely as I optimize this for Mac without making any layout adjustments.
Phew. Looks like our layout held up OK. The first difference that jumps out to you is probably the system iOS button on the left changing to the system Mac button on the right. This causes the button to have a different size at runtime and depending on how you lay out your views, possibly a different origin. Let me draw your attention to the windows. They're exactly the same size and points on the Mac screen.
Remember though, the point sizes of the window on the left and all of its contents are actually 77 percent of the sizes in your app's code. This is the behavior from the first release of Catalyst on Catalina. But keep that in mind as we go through the rest of the changes. Next, take a look at the leading edge of each window. The space between the leading edge of the window and the text view is noticeably smaller on the left than on the right.
As we saw before, system spacing values are generally a bit larger on the Mac.
This means though that there is more horizontal padding on the view optimized for Mac. This gives that view less available width to layout in. And this is the reason that the text has wrapped an additional line and the reason the slider is more narrow. Strangely though, even given less available width the image view has taken up more space when optimized for Mac. It's laid out with required width and height constraints matching its intrinsic content size.
Knowing that, you can guess why it's wider when optimized for Mac. The image has gone from being 77 percent of its natural size to 100 percent of its natural size. You can handle this different ways depending on your circumstances.
The optimal way is using asset catalogs to provide a Mac- or iPad-specific asset.
If you don't have a properly sized asset you can use Interface Builder's Trait variations to assign a different size to either idiom. This fully explains the appearance of the slider. The sliders configured to take up the available space remaining. The increased padding and wider image have decreased the space available to the slider.
In fact, the optimized for Mac Slider is shorter by the sum of the increased padding and the increase width of the image.
That's enough layout for now. Let's take a look back at appearances. The slider on the left is a system UI slider with no customizations. On the right, you see it's adopted the appearance of the newly-designed macOS slider.
Notice some subtle differences in the track height and knob shadow. The important part for you and the people who use your app is that this slider is identical to other sliders on the Mac. One thing that isn't obvious from these screenshots is the difference in text rendering. The text view is using the Body Text style. On the left. that will be a font size of 17 points, the iPad standard. On the right. 13; the Mac standard. As we know the fonts match visually in size. However, since the View optimized for Mac is using a true 13 point font the text is sharper. Remember that that additional line of wrap is because of the decreased horizontal width available and doesn't have anything to do with text rendering or sizing. If you're inclined towards concrete numbers I've annotated this slide with the land values so you can convince yourself that all of these changes make sense.
Taking all of this together you can see that you're committing to a certain amount of work refactoring even some simple layouts when you elect to optimize for the Mac. Let's tidy up this Mac layout. That app is truly at home on the Mac. So we just saw that it's less about applying rules of thumb to your layouts and more about understanding which elements will be changing and how. The payoff is this wonderful app that looks completely at home to users. Before we leave this view behind, take a look at that Get Cooking! button on the left. It's tint color is set the system teal but on the right that tint colored doesn't carry over to the Mac appearance at all. Tinted buttons aren't standard on the Mac and users aren't accustomed to them.
So that tint color gets dropped for the optimal Mac appearance.
In fact there's a larger category of control customizations that are unavailable when optimizing for Mac, either because the customization is typical to the iPad and not the Mac or because their usage isn't supported with the Mac visual appearance. Its common to attach a gesture recogniser to a UIButton to detect a long press and overload the button with multiple actions. Your gesture recognizers on UIButtons will not get called if you're using a system button that has adopted the Mac appearance. You can handle this in a number of ways. First, make sure you aren't bringing an iPad interaction over to the Mac. This might be better handled with a menu item in the apps menu bar or by attaching a menu to the UI button using the UI button menu property, like Maps does here. When optimizing your app, we recommend auditing controls customized at the event handling level. This includes gesture recognizers on controls like UIButtons and overrides of UIControlEvent tracking methods like beginTrackingTouchWithEvent. If the gesture recogniser is non-negotiable, remember that the custom button type is not rendered with the Mac appearance and will maintain the same event tracking as on the iPad and your gesture recogniser won't lose functionality. Look at this customized slider to the right here. I've really taken off with it.
It has a white minimum trackTintColor and blue maximumTrackTint color and has replaced the circular thumb with an airplane. You might experience some turbulence when you bring this to the Mac. In the Mac idiom, these customizations are unavailable. An effective mental model here is that when using system controls, you are limited to appearance customizations where standard Mac appearances overlap available UIKit API. I'll now hand it over to Jake who will take you through making some changes to a scaled Catalyst app to optimize it for the Mac.
Thanks Nick. Hi. My name is Jake and I'm an engineer on the Xcode team.
Today I'd like to show you a simple Mac Catalyst cookbook app that some of us have been working on. Let's jump right into a demo.
First let me give you a quick tour of the app before we optimize it for the Mac. On the left we have a sidebar with easy access to common areas of our app, like All Recipes and Favorites. Next we have a list of recipes and finally the recipe itself. We get a new recipes by pressing this new recipes button. Here, we can have details of our recipe along with a photo.
This app already feels pretty good on the Mac but there are some things that feel out of place, like iOS-style button and the navigation bar. Let's switch over to Xcode and get started. This is the target's general settings. Here you'll notice this new pop up button next to the Mac checkbox. By default, Scale Interface to Match iPad will be selected. new with Xcode 12 Is the Optimized Interface for Mac option. Let's choose that. What this will do is tell UIKit that we want our app to run with the Mac idiom which will give it a more Mac-like look and feel.
Let's build and run and see what's changed. I set this up so that we can view both the Scale Interface to Match iPad and the Optimized Interface for Mac versions at the same time. Immediately you'll notice that the window is larger. But not only that, the content inside the window is also larger and that's because it's no longer being scaled. The next thing I'd like to point out is this Timers button. Just by making the change to Optimize Interface for Mac, we're automatically getting a more Mac-like look for this button.
There's also something else going on here. Not only does the button look bigger because it's no longer being scaled, it's also using different metrics. What do I mean by that? What I mean is that some of the sizes have actually changed. For example the font is bigger and there's more padding between the text and the button border. Because of these types of changes the frame of the button is actually larger. It's these changes and metrics that you should keep in mind when auditing your layouts after making this change. OK, let's look a little closer at this list of recipes. We know that the recipe image is on the left and the favorite icon on the right or slightly bigger because they're no longer being scaled. But if you look closer you may notice that the size of the text did not change. And that's because we've used a dynamic type style which automatically adjusts for optimal legibility. The size of the text looks good but I think the list would look better if the recipe images and the favorite icon were a little smaller, like they were before.
Let's head back in Xcode and get this list looking better. This is the view controller that manages that list of recipes. If we look through the code here that creates the layout we can see that we're using an absolute height of 100 points. Because of the way I've set up the auto layout constraints, if this height were smaller it would cause the recipe images to be smaller too.
I was playing around with this earlier and found that 80 points looks really nice.
So I'll update this line of code to check the idiom. If it's Mac, we set the height to 80 points. Otherwise we leave it at 100. Now for the favorite icon.
For that I've specified an image here in the asset catalog. I've only filled in the universal version so it's getting used everywhere the app can run. In this case, on iPhone, iPad, and Mac. As we saw this version of the image looked too big next to the text when running on the Mac. Now that our app is running in the Mac idiom it'll have access to the Mac assets defined here in the asset catalog. This will let us specialize the image and use one that's been handcrafted to the correct size. To enable the Mac assets all we need to do is click this Mac check box here in the Devices section of the inspector. Now we can drag in the Mac versions of our icon. That's it! Let's build and run and take a look at that list again. Now you can see that our cell height is shorter which cause our recipe images to be smaller also and that our favorite icon on the right is a more appropriate size for the text because it's using that specialized Mac asset. Let's move on and take a look at the new recipe screen. OK, we got that new max style for this Choose Photo button which is really nice, but there are some things here that feel out of place on the Mac like this top navigation bar. Navigation view controllers and their navigation bars are really useful for transitioning between child view controllers so that you can show more data on small screens.
This type of interaction feels out of place on the Mac though. It's also common to put frequently used buttons in the navigation bar. On a Mac, the toolbar, up here where you see the window title, is a better choice for this type of UI. So the Save and Cancel button should be moved either up to the toolbar or down into the view and the navigation bar should go away completely.
Because the Save and Cancel buttons are acting on the data entered in this view and because both of them will end up dismissing the window, it would be more Mac-like to move them to the bottom of this view. I also see a bug now that we're running in the Mac idiom, the title label is bigger than the other two labels. Let's go back to Xcode and get these fixed up. This is the recipe editor view controller which is used in that New Recipe window.
What I'd like to do is hide the navigation bar when running on the Mac.
To fix that we'll check the idiom. If it's Mac we hide the navigation bar. Pretty simple. Next, let's take a look at the storyboard. Now that our project supports the Mac idiom you'll notice this new idiom chooser in the device bar here at the bottom. Watch the view above as I switch it to the Mac.
You'll notice the canvas is updated. The controls are now more Mac-like and are using the Mac standard spacing and metrics. First thing I'd like to fix here is the title label at runtime. It was bigger than the other two.
If we take a look at the font attribute in the inspector you can see that it's set up to use a 17 point system font. Like Nick mentioned earlier this was getting scaled down to around 13 points but now that we've chosen the Optimized Interface for Mac option it's getting rendered at its upscaled 17 points. So that's why this one is bigger but why haven't the other two changed? If we select one of the other two labels we can see that it's set up to use the Body Text style like I mentioned earlier, these text styles are dynamic and will adjust to be the appropriate size for the platform they're rendered on. We highly recommend using these text styles when you can.
Let's go ahead and update the title label to use the Body Text style as well.
Next, let's address the Save and Cancel buttons. Remember that we've already hidden the navigation bar in code. So even though it does show up here it won't at runtime. Let's add new Save and Cancel buttons to the bottom of this view and set them up to only show in the Mac idiom. First I'll resize this bottom text view to make room for a new buttons. When I do, Interface Builder alerts me to the fact that the frames in the canvas no longer match the frames computed by Auto Layout. I'll leave this for now so that we have room for our buttons. Now I'll go ahead and drag out a Stack view and pin it to the bottom right. I'll adjust the spacing use the system standard spacing.
And set it's distribution to fill equally so that the buttons are the same size.
Next I'll drag out our buttons and update their titles.
I only want these buttons to show up when the app is running in the Mac idiom, so I'll select the containing stack view and I'll use this Installed attribute here at the bottom of the attributes Inspector. For a view this attribute specifies whether or not it will be added to the View hierarchy at runtime by having Installed checked this stack view will always be added to The View hierarchy but we can add a trait variation by clicking the plus button down here in the left. This will let us vary the attribute based on these traits. New in Xcode 12, we've added the ability to vary the traits based on the Mac idiom. I'll go ahead and add a variation based on these traits. We'll leave Installed checked for this new marketing variation but uncheck it for the default case. Now these views will only be installed when running in the Mac idiom. Next, let's make sure that our text view doesn't cover up our new buttons. To do that I'll controll drag from it to the Stack view. When I hold the Option key on the keyboard, the top choice changes from Vertical Spacing to Vertical Standard Spacing. I'll choose that one. The constraint was added but some of our other constraints turned red.
This means we have unsatisfiable constraints. If we look at the red constraints at the bottom you can see that we still have that 20 point spacing between the text view and the bottom of its super view. This is conflicting with the new constraint we just added. We can't just delete this old constraint because when running on the iPad our new buttons won't be installed and we'll need some other way to specify the height of this text view. There are a couple ways we could fix this but I think what I'll do is change the constraints priority. Currently it's set to Required but let's change it to High priority instead. This way it'll be ignored when it can't be satisfied.
We're back to all orange constraints. So all we need to do is click the update frame button down here in the bottom right. Now the constraints work in both Mac and iPad idioms and we can verify that using the idiom chooser and the device bar again. Now, when I bring up the new recipe window you can see that the title label is the appropriate size. The navigation bar is hidden and we have the Save and Cancel buttons at the bottom. This feels much more Mac like.
Let's go back to slides and recap. So by choosing the Optimized Interface for Mac option you're telling UIKit that you want your app to run in the Mac idiom. As we saw this gives your application a more Mac-like look and feel but it also means layout changes because the Mac standard spacing and control metrics are being applied. This means that controls, image views, and font sizes will be different. So you really need to audit your layouts after making this change. One tip would be to check for unsatisfiable constraint warnings in the logs. This can help find issues caused by the changes to control sizes. We also looked at providing Mac assets in the asset catalog to help with some of these kinds of issues. One thing to keep in mind here is that if Mac assets can't be found the system will fall back through Mac Scaled and iPad assets before using the universal assets. As we saw in the demo, it's likely the sizes of these assets won't be optimal so make sure to audit your images and provide Mac versions where appropriate.
Lastly we looked at some paradigm differences between Mac and iPad, like the navigation bar and button placement. You should keep these kinds of differences in mind when designing your Mac Catalyst apps. I would highly recommend reading our Human Interface Guidelines for more insight into designing apps that feel truly great on the Mac. While it is possible to back-deploy Mac Catalyst app that has been optimized for the Mac there are some things you should keep in mind. When running on Catalina these apps will not get the new Mac-like look and feel. It also means supporting both the iPad and Mac idioms. We found that a majority of the work when back deploying is making sure that your layouts can handle the metrics and both idioms. You'll also need to continue guarding uses of frameworks and API that aren't supported on the Mac. Consider checking the idiom on traitCollection.
Or using conditional compilation blocks to help with these sorts of things.
Keep in mind that the conditional compilation block here will be true regardless of idiom. And in some cases it may be appropriate to use both techniques.
That's it for me. I'll hand it back over to Nick to tell you about SwiftUI. optimized for Mac. Nick? Thanks for the demo Jake. That cookbook. app fits right in on the Mac. Now you may know that SwiftUI is available to Catalyst applications scaled to match iPad. SwiftUI is also available to use in applications optimized for Mac. SwiftUI takes a similar approach to UI Kit and Catalyst optimized for Mac. But you tend to get more for free. It's declarative syntax and layout allows it to do more for your views when optimizing them for the Mac.
If you've worked with SwiftUI you've seen how it already adjusts your views on a context aware-basis, for example changing a button style if it's in a form or a menu. SwiftUI also knows if views are being used in the Mac idiom just like your controls change their appearance for where they are in an iPadOS view, so too will they represent themselves differently optimized for Mac. You can still expect to do some layout work to optimize SwiftUI interfaces for the Mac. Your SwiftUI layouts will by and large shift based off the containers you use to compose your views. As always you can build more flexible and reusable layouts, keeping your views modular and making proper use of containers. Let's take a whirlwind tour through some SwiftUI controls and how their appearances change from Scale to Match the iPad to Optimized for Mac. This year, GroupBox is new on iOS and iPadOS. GroupBox is used for layering structured content and automatically receiving the right semantic colors as backgrounds for that content. In this code sample, I've used a GroupBox in a VStack nested in another GroupBox and the views have rendered automatically with different background colors. Your SwiftUI GroupBoxes will appear as Mac GroupBoxes when optimized for Mac.
This comes with some automatic padding and layout adjustments. Here, I've set up a toggle in code that uses the variable "completed" as its bool binding.
You'll see that the default representation of a toggle in SwiftUI on iPadOS is the sliding switch. We've already seen that Mac Catalyst and UIKit make the Mac checkboxes available and so does SwiftUI. In Catalyst Optimized for Mac, the default toggle appearance is a checkbox. You can use the ToggleStyle structs and Toggle Style modifier to specify a style if the default isn't right for your case.
Similar to UIKit, system iOS Buttons will adopt the native Mac appearance. You can even place S.F. Symbols alongside them.
These are both definitely fantastic buttons. I don't know about you but one of these looks more clickable to me. DatePicker is a little different.
On the right, you see the DatePicker and both idioms of Catalyst. The Default DatePickerStyle renders identically across Catalyst. Remember that here too. There are of course other styles available to you. The DefaultDatePicker Style is compact in both idioms.
This ContentView sets up a picker to pick from the small, medium. and large sizes.
It's binding is set up through a property size index. You could also bind a string values or an enum. When you ptimize for Mac, the Mac Picker becomes available to you. This is a control users are very familiar with on the Mac and offers a much more Mac-like experience than the scrolling picker.
Remember the segmented control style is an option on both platforms to.
One last control to mention: you know that the system buttons are available to you. However you also aren't sacrificing any customizability on your SwiftUI buttons. If you aren't using the system button appearance then you're using some custom body. Hopefully, you're using SwiftUI's button style API as I've done here to make your buttons styles flexible and reusable.
SwiftUI and Catalyst know not to render custom buttons with a Mac appearance so your custom buttons come across exactly as they are. I've taken some time to write a fully custom throwback 90s button style. You can see I've applied it as a View modifier to the button in my content views body. Thanks to Catalyst, I can have this on iOS and Mac without needing to write any additional code. So I, like some of you maybe, have been experimenting with SwiftUI and you may know that Swift UI can run seamlessly in UIKit apps.
It's really easy to build up a content view in the SwiftUI previews canvas and then drop that right into my UIKit code with a UI hosting controller.
I thought that this text-only view from the cookbook app Jake was showing earlier could use a makeover. So I made this interactive recipe view completely with SwiftUI. It lets the user check off their progress as they work through the recipe. You can select which units of measurement to use with a picker at the top. Each instruction is contained in a group box. And can be marked complete with a toggle. I've used the custom blue time review and custom SwiftUI button to control that timer. Now let's see how this new iPad feature work carries over to our Catalyst app optimized for Mac. Here's the app with the plain text directions view. And here it is with my iPad SwiftUI view dropped right in. No code changes at all! I am really happy with these changes. The picker has adopted the default Mac appearance. The iOS style group boxes are now using the Mac style. Notice how using the group box also achieved a more Mac-like layout that I otherwise would have had to do myself. The Mac group box uses Mac metrics so it's a little bit more snug around the views and the label of the group box has moved outside the box which also affects what completed instructions look like. The sliding switches are all now checkboxes. And the labels of those checkboxes are to the trailing edge of the box. Those labels are also clickable to toggle the checkbox. And this is different from a sliding switches label behavior.
And my custom views are untouched and scaled correctly. I'm very excited with how easily I was able to bring SwiftUI right into this app and make following our recipes easier and more interactive on the Mac and the iPad.
Let's review all that we've learned today. You saw what to expect to change when you optimize your Catalyst interfaces. We went over traits that might make an app a good candidate for optimizing for the Mac. Jake showed you how to optimize your app in Xcode using Interface Builder's trait variations and idiom checks and code. Finally we saw how SwiftUI optimizes for Mac and how easy it can be to integrate new SwiftUI views into your UIKit app.
Thanks for watching. Enjoy WWDC 2020!
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.