I have an iOS app developed in Xojo (2023 Release 1.1) that works great in the Xcode simulators and runs fine on my iPad Pro. What do I need to do to allow it to run natively on Mac OS with Apple Silicon? I changed the LSRequiresIPhoneOS key in the info.plist to false but that did not convince Mac OS to open the app (‘You can’t open the application “xyz.app” because this application is not supported on this Mac.’). The only entitlement that the app uses is User Authentication.
Only way I have found so far is to upload your app to Appstore connect with Transporter.app (available on the app store).
Then download the app using Testflight.
Thanks for the reply, Jeremie. I was thinking there are settings in the info.plist or equivalent that indicate to Mac OS that the iOS app is compatible.
There’s a checkbox when you create the app on Apple’s Developer site. Can’t remember exactly where.
As I recall, the app needs to support iPadOS and multitasking. Just being an iOS app is not enough. It is the multitasking support which denotes the app is capable of dynamically switching window sizes etc.
I don’t think you necessarily need to upload via Transporter.app or use TestFlight. I have done it in the past using Enterprise licenses and private distribution via company websites. So there was never any checkbox option on Apple’s side or upload to Appstore connect involved.
Douglas, my app already behaves properly with Stage Manager when the windows are resized on the iPad, is that what you are referring to?
My history with making iPadOS apps which run on Apple SoC predates Stage Manager. And used another development platform. I’ll see if I can find what I read once on the app requirements to run natively on Apple SoC. My recollection is that it had something to do with multitasking support (but this was before Stage Manager).
I did find this Apple document which may be of some help. It has a section " Make your windows resizable using iPad multitasking which also includes this line:
- Don’t include the
UIRequiresFullScreenkey in your app’sInfo.plistfile.
But look over that whole page for more information.
Maybe this page can give you some hints: Running your iOS apps in macOS | Apple Developer Documentation
That page is helpful, Thomas, but this is the part that has me stuck.
Modernize the iOS apps you choose to run on a Mac with Apple silicon, or opt out of running on a Mac altogether.
iOS Apps on Mac runs your unmodified iPhone and iPad apps on Apple silicon with no porting process. Your apps use the same frameworks and infrastructure that Mac Catalyst apps use to run, but without the need to recompile for the Mac platform.
It makes it sound like you don’t have to do anything special at all, yet Mac OS won’t open the app. 
I searched the info.plist file and did not find UIRequiresFullScreen anywhere. It does have LSRequiresIPhoneOS, but even removing that tag does not change the result.
The page says:
But a Xojo app isn’t a Mac Catalyst app, right?
Good point, Arnaud, and perhaps that’s the issue.
The most important part, in my opinion is this:
[Choose whether to include your iOS app in the Mac App Store]
After you sign the updated developer agreement, the App Store automatically makes compatible iOS apps available to users of a Mac with Apple silicon.
For your iOS App to be available on Mac, it must be distributed through the App Store.
That is the preferred way for Apple.
There are certainly other ways, such as using Enterprise licenses or private distribution.
Thanks for that, Jeremie. This is an app for in-house use only, it will not be on the app store. I was hoping it would run on both platforms but it really is for use on the iPads.
Michael,
Apple seems to be really trying to minimize use (or at least abuse) of Enterprise licenses, and they are harder to get approved now. Including refusing to renew existing Enterprise licenses that have existed for years for corporations with under 100 employees.
However, they do now offer “unpublished links” in the App Store. These are apps which still go through all the normal review channels etc but are NOT listed in the App Store search results. They are intended for things like limited distribution scenarios, where Enterprise licenses may have been ideal in the past. You still get a link to the App Store install like normal public search results, but without the direct link would otherwise not know it exists. You still have to apply for an unpublished link, but the approval process is MUCH easier than getting an Enterprise license.
Or you can just do Test Flight, which lets you install on up to 1,000 devices (or is it 10K?) per platform. That has an even more minimal initial review process, and does not need all the App Store requirements like screenshots etc.
Thanks, Douglas, I’ll look into the “unpublished links” approach.
Very helpful! In the past my usual tactic for in-house stuff (it’s a small house) is just to put the development version of the app on each device. The problem with that is the provisioning profile expires and I have to make a new one each year.
Plus if you are using ad-hoc profiles, you need to add each device’s UUID into the provisioning profile BEFORE you create the profile. Test Flight reduces that hassle, but apps expire even quicker. Enterprise profiles also expire yearly.
So “unpublished links” are a welcome addition to the toolbox, but does mean you have have the app store review delay before you can roll out an emergency fix for in-house stuff. Thankfully, that tends to be much shorter than in the early years of App Store reviews.