Platform, Multiplatform & Companion App: what's the actual difference?
Hi everyone, have you ever heard “platform app”, “multiplatform app”, and “companion app” used as if they meant the same thing? They do not, and this article walks through each one in turn.
By the end of this article, you will be able to tell the three patterns apart, know which Xcode setup each one uses, and pick the right one for your next Apple app.
A single app built for exactly one Apple platform
A platform app targets one specific Apple operating system (iOS, macOS, watchOS, tvOS, or visionOS). It is built, compiled, and shipped only for that one destination. The developer picks a single platform target in Xcode. The resulting binary runs only on that hardware family.
This is the default starting point for any Apple project. You get full access to the platform’s SDK with nothing in the way. There is no expectation that the code will ever run anywhere else.
Best for: Apps where the main interaction depends on specific hardware. Think LiDAR scanning, the Digital Crown, Siri Remote navigation, or a watchOS complication. It is also the right choice when the team has no real plans to support other form factors.
Examples: A dedicated iOS banking app with Face ID, a standalone tvOS video player, a watchOS fitness tracker that lives only on the wrist.
One codebase. Multiple platforms. One app identity.
Multiplatform apps first arrived in Xcode 12 and grew in Xcode 14. A multiplatform app is a single Xcode target that supports multiple Apple destinations. The most common set is iPhone, iPad, and Mac. The same Swift and SwiftUI code is compiled for each platform. Apple’s documentation describes this as “sharing project settings and code across platforms in a single app target.”
The model layer, business logic, and most SwiftUI views are written once and run everywhere. Platform-specific behaviour is handled only where needed. You can use #if os(iOS) compilation conditionals, environment values like horizontalSizeClass, or separate view files that are only included in certain compile sources.
Apple’s WWDC22 session 110371 is a clear reference. It explains the difference between the multiplatform template and the separate-targets approach. Separate targets still make sense when platforms need different codebases, or when they lean heavily on UIKit vs AppKit. For SwiftUI-first projects that share most of their logic, the single multiplatform target is the recommended default as of Xcode 14.
Real examples: Apple’s own Notes, Reminders, Freeform, and Pages use this model. Third-party examples include finance trackers, to-do apps, and reading apps. In each case, the same content and actions are just as useful on phone, tablet, and desktop.
Two separate apps, coordinating across platforms
A companion app is built differently from both of the above. It is a second, separate application on a secondary platform that extends or adds to a primary app. Each app has its own bundle ID and often its own App Store listing.
Apple’s WWDC19 session on creating independent Watch apps made this vocabulary official. In the watchOS world, the “companion” is the iPhone app that a Watch app pairs with. They talk through the WatchConnectivity framework and exchange live messages, application context, and file transfers. The Watch app’s experience is shaped by its relationship to the iPhone app.
The companion pattern goes well beyond watchOS. An iOS app might have a macOS companion that works as a sync or admin dashboard. A tvOS game may use an iOS companion as a second screen or a physical controller. In every case each app plays a clearly different role, as a separate tool that fits what the secondary platform is good at and the limits it works under.
WatchConnectivity exposes an isCompanionAppInstalled boolean. It lets the Watch app check whether the iPhone app is present before it tries to talk to it.
Examples: A fitness app where iPhone manages workout history and watchOS shows live heart rate. A smart home app where iPhone configures automations and Apple TV shows a live camera dashboard. An airline app where iPhone handles booking and Apple Watch surfaces the boarding pass.
Side-by-side comparison
| Attribute | Platform app | Multiplatform app | Companion app |
|---|---|---|---|
| Xcode targets | One target | One target, multiple destinations | Two or more separate targets |
| Bundle ID | Single | Single (shared) | Multiple, one per app |
| Codebase | One platform’s code | Shared, with conditional divergence | Separate codebases, coordinating |
| App Store | One listing | One multi-platform listing | Separate listings (usually) |
| User experience | One device, optimised fully | Same core UX, adapted per device | Different roles, complementary, not identical |
| Communication needed | None | Optional (shared CloudKit data model) | Yes: WatchConnectivity, CloudKit, networking, deep links |
| Best when… | Use case is tied to one platform’s hardware | Core value works the same on all devices | Secondary platform needs a fundamentally different role |
Which should you choose?
Apple does not publish one single document that compares all three patterns. You have to build the mental model yourself from WWDC sessions and API documentation. The rules of thumb below come from that material:
Decision flow
“Same UX” and “Different role” are what separate the multiplatform and companion patterns.
Recap
The goal was to help you tell these three patterns apart and pick the right one for your app. Here are the main points:
- A platform app is one Xcode target, one bundle ID, one platform. Pick it when the app depends on one device’s hardware.
- A multiplatform app is one Xcode target with multiple destinations and one shared codebase. Pick it when the same experience makes sense on phone, tablet, and desktop. Apple recommends it as the default for SwiftUI-first projects since Xcode 14.
- A companion app is a second, separate app with its own bundle ID. The two apps talk over a channel like WatchConnectivity or CloudKit. Pick it when the secondary device plays a different role.
- To choose between multiplatform and companion, ask whether the secondary device gets the same app resized or a different tool in the same ecosystem.
I hope this writing helps you choose with more confidence. Thanks for reading, and feel free to share it with someone who is starting a new Apple project.
Cited sources