One SwiftUI codebase, three native apps
A SwiftUI multiplatform app builds for iPhone, iPad and Mac from shared Swift code. Done well, you write the data model, business logic, sync and most views once, then give each platform the navigation, input and window behavior its users expect. Done badly, you ship an iPhone app in a Mac window.
It makes sense when:
- Your users work on the Mac and check or capture things on the phone.
- A professional or creative tool benefits from a big screen, a pointer and a keyboard.
- You want Mac and iPad versions without paying for three separate codebases.
What is hard about multiplatform SwiftUI
Navigation is not shared
iPhone apps stack screens. Mac and iPad apps show a sidebar, content and detail side by side. NavigationSplitView collapses to a stack on compact widths, but the information architecture still has to work in both shapes. I design the iPhone flow and the three-column layout together, not one after the other.
The Mac has its own conventions
Menu bar commands, keyboard shortcuts, multiple windows, a Settings scene, right-click menus, hover states, drag and drop, and undo all matter on the Mac. Missing them is what makes an app feel ported. SwiftUI covers most of these with commands, keyboardShortcut and scene types, but each one has to be designed in.
Hardware differences
Platforms do not just differ in screen size. Cameras, sensors and haptics vary, and features that depend on them need a plan for devices that lack them. Sometimes that plan is graceful degradation; sometimes it is another device doing the job.
Where SwiftUI stops
Some controls and behaviors still need UIKit or AppKit underneath. I wrap them in representable views behind a small interface so the rest of the app stays in SwiftUI and the escape hatch can be removed when SwiftUI catches up.
Keeping it maintainable
Scattered #if os(macOS) checks turn a shared codebase into three tangled ones. I split code into SwiftPM modules (models, services, shared UI, platform shells), so platform differences live in a few clear places and tests run against the shared core.
How I built Haptic Forge for three platforms
Haptic Forge is my visual Core Haptics editor for iPhone, iPad and Mac (OS 26 or later), on the App Store and the Mac App Store. It is a good stress test for multiplatform SwiftUI:
- Different layouts for different devices. On iPhone it is a focused editor. On Mac and iPad it is a full editor with a sidebar library, layer tabs and an inspector.
- A hardware gap solved with pairing. Macs and iPads cannot play Core Haptics patterns, so a nearby iPhone pairs once with a six-digit code and plays every pattern as you edit, over an encrypted local-network connection. That workflow is explained in testing haptics on iPhone from a Mac.
- One library everywhere. Collections, favorites and recent work sync through the user’s iCloud across all three platforms; the data side is on my iCloud sync page.
- One file format. Standard .ahap import and export, so patterns stay usable in any app that reads AHAP.
Multiplatform projects I can take on
- A new app designed for iPhone, iPad and Mac from day one, with shared modules and platform-specific shells.
- A Mac version of your existing iOS app, native rather than stretched. See Mac app development.
- An iPad experience that uses the space: sidebars, multiple columns, keyboard and pointer support.
- Restructuring an app that already targets several platforms but has grown hard to change.
Plan your multiplatform app
Tell me which devices your users have and what they do on each, at contact@hobbysoft.pro. I will suggest what to share, what to tailor and where to start.
