What to Decide Before Spreading One Idea Across Every Apple Platform

Reason about each device's context concretely

You can't decide on abstractions alone, so lay out concretely what kind of app makes a context hold for each device.

Take a wallpaper app I operate, for example. On iPad, the context of "pick artwork on a large screen" genuinely holds. Apple Watch, on the other hand, has almost no motive for choosing wallpaper on the wrist, so I judged that shipping it would only add operating cost. Even for the same app, the answer splits by device into "yes" and "skip."

Draw the line between shared and branched code first

Once you decide to extend to several devices, settle in your own mind "what's shared and what's branched" before you hand it all to generation. Rork Max writes the code for each target, but where you confine device-specific behavior is a design decision that bites later.

Notification behavior and layout density, for instance, can't be shared as-is between iPhone and Apple Watch. Confining those differences in one place with conditional compilation keeps later maintenance quiet.

struct GlanceView: View {
    var body: some View {
        #if os(watchOS)
        // On the wrist, show only the minimal info that finishes at a glance
        CompactSummary()
            .padding(.horizontal, 6)
        #else
        // On iPhone / iPad you can place list and detail side by side
        DetailedSummary()
            .padding(.horizontal, 16)
        #endif
    }
}

Pushing branches into one place like this makes the spots you'll touch predictable when you add a device, and reduces accidents where a fix for one device breaks the other. Telling generation up front "express this difference as a platform branch" also shrinks the cleanup you'd otherwise do by hand.

The operating cost each added platform brings

To decide calmly whether to add one, make the added cost concrete. Add one platform and you get at least one more set of the following.

• One more target in App Store review (and one more round of dealing with rejections)
• Creating and updating screenshots and copy for that device
• Handling that device's specific bug reports and inquiries
• Re-verifying behavior in production with every OS update

Generation can't take these over. The easy ones to overlook are device-specific screenshots and device-specific inquiries. A report that "the display breaks on Apple Watch" is work that wouldn't have existed if you hadn't shipped Watch.

I measure whether to add a new device not by how easy generation is, but by "can I keep operating this for six months?" I draw the line at six months to ask whether I can quietly keep tending it after the post-release heat cools. If I sense I can't keep it up, I don't add it at that point.

Start from a minimum set and widen on data

My conclusion is this: precisely because generation can cover so much now, deliberately narrow what you ship first. Build one iPhone version carefully and get it into operation. Look at the data you gather — which screens get used, where people drop off, what requests come in — and only then widen, one device at a time, to the ones where context holds.

This order has a side benefit. When you add a device later, you already know how the iPhone version is used, so you can decide "what to cut and what to keep" for that device with grounds. You can scope an Apple Watch version down to the one feature that means something on the wrist — not the iPhone version's full feature set — from data rather than guesswork.

Rork Max opening the door to every Apple platform is unquestionably a big step forward. But the door being open is a different matter from whether you should haul your luggage into every room. Generation is cheap; operation isn't. Keeping that asymmetry in mind and selecting the devices worth shipping to — that, I think, is the plain, dependable stance for running several apps over the long haul. I hope it gives you a footing for your own decisions if you've been torn over where to expand.