Native Mac apps built with Mac Catalyst can share code with your iPad apps, and you can add more features just for Mac. In macOS Big Sur, you can create even more powerful versions of your apps and take advantage of every pixel on the screen by running them at native Mac resolution. Apps built with Mac Catalyst can now be fully controlled using just the keyboard, access more iOS frameworks, and take advantage of the all-new look of macOS Big Sur. There’s never been a better time to turn your iPad app into a powerful Mac app.
Designed for macOS Big Sur.
How to run Mac OS 8 in an app inside Catalina. By William Gallagher. The Mac OS 8 macintosh.js app itself is by Rieseberg. 2020 iPad versus 2019 iPad and 2018 iPad.
MacOS 10.15 Catalina is ruthless about launching unknown apps. Unless your app comes direct from the App Store, or the app’s developer got the app notarized by Apple, it won’t launch. In an effort to keep macOS running smoothly, Catalina will run on a dedicated system volume all its own and separate from other apps and data in a read-only space so that system files remain. MacOS Catalina's iPad apps for the Mac are here, but the story is just getting started Catalyst has been slow to take off on MacOS 10.15, but here's a look at the state of tablet apps migrating to. ITunes replacement. For years, iTunes served as Apple's digital hub, helping you buy, manage, play. What’s the deal with 32-bit and 64-bit apps and macOS Catalina? One of the major changes in macOS Catalina is that software must be 64-bit in order to run. 32-bit apps will not run on Catalina.
When an app built with Mac Catalyst runs on macOS Big Sur, it automatically adopts the new design. The new Maps and Messages apps were built with the latest version of Mac Catalyst.
Get a head start on your native Mac app.
Your iPad app can be made into an excellent Mac app. Now’s the perfect time to bring your app to life on Mac. The latest version of Xcode 12 is all you need. Begin by selecting the “Mac” checkbox in the project settings of your existing iPad app to create a native Mac app that you can enhance further. Your Mac and iPad apps share the same project and source code, making it easy to make changes in one place.
Optimize your interface for Mac.
Your newly created Mac app runs natively, utilizing the same frameworks, resources, and runtime environment as apps built just for Mac. Fundamental Mac desktop and windowing features are added, and touch controls are adapted to the keyboard and mouse. By default, your app will scale to match the iPad’s resolution. On macOS Big Sur, you can choose “Optimize interface for Mac” to use the Mac idiom, running your app using the native resolution on Mac. This gives you full control of every pixel on the screen and allows your app to adopt more controls specific to Mac, such as pull-down menus and checkboxes.
Even more powerful.
The new APIs and behaviors in macOS Big Sur let you create even more powerful Mac apps. Apps can now be fully controlled using just the keyboard. You can create out-of-window and detachable popovers, control window tabbing using new window APIs, and make it easier for users to select photos in your app by using the updated Photos picker. iOS Photos editing extensions can now be built to run on Mac. And your app is even easier to manage when it’s running in the background with improved app lifecycle APIs.
New and updated frameworks.
Mac Catalyst adds support for new and updated frameworks to extend what your apps can do on Mac. HomeKit support means home automation apps can run alongside the Home app on Mac. The addition of the ClassKit framework lets Mac apps track assignments and share progress with teachers and students. Plus, there are updates to many existing frameworks, including Accounts, Contacts, Core Audio, GameKit, MediaPlayer, PassKit, and StoreKit.
Tools and resources.
Macos Catalina Run Ipad Apps Download
Download Xcode 12 beta and use these resources to build native Mac apps with Mac Catalyst.
Macos Catalina Run Ipad Apps On Macbook
Streaming is available in most browsers,
and in the WWDC app.
Macos Catalina Problems
Apple Silicon Macs can run many iPad and iPhone apps as-is, and these apps will be made available to users on the Mac through the Mac App Store. Discover how iPad and iPhone apps run on Apple Silicon Macs, and the factors that make your apps come across better. Learn how to test your app for the Mac, and hear about your options for distribution of your apps.
Resources
Related Videos
WWDC 2020
WWDC 2019
- Download
Hello and welcome to WWDC.
Welcome to 'iPad and iPhone Apps on Apple Silicon Macs.' My name is Jason Beaver, and I'll be joined later by my colleagues James Snee and Patrick Heynen.
As you may have seen in the Keynote or State of the Union talks, Big Sur on Apple Silicon allows you to run iOS apps natively on the Mac without recompilation.
The Mac is a robust platform for development that enables all kinds of apps. There's everything from powerful desktop apps to web-based experiences and graphic-intensive games. These experiences are all powered by our dedicated UI frameworks.
In macOS Catalina, we added the ability to build your iOS apps for the Mac with Mac Catalyst. Mac Catalyst makes UIKit a native peer to these other UI frameworks on the Mac and enables you to bring your iOS apps over to the Mac as first-class experiences.
You can refer to last year's 'Introducing iPad Apps for Mac' session to hear all about how we did this.
Mac Catalyst requires building your app with the macOS SDK and gives you the ability to customize and optimize your application to take full advantage of the Mac.
In macOS Big Sur, we are leveraging this Mac Catalyst infrastructure to enable running your existing iOS apps as-is on Apple Silicon-based Macs.
Here, 'as-is' really means 'as-is.' We enable the user on the Mac to purchase or download, through the Mac App Store, the application you've already made available on the iOS App Store. It is the exact same binary.
Because these apps use the same underlying infrastructure that is used for Mac Catalyst apps, the same unified frameworks and the same iOS frameworks brought over and integrated with the Mac, your iPad and iPhone apps get a tremendous amount of behavior automatically, making them feel right at home on the Mac.
However, they don't have access to all that a Mac app would like to offer. If you want to take your iOS applications further on the Mac, create a Mac Catalyst version by checking that switch in Xcode. This will give you the ability to customize your app's behavior on the Mac, as well as allow you to distribute your application on all Macs, not just those running Apple Silicon.
For your app to be available in the Mac App Store, it must be compatible with the Mac.
Your app can't be dependent on an unavailable symbol or framework, it can't be dependent on missing functionality in existing frameworks, and it can't be dependent on hardware capabilities that don't exist on the Mac.
Compatible iOS apps are automatically available in the Mac App Store, but you can manage the availability of your app in App Store Connect. You might choose not to make your iOS app available in the Mac App Store if you already have a Mac app or are planning on shipping one or if your app doesn't make sense on the Mac.
Patrick will discuss this further later in the session.
Most existing iPad and iPhone apps run great on macOS, but the environment has some differences that you should be aware of.
These fall into three categories: hardware differences, UI differences and system software differences. Let's start with hardware differences.
iOS is built around a direct, multi-touch interaction model, but macOS is built around an indirect, cursor-based interaction model.
The infrastructure automatically maps many multi-touch gestures, but if your application uses custom touch handling, you should test whether your application is compatible with the Mac. If your application supports keyboard entry as an alternative to your custom touch handling, that will also help your app be more compatible with the Mac, as well as a better experience on iOS.
iOS devices have a range of sensors that aren't available on Macs, such as accelerometers, gyroscopes, magnetometers, depth-sensing cameras and GPS.
By dynamically confirming in your code that the appropriate sensor is present, you can ensure that your app is compatible with the entire range of iOS devices, as well as compatible with the Mac.
Note that not all APIs that are dependent on these sensors fail to work on the Mac.
For example, even though Macs do not contain GPS receivers, they do support Core Location and can provide position information to your app, though it will be less precise than it would be with GPS.
iOS devices typically just have front- and rear-facing cameras. Macs, on the other hand, may have built-in front-facing cameras, like in our laptops and some desktops, but may also include cameras built into external displays or cameras plugged in via USB.
iOS apps may not be prepared to deal with all of these configurations, but using the AVCaptureDeviceDiscoverySession instead of enumerating all of the AV capture devices will allow us to ensure that your app has access to the most appropriate camera for your needs.
Now, let's talk about some UI differences.
As we discussed before, iOS apps automatically get a great deal of system behavior from macOS.
This will necessarily look and behave differently than on iOS devices. For example, alerts and pop-ups may show up in different locations on the Mac and Open and Save panels will show in separate windows.
This means that it's important that your app does not hard-code any assumptions about the UI, like the location of system UI, since those assumptions might be wrong when running on the Mac.
On macOS, windows are typically resizable by the user. If your iPad app already supports multitasking on iOS, it will be fully resizable on macOS.
This means that it can run at a wide range of sizes, not just the small number of fixed sizes supported by iOS multitasking.
Using Auto Layout will help you ensure that your app can run correctly at any size.
Window resize is also live on macOS. Optimizing the performance of your application layout will improve the resize experience on the Mac and make your app even more responsive when multitasking on iOS.
If your iPad app does not support multitasking, or if you have an iPhone app, it will run in a fixed-size window and will not be resizable.
Now let's look at some of the system software differences. On iOS, apps live in a standard location, but on macOS, the user can move the app wherever they would like.
Your app's data containers are also in a different location on the Mac.
If you're using the Foundation APIs to locate items in the file system, all of this will be transparent to you, and your app will behave correctly when running on the Mac.
Some system APIs will reveal that your application is running on a Mac.
For example, if you've hard-coded parts of your system, whether on the device or on your servers, to expect only the devices iPhone, iPod Touch or iPad, you will likely encounter problems when running your iOS application on the Mac.
It is better to ensure your software robustly handles unexpected values and falls back to some default behavior.
Other device properties, such as screen size, can vary dramatically across Macs, and your application should not make the assumption that it will match one of the screen resolutions in our iOS devices. Now I'd like to hand it over to my colleague James, who will talk about testing and debugging your iOS apps on the Mac.
Thanks, Jason. Being able to run iPhone and iPad apps natively on the Apple Silicon Mac allows you to reach a whole new set of users.
And with macOS Big Sur, Apple has done all the hard work to make that possible with minimal to zero effort on your part.
So I'm sure you want to see how your app looks running on the Apple Silicon Mac. As Jason mentioned, your apps may be making some assumptions about the devices they're running on that are no longer true on the Mac.
The goal here is to ensure that your apps function correctly and that there aren't any major UI glitches or unexpected behavior.
The good news is that Xcode has great support for debugging, testing and profiling iPhone and iPad apps natively on the Mac, just as if it were running in a simulator or on an iOS device. Let me show you how that works.
Here I've got an iOS app project open in Xcode.
Some of you may recognize it from a previous session.
In order to run an iOS app on the Apple Silicon Mac, all you need to do is select the new run destination, My Mac, Designed for iPad.
So let's go ahead and build and run this app.
I want to call out that this app is building against the iOS SDK, so barring the edge cases Jason mentioned, you don't have to make any source changes in order for this to run.
So, here we have this iOS app running natively on the Apple Silicon Mac. It's built against the iOS SDK and isn't running in a simulator.
As I click around the various views, I can verify that it behaves the same as it does on an iPhone.
As well as running iPhone and iPad apps, we've also brought all of Xcode's great debugging and profiling capabilities along for the ride.
While an app is running, you can get a high-level view of its performance by checking out Xcode's debug gauges.
You can see how much CPU time and memory it's consuming, as well as any network and disk I/O it might be performing.
If you want to take a more targeted look at what your app is doing, you can pause it or set a break point and use one of Xcode's great debugging features, just like you would on an iPhone or iPad. For example, a common use of the debugger is to investigate the state of an app in response to a user action.
Let me show you how this works with this iOS app running natively on the Mac.
I'm going to set a break point here in this IBAction method.
And I'm going to trigger it by clicking on this useful button in the app.
You'll see, in response to triggering this break point, Xcode presents its debugging interface.
Once in the debugger, you can make use of all the features you'd expect, such as inspecting variables and evaluating expressions.
To investigate more specific issues, you can check out the Memory and View debuggers. And for understanding or tracking the performance of your app, you can use Instruments.
And finally, I'm sure you're wondering about testing. Tests are a great way to verify that your software is behaving as you expect. Let me show you.
With Xcode, you can run your iOS app XCTest unit tests natively on your Apple Silicon Mac.
I'm going to execute these tests by clicking Run here in the Test Navigator.
Like running the app, these tests are being built against the iOS SDK and are running natively.
Great. The tests pass.
Xcode provides a great set of tools to help you debug, test and profile iPhone and iPad apps natively on the Apple Silicon Mac.
And with that, I'll hand it over to Patrick to talk about distributing iPhone and iPad apps for the Mac.
So, now that we understand how iPad and iPhone apps work, let's talk about how these apps get on the Macs your users and team members will be running.
The good news is that distribution for your iOS app on the Mac works exactly like it does on iPad or iPhone today.
All of the workflows you are familiar with today have been seamlessly extended by adding the Mac to the family of devices supported by your app.
All you really have to do to make your apps available on the Mac is sign the new Developer Agreement, and your compatible apps will be made available on the Mac App Store later this year.
For new submissions, distribution for the Mac will fit seamlessly into your existing development workflows.
From the Xcode organizer, you can prepare your app for running on the Mac by exporting through App Store Connect or use any of the local distribution options, such as ad hoc, enterprise or development to distribute versions of your iPad or iPhone app directly to members of your team.
If your app takes advantage of App Store features, they will all be supported when running your iPad or iPhone app on a Mac.
Users will have full access to any in-app purchases and subscriptions associated with your iPad or iPhone app when running on Mac and can make new purchases using the StoreKit framework.
If your app uses on-demand resources to dynamically manage the content downloaded for your app, the experience will be identical when running on a Mac.
In fact, all App Store features work just like they do on iPad and iPhone.
App thinning has also been extended to work with deploying to Apple Silicon Macs. App content is automatically selected for best fit for running on a Mac, and inapplicable resources best suited for other iPad or iPhone devices are left out for a streamlined install experience.
In fact, for app thinning, a new Mac looks just like any other very capable iPad.
To support this workflow, Xcode has added a new virtual thinning destination for Mac in the Organizer export workflow.
Use the Mac device to produce an install variant optimized for running or testing on any Apple Silicon Mac.
Note that because Mac users are accustomed to moving apps seamlessly between machines and removable storage, only a single app variant and thinning target is needed.
If your app relies on developer or ad hoc distribution, that will work just like it does on iPhone and iPad.
The good news is that you can get your iPhone or iPad app onto Macs by exporting just like you would for other iOS devices.
If you take advantage of Over-the-Air installation, distributing to the Mac requires no changes. The Mac will automatically select an appropriate variant from your OTA manifest to download and run on your suitably provisioned Macs.
For scenarios involving managed devices, iPad and iPhone apps can be pushed to enrolled Macs just like any other device.
Although distribution to the Mac is incredibly straightforward, the Mac is a distinct platform, and there are some key points to consider when deploying to Mac.
TestFlight is not available for Mac, so any prerelease distributions ahead of your final submission will need to use ad hoc or development distribution as an alternative to test your app. In addition, as Jason noted earlier, there are limits to iPad and iPhone app run-time compatibility on Mac.
Xcode will tell you if your app has hard dependencies on symbols or frameworks unavailable on Mac, but it is always a good idea to test your app on Apple Silicon Mac hardware when available in order to evaluate the user experience of your app on a Mac.
We have made it incredibly easy to get your apps onto the Mac App Store.
To ensure that your customers will have the best experience with your iOS apps on the Mac, App Store Connect will be providing tools to help you test and validate that experience later this summer.
Of course, you will still have the choice of whether your apps are available on the Mac App Store.
Let's look at how you'll control that now.
After you sign the Developer Agreement, all your compatible apps will automatically be made available on Mac.
Use App Store Connect to review the status of all of your apps.
In App Store Connect, the Pricing and Availability page is where you make your choice about whether to distribute your app on the Mac App Store.
If you don't want this app available on the Mac, simply uncheck this box, and it will no longer be offered for sale on the Mac App Store.
Note that once your app is made unavailable, Mac users will no longer be able to re-download existing versions of your app until the app is made available on Mac again.
So, now you know. Your apps can now run natively on Apple Silicon Macs without change. Users will love the ability to run your apps on their desktops.
Most functionality just works, and the apps run adapted to the familiar Mac user experience.
Building and debugging is just the tools that you already know and use.
So all you need to do is test your apps on Apple Silicon Macs to confirm your apps come across well.
Then you'll have a whole new set of users enjoying your apps from the Mac App Store soon.
Thank you for watching.