IPadian is more of a simulator than an emulator. That is, it does not create a local version.
Streaming is available in most browsers,
and in the WWDC app.
Itunes
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.