<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
<img width="1796" height="804" alt="CleanShot 2026-01-16 at 13 11 31@2x"
src="https://github.com/user-attachments/assets/4c0be252-f3b6-4ff5-b27e-8b11f19eaee4"
/>
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
## Summary
BSSID sensor reported MAC addresses without leading zeros (e.g.,
`18:e8:29:a7:e9:b`), inconsistent with Android companion app and
standard MAC address notation. This breaks cross-platform room presence
tracking.
**Changes:**
- Added `String.formattedBSSID` extension that pads hex octets to 2
characters
- Applied formatting to BSSID sensor state in `ConnectivitySensor`
- Added test coverage for formatting edge cases
```swift
// Before: "18:e8:29:a7:e9:b"
// After: "18:e8:29:a7:e9:0b"
sensor.State = bssid.formattedBSSID
```
## Screenshots
N/A - Sensor value formatting change only
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#
## Any other notes
**Breaking change:** Users with BSSID-based automations must update to
the new zero-padded format. This aligns iOS with Android, standard MAC
notation, and network management tools like UniFi.
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>BSSID mac address format isn't consistant with Android
Companion app</issue_title>
> <issue_description>**iOS device model, version and app version**
> <!-- Please include your device 'Model Name' and 'Software Version' as
listed in iOS Settings>General>About. Please also give the app version
listed beneath "Home Assistant Companion" in the App Configuration>About
menu within the app, please include the number in brackets -->
>
> Model Name: IPhone 6S
> Software Version: IOS 14.4.1
> App version: 2021.77
>
> **Home Assistant Core Version**
> version | core-2021.3.4
> -- | --
> installation_type | Home Assistant Container
> dev | false
> hassio | false
> docker | true
> virtualenv | false
> python_version | 3.8.7
> os_name | Linux
> os_version | 5.3.18-3-pve
> arch | x86_64
> timezone | Europe/Paris
>
> <details><summary>Home Assistant Community Store</summary>
>
> GitHub API | ok
> -- | --
> Github API Calls Remaining | 4998
> Installed Version | 1.11.0
> Stage | running
> Available Repositories | 850
> Installed Repositories | 8
>
> </details>
>
> <details><summary>Home Assistant Cloud</summary>
>
> logged_in | false
> -- | --
> can_reach_cert_server | ok
> can_reach_cloud_auth | ok
> can_reach_cloud | ok
>
> </details>
>
> <details><summary>Lovelace</summary>
>
> dashboards | 9
> -- | --
> resources | 6
> views | 31
> mode | storage
>
> </details>
>
> **Describe the bug**
> The BSSID sensor reports access point mac address with leading zeros
omitted
> example:
>
> ```
> 18:e8:29:a7:e9:b
> ```
> The last number is 0x0b
>
> An adroid device connected the the same access point returns
>
> ```
> 18:e8:29:a7:e9:0b
> ```
> **To Reproduce**
> You need to have an access point with mac bytes lower then 0x10
>
> **Expected behavior**
> Having same BSSID representation than reported by Android App
companion
>
> **Screenshots**
> Iphone:
>
>
> Android phone
>
>
>
> **Additional context**
> I'm using BSSID to track room presence based on connected AP. I'm
trying to share BSSID --> access point for all household mobile.
>
> I'd prefer the version with leading 0 witch is aligned with Unify
management tool.
>
> </issue_description>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> <comment_new><author>@zacwest</author><body>
> We're just slurping the value we read from the system, so we'd need to
sanitize the input to change it. It would also be a breaking change for
modifying what values are sent up, which is less-than-ideal since users
get auto-updated in the apps. I'm not sure there's a great path forward
for resolving this.</body></comment_new>
> </comments>
>
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
- Fixeshome-assistant/iOS#1563
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: bgoncal <5808343+bgoncal@users.noreply.github.com>
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
https://github.com/user-attachments/assets/e79c6e4d-13ff-405a-9463-02e597ce4996
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
Following the thread at
https://github.com/home-assistant/iOS/discussions/1764#discussioncomment-10434403
, this is my novice attempt at adding
https://developer.apple.com/documentation/watchkit/wkinterfacedevicebatterystate
or the Watch Battery State, using #2897 as a reference.
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
I don't know how to take a screenshot of the sensor reporting through
the simulator, I can add them if pointed in the right direction.
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
> _I will look into this. I will look for the corresponding watch
battery change docs if they exist and extend them._
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
This is a rough pass. I used #2897 as a launching point - I read it
carefully as this is my first ever code contribution for Swift / iOS,
WatchOS project but I think I had enough heuristics to manage to
_possibly_ get it in the vicinity of it being correct.
I also used `Sources/Shared/API/Webhook/Sensors/BatterySensor.swift` for
including an additional `Battery State` sensor, while exposing both
sensors similarly in name like it's another device.
I think it could still be improved by using
`Sources/Shared/API/Webhook/Sensors/BatterySensor.swift` as a reference.
I tried to change as little as possible.
I wasn't sure if I needed to add anything to
`Sources/App/WatchCommunicatorService.swift`, considering the commit in
#2897,
f961d689e5 (diff-daa127042af3bc5719e4eb4e02e3c50bfcef50084f554e53475f4a4238fdd096)
- I will lean heavily on comments and will iterate where requested, if
the changes aren't edited directly by the maintainers. @bgoncal
- I **do** think I ran the Unit Tests correctly and added to the one
that was also changed in #2897
---------
Co-authored-by: Bruno Pantaleão Gonçalves <5808343+bgoncal@users.noreply.github.com>
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
- Create watch home from iPhone
- Configure Assist for watch from iPhone
- Deprecate message for iOS Actions
- Use Scripts or Scenes directly
- Show/Hide Assist in Apple Watch
- Options to require confirmation before running watch item
(script/scene/action)
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
https://github.com/user-attachments/assets/1e4509f8-45e5-4b39-bfdc-62f9bce64617
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
So you can finally know if that family member is not having their phone
tracked correctly because of the current location permission settings
and messing up with automations :D
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
## Summary
Swift lint and swiftformat are outdated. This PR does update those +
applies the new formatting form swiftformat.
There is 1 swift file with a manual change:
`Sources/Vehicle/Templates/Areas/CarPlayAreasViewModel.swift`. This is
done because `swiftlint` did create the following swiftlint error:
`error: Cyclomatic Complexity Violation: Function should have complexity
10 or less; currently complexity is 11 (cyclomatic_complexity)`.
Because it does change a lot of files the question is if we want to
finetune the `swiftformat` rules.
## Screenshots
No user facing changes.
## Link to pull request in Documentation repository
NA
## Any other notes
NA
<!-- Thank you for submitting a Pull Request and helping to improve Home
Assistant. Please complete the following sections to help the processing
and review of your changes. Please do not delete anything from this
template. -->
## Summary
<!-- Provide a brief summary of the changes you have made and most
importantly what they aim to achieve -->
Drop support for iOS 12 and 13.
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a
corresponding pull request in the Companion App Documentation repository
(https://github.com/home-assistant/companion.home-assistant). Please add
the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull
Request is part of a bigger change, please include it here. -->
Apparently `#if canImport(CoreMediaIO)` is now true even if you are
trying to run the App on iOS instead of macOS, so this PR wraps it also
under `#if targetEnvironment(macCatalyst)`
## Summary
When set to "None", all sensors sent to the server will be redacted.
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#644
## Any other notes
This also updates location when changing location privacy & sensors when changing sensor privacy, so the data server-side will be most-up-to-date.
Fixes#1958.
## Summary
Existing Core Audio stuff already exposes the output devices pretty easily, so creating sensors from 'em is pretty easy.
## Sensor Values
Roughly identical to microphones:
| Sensor | Attributes | Description |
| --------- | --------- | ----------- |
| `sensor.active_audio_input` | `All`, `Active` | The name of the active audio input (microphone), or `Inactive` if not in use. |
| `sensor.active_audio_output` | `All`, `Active` | The name of the active audio output (speaker), or `Inactive` if not in use. |
| `binary_sensor.audio_input_in_use` | None | Whether an audio output (microphone) on the system is currently in use. |
| `binary_sensor.audio_output_in_use` | None | Whether an audio output (speaker) on the system is currently in use. |
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#627
## Any other notes
This updates relatively instantly for when output starts, but takes a few seconds before it updates once output pauses.
Existing `microphone` sensors won't have their unique IDs changed, but their display name will change. New installs will get the new unique ID.
- Stops caching of sensor values and now sends them to the server regardless if we think they have changed. Fixes#1473. The sensor container was (a) prone to issues (as it could not fully capture network semantics) and (b) not updated for multi-server support.
- Moves all intent handling that I can into the app for iOS 14+ / macOS 11+. The only intent that must be in the extension is the focus intent, which now strictly updates just the focus sensor on macOS, since it did not have access to all sensor values. Fixes#1921.
## Summary
Fixes unnecessarily doing a sensor update pass when launching in the background, as well as an occasional crash talking to UIApplication's applicationState off the main thread.
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include screenshots in light and dark mode. -->
## Link to pull request in Documentation repository
<!-- Pull requests that add, change or remove functionality must have a corresponding pull request in the Companion App Documentation repository (https://github.com/home-assistant/companion.home-assistant). Please add the number of this pull request after the "#" -->
Documentation: home-assistant/companion.home-assistant#
## Any other notes
<!-- If there is any other information of note, like if this Pull Request is part of a bigger change, please include it here. -->
## Summary
Fires a sensor update pass if the app is running when the focus status changes.
## Any other notes
The focus sensor _always_ live-updates, but it does so in the Intents extension. This allows the Intents extension to inform the app that it did an update, which (unfortunately, for now) fires a sensor update pass in the app. So we're over-updating the sensors, but we're keeping the in-app sensor list updated. Worth the cost, I think, since the app running when focus changes happening feels rare unless the user's playing with the sensor.
## Summary
- Upgrades the font, config, and adds a migration for renamed/removed icons.
- Migrates the one use of a renamed/removed one: `laptop-mac` -> `laptop`
## Any other notes
This change should also make it a little easier to do the migrations, since the Realm+Initialization part won't need to be touched, probably.
## Summary
Fixes the insta-updating of the focus sensor on iOS 15.
## Any other notes
`INFocusStatusCenter.default.focusStatus` always returns isFocused=false in the extension, but the intent provides the correct focus status for each update -- so we need to cache this value in the extension, and not trust the focus center state.
## Summary
Fixes a crash caused by infinitely recursing the value change.
## Any other notes
This also allows setting fractional minute values, every 15 seconds. The minimum timer which we check is 5 seconds, and that low means we won't detect changes if they occur in a 10 second period which feels too low.
Refs #945. This will not be available until we switch to compiling builds with Xcode 13, regardless of when it is merged.
## Summary
Adds a "Focus" binary sensor which is on when focus is enabled. This updates live, even when the app isn't running, via Intents.
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#543
## Any other notes
Followup is needed for onboarding to prompt for this permission.
Fixes#1473.
Refs #1460/#1467.
## Summary
When an earlier request gets applied later than we expect, we also need to assume it has replaced values similar to the transient update case fixed before.
## Any other notes
I am going to keep telling myself that the long-term benefit of the sensor caching outweighs having to figure out all of these real-world edge cases the hard way. In this case, I already expected it, I just did not fully think through the ramifications of the edge case and how it would look from the server perspective.
Fixes#1460.
## Summary
Fixes our internal cache being out of sync with the sensor values on the server.
## Any other notes
This issue occurs when, for example, we transition from value1 -> value2 -> value1. If the value2 update fails from our perspective, but successfully hits the server, we may not realize that we need to send value1 up again in the future.
Adds new fastlane lanes:
- `fastlane lint` which checks the linters
- `fastlane autocorrect` which applies the linters which can autocorrect (Rubocop, SwiftFormat)
Adds a build step to the Codegen abstract target which runs SwiftFormat in lint mode, pointing out what it's going to change when run.
Applies SwiftFormat to nearly all code -- exempts a few externally-sourced files and generated code.
Fixes#1397.
## Summary
Makes server version optional, returning nil when we don't know rather than a fallback version.
## Screenshots
n/a
## Link to pull request in Documentation repository
n/a
## Any other notes
Prevents an issue where we'd alert about the fallback version being old enough to have an alert, rather than the actual version which comes later. Amusingly the work I did to make sure that we'd handle app-launch-to-web-view events supporting an onboarding flow in the middle causes the alerts to be delayed until the webview loads after initial login.
Replace #1013.
## Summary
Keeps track of what sensors we've sent up during the session and only pushes up changes.
## Screenshots
Just tabbing around between apps on Mac:
```
14:49:15.876 [Info] [main] [HAAPI.swift:824] UpdateSensors(trigger:location:) > updating sensors ["frontmost_app"]
14:49:16.561 [Info] [main] [HAAPI.swift:824] UpdateSensors(trigger:location:) > updating sensors ["frontmost_app"]
14:49:17.422 [Info] [main] [HAAPI.swift:824] UpdateSensors(trigger:location:) > updating sensors ["frontmost_app"]
14:49:30.550 [Info] [main] [HAAPI.swift:824] UpdateSensors(trigger:location:) > updating sensors ["frontmost_app"]
14:49:32.363 [Info] [main] [HAAPI.swift:824] UpdateSensors(trigger:location:) > updating sensors ["frontmost_app"]
```
## Link to pull request in Documentation repository
No user-facing changes.
## Any other notes
Unlike #1013, this does not persist the sensor values to disk. This is a place that can be improved, but there are some unanswered questions/complications with storing to disk (especially around migrations and cleaning up the values when upgrading and when hardware devices change and wrong values are shown) that could probably be solved a little cleaner in the future transparently to consumers of these types.
Fixes#977.
## Summary
Adds a sensor for the current frontmost app, also known as the current foreground or active app.
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#425
## Any other notes
Creates `sensor.frontmost_app` which has a state of the name of the current frontmost app, or None if there isn't one. I'm really not sure how that can happen, but it's definitely possible. This updates via a signal when it changes, so it happens immediately.
Fixes#1184.
## Summary
This is the same sensor as we send up on iOS except it now bounces between No Connection, Wi-Fi and Ethernet.
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#424
## Any other notes
- `sensor.connection_type` now has an `Ethernet` value and is set up on macOS.
- `sensor.connection_type` gains attributes on macOS: `Name` (the name of the network interface, e.g. `Wi-Fi`) and `Hardware Address` (the MAC address of the interface).
- Adds signaled updates to this (and other network) sensors.
Important to note that, although Ethernet is now added to Connection Type, the Wi-Fi sensors for SSID and BSSID will still report values if any Wi-Fi network device is connected, even if it is not the primary route.
Fixes#1247.
## Summary
Adds 3 sensors for displays: "Displays" (a count), "Primary Display Name" (the name of the display with the menu bar on it), and "Primary Display ID" (the ID of the primary).
## Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#421
## Any other notes
- `sensor.displays`
- states like `0`, `1`, `2`, …
- attributes of `"Display IDs": ["id1", "id2", …]` and `"Display Names": ["name1", "name2", …]`
- `sensor.primary_display_name`
- states like `"None"`, `"Built-in Retina Display"`, etc.
- `sensor.primary_display_id`
- states like `"BE82E2E6-EA40-4963-93AD-A0BDC9D2F18F"`, `"1AB60A12-6BB3-4503-96BD-F5B481F5830E"` etc.
Breaking change. Fixes#1261.
Collapses all Camera and Microphone sensors from one-sensor-per-device to two camera and two microphone sensors:
- `binary_sensor.[device]_microphone_in_use` and `binary_sensor.[device]_camera_in_use` (value: true/false)
- `sensor.[device]_active_microphone` and `sensor.[device]_active_camera` (value: name or "Inactive")
This is unfortunately required because both the the `kCMIODevicePropertyDeviceUID`/`kAudioDevicePropertyDeviceUID` and the `kCMIOObjectPropertyName`/`kAudioObjectPropertyName` are not stable; the IDs change and names gain `#2`, `#3`, etc., suffixes. This is despite the documentation reading:
> A CMIODevice's UID is persistent across boots.
and
> An AudioDevice's UID is persistent across boots.
Were this the case, we wouldn't need to worry -- we unique on the device ID after all, and names can change over time were that part actually stable.
This is somewhat in prep of being able to make the project file generated, but also just organizes things into more concrete directory structures.
This pulls out _all_ of the build settings from the root level, and most from the target level, into xcconfigs.
The new directory structure looks like:
- Sources
- App
- (everything from HomeAssistant/)
- WatchApp
- Shared
- MacBridge
- Extensions
- Intents
- NotificationContent
- NotificationService
- Share
- Today
- Watch
- Widgets
- Tests
- App
- UI
- Shared
Somewhat intentionally, the file structure under these is not yet standardized/organized.
The project targets are now:
- App
- WatchApp
- Shared-iOS
- Shared-watchOS
- MacBridge
- Tests-App
- Tests-UI
- Tests-Shared
- Extension-Intents
- Extension-NotificationContent
- Extension-NotificationService
- Extension-Share
- Extension-Today
- Extension-Widget
- WatchExtension-Watch
This does not yet clean up resources vs. sources, nor does it handle some of the "it's in Sources/App but it's part of Shared" crossover directory issues.
