Platform, Multiplatform & Companion App: what's the actual difference?
A single app built for exactly one Apple platform
A platform app targets one specific Apple operating system (iOS, macOS, watchOS, tvOS, or visionOS) and is built, compiled, and distributed only for that destination. The developer selects a single platform target in Xcode and the resulting binary runs only on that hardware family.
This is the default starting point for any Apple project. It gives the developer full access to the platform’s SDK with no abstraction layer in the way, and carries no expectation that the code will ever run elsewhere.
Best for: Apps whose core interaction is inseparable from specific hardware: LiDAR scanning, the Digital Crown, Siri Remote navigation, or a watchOS complication. Also correct when the team has no realistic 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.
First introduced in Xcode 12 and expanded in Xcode 14, a multiplatform app is a single Xcode target that declares support for multiple Apple destinations, most commonly iPhone, iPad, and Mac, compiling the same Swift and SwiftUI codebase 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 of the SwiftUI views are written once and run everywhere. Platform-specific behaviour is handled narrowly, only where needed, via #if os(iOS) compilation conditionals, environment values like horizontalSizeClass, or separate view files included only in certain compile sources.
Apple’s WWDC22 session 110371 is a clear reference. It distinguishes the multiplatform template from the separate-targets approach: separate targets are still appropriate when platforms need different codebases or rely heavily on UIKit vs AppKit. For SwiftUI-first projects sharing 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 where the same content and actions are equally useful on phone, tablet, and desktop.
Two separate apps, coordinating across platforms
A companion app is architecturally different from both of the above. Rather than one app identity running in multiple places, a companion app is a second, distinct application on a secondary platform that extends or augments a primary app. Each has its own bundle ID and often its own App Store listing.
Apple’s WWDC19 session on creating independent Watch apps formalized this vocabulary. In the watchOS context, the “companion” is the iPhone app that a Watch app pairs with via the WatchConnectivity framework, exchanging live messages, application context, and file transfers. The Watch app’s experience is fundamentally defined by its relationship to the iPhone app.
The companion pattern extends well beyond watchOS. An iOS app might have a macOS companion serving as a sync or admin dashboard. A tvOS game may use an iOS companion as a second screen or physical controller. The defining trait is that each app plays a qualitatively different role: not the same experience rescaled, but a separate tool suited to what the secondary platform is good at and the limits it works under.
WatchConnectivity exposes an isCompanionAppInstalled boolean that lets the Watch app check whether the iPhone app is present, a concrete API signal of how tightly this pattern can couple two apps together.
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 a single canonical document comparing all three patterns. The mental model must be assembled from WWDC sessions and API documentation. These heuristics are distilled from that material:
Decision flow
“Same UX” and “Different role” are the key discriminators between the multiplatform and companion patterns.
Cited sources