We knew that HomeView OS is rough for developers right now, and leverages CarPlay APIs, but a new tour of how the smart home peripheral exposes just how restricted it is.
The HomeView will officially ship to consumers on November 13, but more is being learned about the smart home device well in advance. Work to virtualize HomeView OS is giving developers more of a glimpse of how the operating system functions.
Threads on Mastodon by Gui Rambo and Steve Troughton-Smith take a developer-centric view of the HomeView's operating system, starting with its use of a new launcher. Following SpringBoard, PineBoard, and SoundBoard, it's using a launcher called BreadBoard.
Apple also apparently continued the trend with a dedicated Control Center UI process called CupBoard.
The delving is performed using virtualization, which Rambo notes already throws up a glitch. The label for HomeView in the virtual machine shows iOS 27.2.0, when really it's running a form of tvOS 27.2 with a "DeviceFamily" of 8.
HomeView's set-up page and running an app locally - Image Credit: Steve Troughton-Smith/Mastodon
Interestingly, Smith was able to launch a Broadcasts app natively within HomeView OS, albeit in a limited form. While developers are being given the CarPlay SDK to work on HomeView projects, evidently it's possible to get other apps running on the operating system.
This despite Apple's decision not to have an App Store on HomeView, nor to allow other apps to be installed.
Settings and authentication
Continuing the tour, Smith entered the Settings and saw that swipe typing was still usable within HomeView OS. The general Settings app user interface looks a lot like Settings on an iPhone or iPad, complete with search.
There was also the discovery of a Liquid Glass strength slider. Users can set whether the effect is more transparent or opaque, similar to other Apple devices.
AirPlay pairing and Liquid Glass slider on Homeview - Image Credit: Steve Troughton-Smith/Mastodon
Smith also found that many system apps require profile authentication before being able to view them. Users can elect to use their personal iPhone or iPad for authentication, or the onboard camera.
When using the camera, the HomeView warns it will temporarily increase the screen's brightness if the room is too dark, or if there's too much shadow on the user's face. A "Recognizing" screen appears with an animated face, before showing a page asking to select a user profile if that fails.
AirPlay, CarPlay, and a developer headache
For AirPlay, pairing is performed with a four-digit code for authentication. Once complete, Smith was able to AirPlay video in wide and square layouts, complete with subtitles and on-screen speed and audio track controls.
After some work, CarPlay was able to be used. Referred to as "PebblePlay" in the operating system, it turns out that the rendering of apps happens on the HomeView using a developer-supplied template.
Running HomeView OS on a virtual machine - Image Credit: Gui Rambo/Mastodon
Though it works like CarPlay from a developer standpoint, developers are advised by Smith that they may want to have different templates for a CarPlay head unit and the HomeView. It does seem that HomeView's CarPlay implementation also only supports audio and video apps, with it not indexing navigation apps or others, such as ChatGPT.
To Smith, Apple's implementation of apps through CarPlay is not a desirable route for an SDK to take. While he believes the concept of showing phone-specific apps per profile is a good one, developers will not be satisfied by the use of a system combining elements of CarPlay and WatchKit 1 in this way.
He concludes by saying that if this were "Option A," he would really want to see what B and C were.
