Catalyst
iPad Apps for Mac Human Interface Guidelines:
When you bring your iPad app to Mac, you give people the opportunity to enjoy your app in the context of the Mac’s large display, outstanding native performance, and ample local storage.
[…]
To ensure that your app gives people a rich Mac experience, it’s essential to enhance this foundation and go beyond simply displaying your iOS UI in a macOS window.
Creating a Mac Version of Your iPad App:
Starting with Xcode 11, you can create a Mac version of your iPad app using UIKit. Configuring your app to run in macOS takes just a click in a checkbox. However, more steps may be needed depending on the system features and frameworks your app uses.
Optimizing Your iPad App for Mac:
The Mac version of your iPad app supports many system features found in macOS without requiring any effort from you. […] You can, however, extend your app to take advantage of even more system features.
One notable thing Apple told me: it won’t try to force all Catalyst sales through the Mac App Store. If you convert your iOS app to the Mac, you can sell it however you want without paying Apple a 30% commission.
It’s not clear yet whether they can be unsandboxed. The documentation simply says that Xcode auto-adds the com.apple.security.app-sandbox entitlement.
Project Catalyst may not have received as much stage time as expected during the WWDC keynote, but it is a huge development for the future of the Mac and iPad alike.
Twitter is thrilled to announce we are bringing the Twitter for iPad experience to the Mac!
[…]
Apple’s exciting new technology empowers Twitter to easily bring our entire 1.5 million line code base from iOS to the Mac, allowing ongoing full feature parity with our iPad app, and enhanced with the macOS experience that will make Twitter feel right at home on your Mac.
This Twitter for Mac will be fully native, with all the native features of a Mac app. Multiple windows, window resizing, drag and drop, dark mode, keyboard shortcuts, notifications and more!
Thanks to Apple’s technology, the new Twitter for Mac will get regular updates, just like Twitter for iPad and iPhone. It’s the best of both worlds: the full Twitter experience enhanced to run natively on a Mac!
SwiftUI ist the new Cocoa. It’s to UIKit and AppKit what Cocoa was to Carbon.
Marzipan is transitional technology. Once iOS apps are built with SwiftUI, Marzipan will become obsolete.
So all the AppKit developers who were concerned that Marzipan would herald the beginning of the end of AppKit (myself included) can relax.
It won’t be Marzipan (officially Catalyst). It’ll be SwiftUI.
So Catalyst turned out to be “Carbon” I guess.
Honestly, I know everyone will hear what they want to hear, but so far it absolutely does not look like UIKit is taking over Mac (or going to soon). They said it’s “good for some kinds of apps”, AppKit is still getting improvements and is fully integrated with SwiftUI.
Say hi to NSSwitch.
It supports the full
NSControlAPI including bindings and formatters. It’s keyboard-accessible (spacebar and arrows), has AX options like state indicators, the works.
Last bit on the Mac switch control: by default the SwiftUI
Togglecontrol is a checkbox on Mac, but you can request a switch using.toggleStyle(.switch).Don’t go replacing all your checkboxes with it. It’s really for “big switches”, not lists of preferences.
I expect many apps will use them that way, anyway.
Picker controls are completely unchanged in Catalina’s UIKit
Apple is very much downplaying UIKit on the Mac this year, trying to thread the needle of Mac developer/user perception. However, I think it’s clear the one-two punch of Catalyst and SwiftUI has all but ensured that the future of the Mac UI is shared with iOS
The nail in that coffin is the fact that they didn’t implement any connection between that and AppKit. That’s going to do more than convince users, it’ll win over developers very quickly. No one will want to work without it soon. Therefore that’s what users will get used to.
Apple made less attempt to show that Catalyst apps can be good than I did in three blog posts. I think that’s a mistake.
I’m still waiting for Apple to show a good high information density mouse focused app made with it (
NSTableViewstyle grid of information?).Music and Podcasts may look the same (good), but they both look like iPad apps; with giant touch targets and massive list row heights.
Regarding last week’s Mazipan (now Catalyst) video: Apple hasn’t shown enough today to give me confidence these will be good. I am pretty worried about these apps. Cut for time, maybe, but I fear the consumer Mac is in a precarious position
As far as I can tell, window title visibility is the only concession apart from window title that we get in Catalyst; there’s no way to set minimum/maximum content sizes, window style mask, etc
Bafflingly, Apple hasn’t yet shipped
UIUserInterfaceIdiomMacin Catalina, which means the 77% scaling is here to stay. Is that really not something coming this year? 😱
Bummer on macOS/Catalyst: static libraries from iOS Simulator and from regular macOS won’t work, even if they’re pure C/C++ and don’t make any use of Cocoa or higher-level framework code. May be able to hack Mach-O header loading commands to work around this but a big pain.
That was quite a day at WWDC. My big take aways:
1. NeXT is finally dead. ObjC and IB are done. AppKit too.
2. React has won (…like it or not).
3. Mac-specific software is not long for this Earth. Not a single ADA winner was for macOS.
I’ve seen people wondering how different Catalina’s Catalyst is from Mojave’s Marzipan: the process architecture is different, but overall it’s very similar. Same issues, same bugs as marzipanified apps from a year ago; more of the holes have been filled+more frameworks ported
Xcode automatically adds “uikitformac” to the bundle ID for Catalyst builds.
which is a pain in the ass if you support iCloud. I have no idea yet how to fix it
Previously:
Update (2019-06-04): Colin Cornaby:
The other interesting thing to me is how Swift UI still has to be hosted inside a UIKit or AppKit app. It actually massively compliments AppKit by giving AppKit a path to share UI with a UIKit app.
If you’re an AppKit developer right now, the best path doesn’t look like tearing down and porting to Catalyst. It looks like starting to build shared SwiftUI components where you can.
SwiftUI : Cocoa :: Catalyst : Carbon
Update (2019-06-06): Matt Birchler:
Reasons to create a Mac app based on your iPad app. They specified that if you already have a great Mac app then there’s no compelling reason to use this.
[regarding Twitter] I can never understand how companies can take indie apps maintained by 1 person and grow them into 100+ developer Goliaths, that seem to have the same or fewer features.
How can tiny teams make native Tweetbot and Twitterrific for multiple platforms, but Twitter itself can’t do that without Catalyst?
Update (2019-06-19): Steve Troughton-Smith:
There seems to be no way for a Catalyst app to ‘share purchase’ with an iOS app(?), which would put me off shipping anything with it. And due to the enforced bundle ID prefix I can’t even use UIKit to replace my existing Mac app on the App Store(?), which I would do for sure
If you want to share a subscription between iOS and Mac/Catalyst, you’ll have to do it all yourself. Apple has no solution for that yet. iCloud Containers are one option, but I’ll probably go with @RevenueCat
Catalyst, from what Apple revealed this week, is a sideshow for games, toy apps, and media consumption apps.
Who did we see in the keynote raving about Catalyst? Twitter. A poorly-run company with no strategy. They had a great Mac client. They also had arguably the world’s most innovative iPad app. They threw both away because their execs were too dumb to recognize what they had.
Odd comparison, but: the Mac developer who says Catalyst will be the end of Electron is like the web developer who says web apps will be the end of native.
They’re going to co-exist forever. But it’s amusing how the extremists on each side are convinced the other is doomed
The near-universal excitement about SwiftUI among long time Mac devs really undermines the critique that they are all stuck in their ways and defensive about change. They rightly just didn’t want to run a weirdo iOS app on their Mac.
“Just follow this twelve-step process to opt out of the automatic uikitformac bundle identifier prefix!” 😪
This is a huge shortcoming for the App Store as Apple broadens the appeal for cross-platform apps without improving the options for “single point of sale.” Kudos to @RevenueCat for filling the void.
Embed your new macOS bundle in your app and make its inclusion conditional to macOS only.
It’s as simple as that! Now you have a loadable bundle that is built with the Mac SDK, and thus has access to all of AppKit. All you have to do is load it manually when you detect you’re running on macOS.
Re-watching Catalyst sessions, it seems clear that Apple expects devs to offer brand new app SKUs for the Mac App Store w/ no shared purchase, shared IAPs, shared subscriptions. I can’t ship on macOS like that, so if that doesn’t change before Sept, that makes Catalyst DOA for me
That’s a huge part of Catalyst that’s fundamentally broken, and not in a small way. It’s hard enough to get users to pay for apps in the first place; forcing them to pay again for the Mac will scupper many apps that wanted to support Mac but not commit to standalone Mac app
If you want to share an app record between macOS and iOS, and share purchases/IAPs/subscriptions, you better get your feedback in now because if Apple doesn’t course-correct you won’t be able to ship on the Mac for another year at the least
I’m very biased here, but I think for premium Mac apps this is a good thing. This will ensure that Catalyst apps won’t immediately bring down the higher MAS price level. But I agree, customers don’t understand why they have to pay two times and Catalyst isn’t helping.
Apple didn’t show off anything at WWDC to enable developers to do anything more than ‘dump their iPad UI on Mac’. That clearly wasn’t the message (despite it being possible), and isn’t documented at all
Confirmation from Apple that they do not consider Simulator and Catalyst binaries to be ABI compatible and so are presumably not going to provide a solution to embed libraries from the former in the latter.
Since Apple’s making a point to treat Catalyst apps as ‘true Mac apps’, that means that your app can do what any other Mac app can do: embed an AppKit-based bundle or framework, and load it at runtime as a plugin.
I’m going to make an absurdly long term prediction: Catalyst is going to be deprecated at the same time as UIKit. Could be a decade before we get there. But it’s not going to be the future environment that SwiftUI is built on.
Resizable windows, drag and drop support, keyboard support. Wow! What a great testimony to Catalyst that Mac users can expect such advanced features. Maybe we’ll even be able to copy and paste text.
Update (2019-08-05): Peter Steinberger:
We’re ~4 weeks away from the GM and there’s still no real answer if AppKit bundles are allowed on Mac Catalyst. The clearest reply I got today was:
“We do not recommend doing this and cannot guarantee support in the future.”
So… it’s ok? It will pass Mac App Store?
My guess: Any Mac Catalyst app that isn’t a game and doesn’t suck will use this approach. It will be a critical mass. They will have to ensure things don’t break in 10.15.
Having sample code how to do this and fail gracefully would be great. Or having any sample code at all…
7 Comments RSS · Twitter
Not The Onion:
> Twitter is thrilled to announce we are bringing the Twitter for iPad experience to the Mac!
