Your Widget on a Kitchen Counter: the HomeView Audit

On October 13, 2026, Apple announced HomeView and, the same day, added three new sections to the Apple Developer Program License Agreement. If your iOS app ships a small widget, you have already agreed to something — and the agreement asks you to think about a car, not a kitchen.

What was announced, and what you can actually test

HomeView is a $299 / £299 seven-inch display — 6.98 inches measured diagonally, per Apple’s own footnote — shipping November 13, 2026. It is not sold in the European Union; Apple’s wording is “Apple HomeView is not available for sale in the European Union.” If your app ships only to EU markets, this audit is optional.

There is no HomeView App Store. The device runs HomeView software 27.2 and requires a paired iPhone on iOS 27.2 or later, or an iPad on iPadOS 27.2 or later. iOS 27.2 is not released. As of October 15, 2026 the current public build is iOS 27.0.1 (September 28, 2026), with 27.2 beta 4 seeded October 13. Apple has announced no release date for 27.2, and I won’t guess one.

That shapes everything below. This is a code-and-contract review against a beta and a device nobody outside Apple has used. The toolchain is Xcode 27 with Swift 6.4, released September 14, 2026. Treat behavioural claims as provisional and re-verify at ship time.

The new §6.4, verbatim

The October 13 revision adds §6.4 (no body text), §6.4.1 and §6.4.2. The press coverage quotes fragments; here are the two operative paragraphs in full.

6.4.1 iOS Application Widgets on CarPlay and Apple HomeView You agree that Your iOS Application widget may be made available on CarPlay and Apple HomeView. Furthermore, You are responsible for determining whether Your iOS Application widget is functional and suitable to use for CarPlay, and for using the disfavoredLocations function to disfavor Your iOS Application widget if it is not. For example, iOS Application widgets that are not functional or suitable include those that require extensive user interaction while driving, or that require the iPhone to be unlocked to be used. Apple reserves the right to disfavor Your iOS Application widget if Apple determines it is not functional or suitable for CarPlay.

6.4.2 Availability of iOS Applications for CarPlay on Apple HomeView If Your Application includes a CarPlay entitlement profile in a category identified by Apple in the Documentation, You agree Apple may provide access to such Application on Apple HomeView while it is running on a paired iOS device.

Read the drafting closely. The permission is bilateral — “CarPlay and Apple HomeView.” The duty is unilateral: suitability “for CarPlay.” The remedy is unilateral. Apple’s reserved right to disfavor is unilateral. Both worked examples are driving examples.

So you have granted consent for two surfaces and acquired a documented duty to reason about one. No HomeView suitability standard exists in the agreement. Neither “Apple HomeView” nor “CarPlay” is defined in the section text. The analysis at ppc.land reached the same reading independently.

How a widget becomes eligible — one declaration, made years ago

The eligibility test is a single line of configuration. WWDC25 session 216 put it plainly: “All you need to do is support the systemSmall widget family.” WidgetKit scales your systemSmall widget to fit, and the docs note that StandBy and CarPlay support come together — “when you ensure your widget supports one, it automatically supports the other.” Apple’s CarPlay developer page states that a small widget or Live Activity “will automatically appear in CarPlay with no changes required.”

StaticConfiguration(kind: "balance", provider: Provider()) { entry in
    BalanceView(entry: entry)
}
// This line is the entire eligibility test.
.supportedFamilies([.systemSmall, .systemMedium])

Omit supportedFamilies entirely and you support all families, including that one. No CarPlay app, entitlement, or CarPlay-specific code is involved.

Two corrections to how this is being described. First, “opt-in by default” is self-contradictory — the accurate version is that consent comes from accepting the agreement, there is no per-app toggle, and eligibility is a side effect of a declaration most apps made for unrelated reasons. Second, widgets are not pushed or mirrored onto the device. MacStories, reporting Apple’s Human Interface Guidelines text as of October 14, describes a person choosing small widgets from an on-device gallery and placing them on the Modular face or the Home Screen. I have not read that HIG page directly, so treat the placement model as reported rather than confirmed.

Also: CarPlay widget support shipped in iOS 26. Users have been able to add your systemSmall widget to a car for a year. HomeView adds a surface, not a new category of exposure — and you can go look at your widget in a real car today. The 4×6 extra-large widget added in iOS 27 is irrelevant here; these surfaces take systemSmall only.

The exits, and what they do not do

The agreement names disfavoredLocations as the remedy. Here is the signature, verified October 15, 2026, available since iOS 17:

.disfavoredLocations([.carPlay], for: [.systemSmall])

WidgetLocation currently has seven members: carPlay, iPhoneWidgetsOnMac, homeScreen, lockScreen, smartStack, standBy, watchFace. There is no .homeView. You cannot express “fine in the car, not on the counter.” Disfavoring .carPlay is the nearest lever and it points at a different device. Whether it affects HomeView at all is undocumented.

Worse, Apple’s own site disagrees on what disfavoring does. The WidgetKit guide says doing so “doesn’t exclude your widget from CarPlay or StandBy, but it communicates to people that these locations aren’t the best fit.” The CarPlay developer page says you can indicate a widget isn’t optimised “to prevent it from being shown.” Both fetched October 15, 2026. The reference docs and WWDC25 support the weaker reading: the widget moves to the gallery’s “Other” section, and interaction is disabled if someone adds it anyway. A developer following §6.4.1 is being handed a tool whose documented behaviour is demotion, not removal.

