<!-- 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 -->
To leverage the features from the legacy iOS Actions, this PR adds
triggerSource to all service calls in the app so users can automate
based on which device (watch/phone/car) triggered that.
## 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 -->
For some reason Realm database migration was not being called event
though scheme version was already bumped to 28, apparently this was
caused by watch complication that was accessing realm passing specific
object types
Test process:
- Checkout commit c257fa21f62acb964edb28c6d3db0796a86731f1
- Run App in iPhone and watch (with some Actions created)
- Checkout commit 2c8470e5fec8a6c715bfe7de113b3f35c37a4e84
- Run App in iPhone and watch
> - this was crashing in watch and now it is running the migration
block.
## 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 -->
Based on user feedback, color customisation is important on their iOS
Actions, in widgets and Apple Watch, so this PR adds this option back
but with a little modification, we will first enforce the tile card
design as the standard, if the user wants to use custom colors it has to
enable "custom colors" toggle in actions configuration screen. (I will
also make a PR in Core to be able to configure that via YAML)
This PR also makes the "default" background color for watch items to be
dark instead of white.
## 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 -->
Some users have pointed out thei Actions sometimes are not sync, this is
to help out define if the time of the sync is relevant.
## Screenshots
<!-- If this is a user-facing change not in the frontend, please include
screenshots in light and dark mode. -->
<img width="703" alt="Screenshot 2024-04-22 at 13 41 04"
src="https://github.com/home-assistant/iOS/assets/5808343/41cd1ff7-7cc3-4cf5-9814-fe59289553f9">
## 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. -->
<img width="584" alt="Screenshot 2024-01-18 at 02 24 31"
src="https://github.com/home-assistant/iOS/assets/5808343/bc037f5d-d916-4715-aaf1-2b823014a99a">
## 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
When a server is deleted, we now update the identifiers of any locally-defined actions or complications to point to the first server. We want to avoid ever having a server identifier pointing to a deleted server so we can trust the identifiers more.
## Any other notes
Deleting in this case would be bad as it's an unexpected data loss. I can imagine someone deletes and re-adds the server (potentially the last one, too), or other maintenance tasks.
Fixes bad logic in the "can server identifier be edited?" check, and colors the detail label of the server select row like a field row in other Eureka contexts.
## Summary
Stores a zone from s1 in Realm like `s1/zone.name` rather than `zone.name` so it's distinct from `s2/zone.name`. This is most apparent for `zone.home` which universally conflicts.
## Any other notes
This does not yet extend to the other synced models as we use their identifier in persisted locations that aren't programmatically changeable (e.g. action IDs are stored in intents). Zones don't pose such a problem, and are the most likely suspect to even have duplicates right now; scenes, actions, and deprecated notification categories can be done after an external beta.
- Updates several dependencies
- Removes Lokalise -- if we can't do it on Catalyst, it doesn't feel worth it to do it elsewhere
- Migrates the NotificationTestCases from a Podspec that keeps having issues to a fastlane script which copies in the latest ones
## Summary
- Moves a few uses of `states` in the REST API into the WebSocket API.
- Zones and Scenes now update instantly as we're updated via the WebSocket subscription.
## Any other notes
- Moves the account row in Settings to be fully self-contained on user and avatar lookup, both through the same WebSocket API call for finding out what to show.
- Moves zone fetching's `get_zones` WebHook call into the WebSocket API cache for `get_states`.
- Moves scene's fetching `get_states` into the same WebSocket API cache.
- Moves Camera ID intents lookup.
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.
Words cannot describe how bad SPM is. For the future record, here are the big reasons:
- Xcode fails to find Swift Package Manager Binary Target dependency… FB8743041
This manifests as "cannot find module Clibsodium" or "Realm" or whatever.
- Xcode Swift Package Manager checkout retry has 0-second delay FB8742078
Xcode's built-in version of git/curl has bugs with pipelining, forcing us to replace it with another version to get ci to be more reliable.
- xcframework via Swift Package Manager both statically links to library and embeds it FB8721223
This requires us massaging the output build products because Xcode produces invalid binaries, which fail all the validation Apple does on App Store Connect upload and on Developer ID Notarization.
-----
In total, this means using SPM produces invalid builds, often fails to build correctly, and often fails to check out dependencies correctly. What a let-down.
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.
