nanda mochammad
Apple Developer Concepts

Platform, Multiplatform & Companion App: what's the actual difference?

7 min read
Tagged iOS
Concept 01: Platform 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) 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.

Diagram: a single Xcode target compiles for one platform; other platforms are out of scope. Xcode project Single target builds for iOS App One destination only macOS: not targeted watchOS: not targeted out of scope
A single Xcode target compiles for one platform. All other platforms are out of scope: not targeted, not compiled, not distributed.

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.


Concept 02: Multiplatform App

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.

Diagram: one shared codebase in a single Xcode target fans out to iOS, macOS, and visionOS, all sharing the same bundle ID and one App Store listing. Shared codebase One Xcode target iOS iPhone + iPad macOS Native Mac app visionOS Apple Vision Pro Same bundle ID One App Store listing
One Xcode target fans out to multiple platforms. All destinations share the same bundle ID and a single App Store listing covers all of them.

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.


Concept 03: Companion App

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.

Diagram: an iOS primary app and a watchOS companion app, each with its own bundle ID, coordinate bidirectionally through WatchConnectivity. iOS app (primary) Bundle ID: com.acme.Fitness WatchConnectivity watchOS app (companion) Bundle ID: com.acme.FitnessWatch Rich interaction · history · settings Glanceable data · quick actions Two bundle IDs · Two separate roles · Coordinated experience
Two distinct apps, each with its own bundle ID, coordinate via WatchConnectivity. The iPhone app handles depth and data entry; the Watch app handles glanceability and quick interaction.

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

AttributePlatform appMultiplatform appCompanion app
Xcode targetsOne targetOne target, multiple destinationsTwo or more separate targets
Bundle IDSingleSingle (shared)Multiple, one per app
CodebaseOne platform’s codeShared, with conditional divergenceSeparate codebases, coordinating
App StoreOne listingOne multi-platform listingSeparate listings (usually)
User experienceOne device, optimised fullySame core UX, adapted per deviceDifferent roles, complementary, not identical
Communication neededNoneOptional (shared CloudKit data model)Yes: WatchConnectivity, CloudKit, networking, deep links
Best when…Use case is tied to one platform’s hardwareCore value works the same on all devicesSecondary 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

New Apple app One device only?→ Platform app
Same experience on all devices? Yes, same UX→ Multiplatform app(recommended default for SwiftUI projects)
Different role on secondary device? Yes, different role→ Companion app

“Same UX” and “Different role” are the key discriminators between the multiplatform and companion patterns.

Cited sources