Beyond iPhone: Developing across Apple platforms

At the Swift Craft(opens in a new tab) conference in May 2025, I gave a five minute ‘lightning’ talk about how, with SwiftUI and UIKit, you can build apps that run across Apple platforms. The talk presented a quick overview of the options available and how I believe that a pragmatism-over-polish mindset is the way forward. In this post, I’ll provide a written version of the talk, followed by a little background about the process behind giving the talk.

At Nutrient, we make an SDK for viewing and editing PDF documents, and our product runs across iOS, macOS, and visionOS. Despite that, our team is called the iOS team. You might similarly call yourself an iOS developer. Chances are that, whether you know it or not, your skills may already extend across Apple platforms. We can use similar skills to make apps for iPhone, iPad, Mac, Apple Vision Pro, Apple TV, and Apple Watch.

For new codebases, you’d want to use SwiftUI because it runs across all of these platforms.

If you have UIKit code, it’s not a blocker, as this will also work everywhere except Apple Watch. For most projects, this is probably not a problem.

iPad

If you run an app that’s only been created for iPhone on an iPad, you’ll see a large black border around it. This is functional but it’s not that great.

The user experience is nicer with Stage Manager because you can mix the iPhone-sized window with other windows. However, Stage Manager is a power user feature most users won’t have enabled.

In your app target’s General settings in Xcode, you can add additional destinations for other platforms.

If you add iPad as an option, you’ll have an app that runs on any size on iPad.

I’d encourage you to do this, even if it ends up looking like a blown-up iPhone app. In most cases, you’ll already be adapting to different sizes of iPhones, so your UI can probably stretch to an iPad without breaking. It might not be the optimal user experience, but I think this is still better than those thick black borders.

Designed for iPad/iPhone on Mac and Vision

Apple silicon Macs(opens in a new tab) and Apple Vision Pro(opens in a new tab) can run unmodified iOS apps if you allow this on App Store Connect.

Consider the situation where you open a website, and you’re told your browser isn’t supported. This is really annoying, because you feel the website probably would work, but the developer decided they don’t want to test in the browser you’re using. Most functionality in most apps will work fine on Mac and Vision automatically. Depending on exactly how your app could fail, I’d really encourage you to enable the relevant checkboxes on App Store Connect to give users the choice. Your app definitely isn’t going to work for the user if they can’t even open it.

Mac

To get more control over how the app works on Mac and to run on Intel Macs, you need to build a separate version of your app, compiled using a different SDK. Separate builds means separate uploads to App Store Connect, so there’s more overhead to releases. Without additional effort, this doesn’t make much difference to how native the app feels.

Here’s my favourite slide from the talk, showing the extensive array of options Apple provides for making Mac apps.

Diving into these options could be a whole other talk or series of articles. The main point is that Apple makes two SDKs for Mac: the macOS SDK from the early 2000s, and Mac Catalyst, which is derived from the iOS SDK. Unless a native Mac app is extremely important for your project, I’d recommend Mac Catalyst because you can use the same code as your iOS app.

Apple Vision Pro

On Apple Vision Pro, you can already run an iPad app right away and you’ll get this opaque window, which is OK, but it’s not such a native experience.

It’s much better if you build a separate version of the app using the visionOS SDK, which is based on the iOS SDK. You can use the same SwiftUI and UIKit code.

Apple TV and Apple Watch

I didn’t have time to cover Apple TV and Apple Watch at Swift Craft, but I’ll briefly mention them here. These devices are more specialised than Apple’s other platforms: Apple TV due to its less expressive input methods, and Apple Watch due to its small screen. As such, it’s not possible to directly run an iOS app on either tvOS or watchOS. While SwiftUI is available on both, and UIKit is on tvOS, the number of APIs available is more limited, so sharing code across platforms isn’t as suitable as with iOS, macOS and visionOS. You may be able to use frameworks to share code for models, data processing, and some UI components, but not the app as a whole.

Concluding the talk

I’d encourage adopting an approach like web developers with responsive design principles. On the web, there are so many different browsers, operating systems, screen sizes, and input methods. Web developers make it work. I think we can adopt a similar mindset to not just make iOS apps, but Apple platform apps. It doesn’t necessarily have to be perfect everywhere, but it’s better to provide users with the options.

Behind the scenes: Talk preparation

There’s a longer talk I’d like to give that goes into a lot more detail about what we’ve learned at Nutrient shipping a unified product for iOS, macOS and visionOS. For example, I’d cover some specific APIs to watch out for and explore the pros and cons of all the options on Mac. However, this talk is at the stage of being an outline rather than being prepared in detail.

I wasn’t aware of the possibility to submit ideas for lightning talks for Swift Craft until the weekend before the conference, and I spontaneously decided to submit the talk I gave, which was essentially the introductory part of my longer talk idea. On Monday, I received a confirmation I could go ahead with my talk, giving me slightly more than 24 hours until the lighting talks took place to wrap up Tuesday, the first day of the conference. This naturally meant I didn’t rehearse or refine my slides as much as I might otherwise have done.

My talk was the last for the day. Coincidentally, the first talk of the conference day was by the other Doug at the conference, Doug Gregor(opens in a new tab) from Apple, who gave the opening keynote, On Progressive Disclosure in Swift(opens in a new tab). His talk provided a lot of insight into the design of many Swift language features.

I’m normally someone who carefully plans things out in advance, but the spontaneity made the conference more fun. I was happy with how the talk went, and I’d encourage everyone to just go for it and submit talks to conferences, especially if there are lightning talks. Most likely you have ideas about how software should be made or learned something that was interesting to you. As with bringing apps across platforms, having something is better than nothing, even if it’s not perfect.