APIs dropped from MacCatalyst SDK without prior deprecation - is this to be expected?

UI Frameworks UIKit
pmdj OP
Created Aug ’24
Replies 5
Boosts 0
Views 780
Participants 3

We maintain a device driver for macOS. This consists of a bunch of components including a Launch Agent, a (Cocoa/AppKit) status bar item app, and a "main" windowed UI app. These all communicate with each other via XPC using the "low level" XPC APIs (libxpc). The launch agent registers a named Mach XPC service, and the two apps connect to it when they launch.

Last year, we had an overhaul of the main UI app as we wanted to add a bunch of features. In the process we decided to switch it from Cocoa/AppKit to Mac Catalyst/UIKit as we were also contemplating porting the driver to iPadOS in future; plus, UIKit is a little simpler and I'm not a great UI programmer, so any simplification is welcome.

This has worked OK so far, but in our attempt to upgrade our build toolchain from Xcode 15.2 to Xcode 15.4 we found that the Catalyst app would no longer build. Apparently the xpc_connection_create_mach_service() and xpc_connection_set_peer_code_signing_requirement() functions are no longer available as of the Mac Catalyst SDK included with Xcode 15.3. This makes it impossible for the app to connect to the launch agent's XPC service.

A few things to note:

  1. These functions were never deprecated, so we did not have their impending removal on our radar.
  2. It seems they actually used to be available in the iOS SDK and were removed from that, so Mac Catalyst is effectively collateral damage. I don't think these would ever have been usable in apps on the iOS App Store, so perhaps they were removed from the iOS SDK ahead of support for notarised iOS app distribution.
  3. So it looks like they might have been removed from Mac Catalyst SDK by accident? I therefore filed a bug about this - FB13929309 - about 6 weeks ago. Reinstating the functions for Mac Catalyst would seem like a very straightforward fix, but I've not had a hint of feedback on the report.

I guess my forum question comes down to this: Is Mac Catalyst considered a platform for building macOS apps in its own right? Or are we "holding it wrong" and should we only treat it as a way of tweaking Mac ports of iOS/iPad-first apps? Should we expect APIs to disappear from the Mac Catalyst SDK with zero notice?

We can still build with Xcode 15.2 for the moment, and the app built this way runs fine up to and including the macOS 15 beta. But thanks to the limited forward and backward compatibility schedule for Xcode we can't stay on old Xcode for long We're also planning to make some feature changes to the app in the near future, and I don't want to be investing in an app built on a platform with no future. I'd rather port the app back to Cocoa/AppKit before adding features if that's the case.

Answered by DTS Engineer in 798197022

There are two parts to this:

  • Why did these XPC APIs go away?

  • What’s the deal with Mac Catalyst overall?

I’ll tackle each in turn.

Regarding these XPC APIs, you are right that APIs shouldn’t just disappear without warning. If you see that, you should file a bug about it. And you’ve already done that (FB13929309), so thanks!

I had a look at your bug and it’s clear that this was a mistake. I can’t offer definitive predictions about The Future™ but, as always, I recommend that you re-test with new betas of Xcode as we start seeding them.

Regarding Mac Catalyst as a whole, Apple rarely makes forward-looking statements about our platforms, but this is a rare exception to that rule. Watch WWDC 2022 Session 102 Platforms State of the Union, and specifically Josh’s section starting at 3:43.

Speaking for myself, I think I’m coming from the same place you are: I’m not a UI programmer at heart. That’s why I’m a big fan of SwiftUI. With SwiftUI I can cons up a basic interface and have it run natively on both iOS and macOS, without having to worry about the limitations of Mac Catalyst.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Replies  5
Boosts  0
Views  780
Participants  3
DTS Engineer OP
Apple
Aug ’24
Accepted Answer
Recommended

There are two parts to this:

  • Why did these XPC APIs go away?

  • What’s the deal with Mac Catalyst overall?

I’ll tackle each in turn.

Regarding these XPC APIs, you are right that APIs shouldn’t just disappear without warning. If you see that, you should file a bug about it. And you’ve already done that (FB13929309), so thanks!

I had a look at your bug and it’s clear that this was a mistake. I can’t offer definitive predictions about The Future™ but, as always, I recommend that you re-test with new betas of Xcode as we start seeding them.

Regarding Mac Catalyst as a whole, Apple rarely makes forward-looking statements about our platforms, but this is a rare exception to that rule. Watch WWDC 2022 Session 102 Platforms State of the Union, and specifically Josh’s section starting at 3:43.

Speaking for myself, I think I’m coming from the same place you are: I’m not a UI programmer at heart. That’s why I’m a big fan of SwiftUI. With SwiftUI I can cons up a basic interface and have it run natively on both iOS and macOS, without having to worry about the limitations of Mac Catalyst.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1
Macho Man Randy Savage OP
Aug ’24

That must've been a nasty surprise.

I don't know about you but I got way too much code and time invested to just throw it all in the trash and start using SwiftUI anytime soon.

As a workaround you should be able to embed an "AppKit aware" bundle in your Catalyst app? This bundle can call all the public methods an AppKit app can. Load the bundle from the Catalyst app and call whatever public API you want...

Something like this...

NSURL *appKitAwareBundleURL = [[NSBundle.mainBundle.builtInPlugInsURL URLByAppendingPathComponent:@"NameOfBundle"] URLByAppendingPathExtension:@"bundle"];
NSBundle *appKitBundle = [NSBundle bundleWithURL:appKitAwareBundleURL];

 NSError *errorLoadingBundle = nil;
            
  if (![appKitBundle loadAndReturnError:&errorLoadingBundle])
  {
         // whoops check error..
        return; 
  }

 Class appKitWorldClass = appKitBundle.principalClass;
  id <YourProtocolNameHereWrappingAPIsYouNeed>myAppKitWorld = [[appKitWorldClass alloc]init];
self.appKitWrapper = myAppKitWorld;

Your principalClass conforms to your protocol you define that wraps whatever API calls you need.

1
DTS Engineer OP
Apple
Aug ’24
As a workaround you should be able to embed an "AppKit aware" bundle in your Catalyst app?

That depends on your definition of the word “should” (-:

While this works a lot of the time, it’s most definitely not supported.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
Macho Man Randy Savage OP
Aug ’24

I hear you but sometimes developers gotta do what they gotta do for their users and themselves. So I was just offering a workaround that should help the developer release an update without having to drastically change the codebase.

I don't know about the OP but depending on the complexity of the app it may not be feasible to just throw the whole thing out because of a bug like this and "just wait, maybe we'll fix it" and then play a commercial for SwiftUI.

Always appreciate your answers though. They have often been very helpful!

1
pmdj OP
Aug ’24

An update on this: the APIs in question have been reinstated as of Xcode 16 beta 5. 🎉

1
APIs dropped from MacCatalyst SDK without prior deprecation - is this to be expected?
First post date Last post date
 
 
Q