• Blog
  • iOS Apps on Apple Silicon Macs

iOS Apps on Apple Silicon Macs

We take a look at the development considerations for having iOS apps on Silicon Macs with MacOS Big Sur.

  • Views
  • 30 Sep 2020
  • Alan Chung
The spacious design of macOS Big Sur displayed on the Mac and MacBook Pro.

In 2019 as part of macOS Catalina, Apple introduced Mac Catalyst which enabled iPad apps to be brought to the Mac using iOS frameworks. This gave developers the opportunity to open up their applications to a whole new audience, whilst making the Apple ecosystem a more cohesive experience for existing app users. Coming this year, Apple is taking this one step further by introducing iOS apps on Apple Silicon Macs, bringing new and existing iPhone and iPad apps to Apple Silicon Macs running macOS 11 (Big Sur).

Development considerations

All that’s needed is for the account owner to accept the updated licence agreement, and all existing compatible iOS apps on the App Store will be made available on the Mac App Store from day one, available on Apple Silicon Macs. What does Apple mean by ‘compatible’? The summary they gave in the WWDC talk was that an app is considered compatible if it doesn’t rely on frameworks or functionality and hardware unavailable on the Mac.


Perhaps the most obvious difference between iOS and Mac is that it’s running on different hardware. Some hardware dependencies in iOS will map nicely on to the Mac - the biggest one being touch events, which will map to the mouse cursor on Mac (as long as the app doesn’t make use of custom touch handlers). It’s a similar story for CoreLocation - it will seamlessly be available on the Mac, but it won’t make use of GPS, so results will be slightly less accurate.

Generally, Apple recommends using the appropriate high-level APIs so that the system can determine the best approach automatically. For instance, in the case of cameras, iOS devices only have front and back cameras, whereas a Mac might have multiple external cameras in addition to a built-in camera. Because of this, it is recommended to use the AVFoundation framework so that the most appropriate webcam can be used for camera functionality on Mac.

For iOS specific sensors like the gyro and accelerometer, there is no direct mapping to the Mac as there’s no substitute for these. In this situation, the recommendation is to dynamically check for support for these, and fall back to some default behaviour when the required sensor isn’t available. Doing this will not only improve compatibility for Mac, but it will improve the experience for the full range of iOS devices too.

User Interface

MacOS Big Sur brings a refresh to the visual style of the Mac, to be more in line with iOS. Despite this, there are still significant differences in system views like popups and open/save dialogs, so it’s best not to make any assumptions or hard code anything related to the position of system UI in your app (which hopefully should be the case anyway)! System dialogs on the Mac will take on the new visual style to be more at home on the Mac.

Another thing to consider is that iOS apps will be contained in a window on the Mac. Any iOS app which supports iPad multitasking will become fully resizable on the Mac. Using auto-layout will ensure the app looks good at any size - plus, resizing happens on-the-fly on Mac (as opposed to snapping to a limited number of fixed sizes with iPad multitasking), so autolayout will ensure the transitions happen smoothly and responsively. If the app is iPhone only, or doesn’t support multitasking, it will be in a fixed-size window on Mac.

System software

We’ve been over some of the hardware and UI considerations when transitioning iOS apps to the Mac, but we also need to think about the behaviour and functionality of the software itself.

One specific area Apple highlights in this regard is access to the file system. Because Mac users are free to move apps anywhere on their file system - in contrast to the fixed location on iOS - we need to be careful about how the file system is accessed. Using the Foundation framework, all of this becomes transparent, and the system will automatically determine the best location to store files. Any hard coded file paths will potentially cause problems when the app is brought over to the Mac. In most cases, hard coded file locations should be avoided regardless!

On the topic of hard coding, another thing that Apple advises to look out for is anywhere in your app (or supporting web API) that expects the device type to be strictly iPhone, iPad or iPod Touch. The Mac, of course, can’t be categorised as any of these, which might cause issues wherever these values are hard coded. The same can be said for targeting specific screen resolutions. Because of this, apps should gracefully handle unexpected values for device-specific traits, and fall back to some suitable behaviour.

Summary for developers

The basic message for developers here is that following best practices and utilising native APIs wherever possible will give your app the best chance of being compatible on Mac. Avoiding assumptions and hard coding will not only improve the experience of your app on Mac, but it will also do the same on the entire range of iOS devices, as well as making the codebase easier to work with in general. It’s a win-win!

Eden Agency logo Eden Agency logo icon Eden Agency logo icon red Eden Agency logo red Eden accessibility icon Eden ai machine icon Eden apps icon Eden architecture icon Eden dev ops icon Eden iot icon Eden ux icon Eden v ar mr icon Eden websites icon Dribbble icon white Facebook icon white Instagram icon white Linkedin icon white Twitter icon white Dribbble icon Facebook icon Instagram icon Linkedin icon Twitter icon Avansce logo Fortem logo Jet2 logo Li fung logo Link logo YBS logo Veo logo Yara logo UK Greetings logo Minster law logo