Apple iPadOS: Smart Move for Developers During Cross-Platform Push

Forget your (likely dim) view of the iPad as a full-fledged “computer”: Despite Apple’s insistence that the tablet is actually a PC, it can’t get around the clumsy keyboard folio, small screen, and limited desktop-class processing power. But if you’re developing apps for Apple’s ecosystem, you should rush to support its new operating system, iPadOS. Here’s why.

The last few generations of iOS have created a schism between iPad and iPhone. Apple invented bespoke features for the iPad, which finally prompted it to spin those features into a unique operating system named iPadOS. This latest iteration is still very mobile; the look and feel is more iPhone than Mac, and it still carries some mobile-first features that power users will point to when they yell, “But it’s NOT a computer!” iPadOS is, after all, an iOS derivative, and that comes with lock-in, such as the inability to run prompts from the terminal.

Why iPadOS is Critical

Still, if you’re developing iOS apps, you should support iPadOS. Heck, even if you have no interest in the platform, you should support it! In the most important ways, it’s a two-for-one deal.

With iPadOS, there are some desktop features: Multiple-window support, drag-and-drop, desktop-class Safari browsing, and the ability to access files and folders from external sources are all key here. It’s the bridge between the iPhone and desktop… which is exactly why it’s critical.

Most developers within Apple’s ecosystem create apps for iOS, the UIKit framework and tooling should be familiar (AppKit, the tooling used for dedicated macOS apps, is long in the tooth and has enough obstacles that developing apps for it is unfriendly). Catalyst, Apple’s cross-platform tooling within Xcode, allows iPadOS apps to come to the Mac with a few clicks.

In some ways, the AppKit/UIKit argument is becoming null. With Catalyst, the de facto framework for developing apps for Apple’s ecosystem will be UIKit. there are plenty of reasons to avoid AppKit (and the desktop), but almost no good reason to eschew mobile… and the ability to port a mobile app to the desktop makes ignoring either silly.

Within Xcode, choosing to make your app available to macOS means “fundamental Mac desktop and windowing features” are added automatically, as is mouse/touchpad/keyboard support. Some of the iPadOS features, such as split-view, will port to your Mac app without any fuss.

But this doesn’t mean the development work is done. Apple encourages developers to round out their ported apps to be more desktop-like, and support things such as the menu bar or unique gestures. There may also be some interface work to be done.

The Future of App Development

Those developers with pro apps will likely want to round out the iPadOS/macOS app (we could just call them Catalyst apps) with additional features for desktop. And it seems UIKit is the direction Apple wants us to move in this case, as well. In August, we noted Catalyst documentation only references UIKit; that’s still largely true, though a note has been added to the “Optimizing your iPad App for Mac” page: “iPad apps running in macOS can only use AppKit APIs marked as available in Mac Catalyst, such as NSToolbar and NSTouchBar. Mac Catalyst does not support accessing unavailable AppKit APIs.” This is the only AppKit mention.

In June, we wrote: “We think of [using UIKit in place of AppKit] like a deprecation of AppKit, much as Objective-C was deprecated when Swift arrived. Swift didn’t kill Objective-C, and the UIKit framework familiar to iOS developers isn’t killing AppKit. You can still write an iOS or macOS app in Objective-C, and you can still write a ‘traditional’ macOS app using AppKit.”

The iPad app ecosystem, like the Mac app ecosystem, has suffered because developers have problems seeing why they should support either when they can just focus on the (profitable) iPhone world. Catalyst helps answer that; it’s no longer a binary choice, because it’s a two-for-one app development process in most cases. And though the Mac App Store is still sparsely populated, that presents opportunity once macOS Catalina lands this month, and cross-platform apps start populating there as well as in the iPadOS App Store.

The iPad is not a desktop-class computer, and the Mac is not a mobile device. But Catalyst helps developers get a sense of what each brings to the table, and how to best support each ecosystem with a single core app. Both platforms need great apps, and the ability to have one app populate on both operating systems is intriguing in a big way. As SwiftUI (Apple’s MVVM development paradigm) gains traction, we expect the avenues between Mac and iPad and iPhone and Apple Watch and TV to be largely interchangeable.

For now, supporting iPadOS and Catalyst ports to macOS is a great primer for the future of app development.

2 Responses to “Apple iPadOS: Smart Move for Developers During Cross-Platform Push”

  1. Normen Wohner

    I politely disagree.
    Swift is a language, not a Framework. The only reason it did not “replace” Objective-C is that Objective-C exists in large quantities in old App code. We will not replace it any near future either because it is just to much to put a budget on. I know very simple Apps with almost a Gig of code out there whose development would be stalled 8 months just to fully migrate them. So we only migrate what we touch.
    ObjC however does not intrinsically offer Anything that Swift can’t. I dare you to find a Programmer that disagrees. Swift is just an objectively better language.

    The same can absolutely not be said for AppKit and Catalyst. While it is lovely to use SwiftUI where you can, and that is inherently UIKit so far. Catalyst is just a framework on a framework, there to help you migrate something you otherwise would not have considered migrating. It visibly impairs your App. By the time you need to fidget with Catalyst to make it look “acceptable” you could have pulled off a decent UI in AppKit and then enjoy an open door of features that Catalyst just cannot talk to. It just isn’t meant to replace it yet.
    SwiftUI will eventually take over the Mac just as well as it soon will iOS. It’s just better than traditional programmatically generated UIs or the old and dusty Storyboards. Now while I welcome the Idea of “NS prefixes and 1000+ lines of boilerplate” disappearing from Desktop App code, Catalyst is just not the end all solution.
    Catalyst might evolve or be replaced by a newer version of AppKit who cares about semantics, what we need however is access from SwiftUI to sane and pretty Desktop standards and functionality! A button needs to behave and feel a Desktop kind of way. Programs need to be able to operate and communicate through more than a single Window and a few Warning popups.
    Content within Windows needs to be manually resizable and concealable.
    There is simply said an Essay of questions that Catalyst has no answer to. The future is near, but Catalyst is merely a tool for the lazy.

  2. Biggest problem for Apple is that if you develop for Apple you basically develop for Apple. This was fine in the days of most people embracing a purely Apple only ecosystem. But today it doesn’t work very well, people want more choice, cross platform compatibility, apps that also cross boundaries and not require you to embrace only certain operating systems. Microsoft is probably one company that saw this early and has worked much harder to bridge gaps in cross platform compatibility for its software. Uses can access Office 365 from any browser or OS and get mostly the exact same experience. You Cannot say this with many Apple applications. I would say most who continue to live in the Apple ecosystem and feeling more and more locked into a very inflexible system that unfortunately is very hard to escape from. This is benefiting Apple of course, but as users realize this when they do escape they won’t come back. This ideal that people will come to Apple rather than Apple coming to them is a model that doesn’t work anymore. The ideal of expecting people to live in a Apple bubble and not realize there is technology outside of that bubble will eventually hurt Apple.