There is one documented hard exclusion. containerBackgroundRemovable(false) “excludes your widget from the widget gallery in contexts that require a removable background” — Apple names the iPad Lock Screen and StandBy. It does not name CarPlay or HomeView. Since a removable background is listed as a StandBy/CarPlay requirement, exclusion plausibly follows, but that is an inference I have not tested in the CarPlay Simulator, and it is off-label: the modifier exists for widgets whose content is the background, and it costs you the iPad Lock Screen and StandBy too.

The blunt instrument is dropping .systemSmall. That ends eligibility and also surrenders the iPhone Home Screen’s most-used size, the Lock Screen, and StandBy. For most apps that trades away far more than it buys.

What actually leaks, stated precisely

The scaremongering version of this story does not survive Apple’s privacy model, so don’t build on it. HomeView recognises up to six enrolled people and gives each a personalised Home Screen. Personal content from Messages and Calendar surfaces only when the enrolled person is recognised by face and their paired device is present and recently unlocked. Guests can control accessories, check weather, set timers and play music without reaching anyone’s personal information. Apple does not call the device always-on — it shows idle faces, dims to 0.3 nits, and responds to proximity.

Three things keep the risk real. Apple’s documented gating names Apple’s apps. No Apple source states that third-party widgets inherit face-plus-proximity gating, or that they render with the privacy redaction reason when the owner isn’t recognised. Nobody should claim they do, or that they don’t.

Recognition is presence, not solitude. Being recognised means you are in front of the camera; it does not mean you are alone in the kitchen. And the car assumption breaks: a widget authored for CarPlay was authored for one person in a private cabin, glancing. §6.4.1’s examples are about driving safety, not observation.

The irony is in Apple’s own guidance. The StandBy and CarPlay checklist tells you to “use larger typography, and make it easy to read from a distance” — precisely the property that turns a private number into a household announcement.

A useful diagnostic from WWDC25 session 216: if your widget relies on data protection class A or B, it likely won’t work in CarPlay. Inverted — if your widget was built to work while the phone is locked, you already decided this content is safe on a locked screen in public. Whether that decision extends to a persistent shared display is a product decision, not an engineering one.

Classes worth auditing: account balances and transaction amounts; health and fitness metrics; medication and cycle tracking; dating and message previews; job-search status; delivery contents; home-security and camera state; family member locations; work calendar titles; streak counts that imply behaviour.

The audit, in six steps

1. Am I eligible? Grep every WidgetConfiguration for supportedFamilies. If .systemSmall is present, or the modifier is absent, you are eligible. Check Live Activities too — they appear in CarPlay automatically.

2. Am I already there? Add your widget to a CarPlay car today. That exposure predates HomeView by a release.

3. Read each widget as a stranger across a room. Not “is this safe while driving” but “what does someone who isn’t the account holder learn.” Every timeline entry, including placeholder and error states.

4. Does a degraded mode exist? If no view carries privacySensitive() and nothing reads redactionReasons, your widget has nothing for any gating to act on:

@Environment(\.redactionReasons) private var redactionReasons

if redactionReasons.contains(.privacy) {
    Text("••••").font(.headline)
} else {
    Text(entry.balance, format: .currency(code: "USD"))
        .privacySensitive()
}

This is a prerequisite for gating, not a guarantee of it. Also note: levelOfDetail (iOS 26+) is a rendering hint whose inputs “can be determined by different factors depending on the platforms.” It is not a location identifier. Do not use it as a HomeView detector.

5. Expose the choice instead of detecting the context. There is no API to detect where a widget is rendering. Asked in the developer forums how to distinguish CarPlay from the iPhone Home Screen, an Apple frameworks engineer answered: “You will need to file an enhancement request for this.” One was filed (FB22802365) and appears to still be open. So a redacted variant that activates on HomeView is not shippable. A user-selectable one is:

struct DiscreetModeIntent: WidgetConfigurationIntent {
    static var title: LocalizedStringResource = "Balance"
    @Parameter(title: "Hide amounts", default: false) var hideAmounts: Bool
}

With AppIntentConfiguration, a person can plausibly configure the counter instance to hide amounts while leaving their phone instance intact. The per-placement model that makes this work is reported, not documented for HomeView — test it before promising it.

6. Decide, and record who decided. §6.4.1 assigns the suitability judgement to you, with Apple reserving an override. That allocation of responsibility belongs in a written decision, not in one developer’s head.

What nobody knows yet

Being accurate about the gaps is more useful than filling them. As of October 15, 2026, these are unanswered by any source I could verify:

Do third-party widgets on HomeView inherit face-plus-proximity gating, or render redacted when the owner isn’t recognised? Does disfavoring .carPlay affect HomeView at all? Does a nonremovable container background exclude a widget from CarPlay and HomeView? Is there a user-facing setting listing which widgets may appear, equivalent to Settings → General → CarPlay? Which CarPlay entitlement categories does §6.4.2 actually cover — the agreement defers to documentation it does not quote, and Apple’s HomeView materials mention only “compatible third-party audio and video apps”? Does rendering happen on HomeView or on the paired iPhone, and what does that do to timeline budgets? And what is the effective date of the revised agreement — Apple’s news item gives none, while acceptance is required to keep distributing.

Two facts to re-check immediately before you act on any of this. WidgetLocation having no .homeView case is the load-bearing technical claim here, and it could change in any SDK seed. And the two contradictory Apple sentences about what disfavoring does may quietly become one; screenshot both now.

The practical summary: your small widget is eligible, a person has to place it, the only lever Apple pointed you at demotes rather than removes, and the duty the agreement wrote for you is about driving. The kitchen is yours to reason about.