<!-- 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. -->
---------
Co-authored-by: Copilot <175728472+Copilot@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 -->
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 -->
Integration PR:
https://github.com/home-assistant/core/pull/121496#event-13420408451
## 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
This pr intruduces the following changes:
- Upgrades the [Alomofire
dependecy](142efae0cc).
- Removes not needed [available
anotations](a4e71a3c88)
and split up code in multiple files; The anotations are not needed since
https://github.com/home-assistant/iOS/pull/2469.
## Screenshots
No user faceing changes
## Link to pull request in Documentation repository
NA
## Any other notes
NA
## 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 -->
## 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
During onboarding, allow trusting an invalid certificate chain for most features of the app.
## Screenshots
<img src="https://user-images.githubusercontent.com/74188/170773293-14eeb3fb-2e54-42a5-b6c6-8b07c792ea24.png" width="300">
## 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
Future changes necessary:
- Trusting certificates if an error occurs while the app is running
- Trusting certificates when configuring internal/external URLs
## Summary
Version 0.110 started sending internal_url/external_url, but older versions than that send base_url.
## Any other notes
This is really only a problem because versions older than 0.104 do not support including the device id in the registration, but we don't know the version number until we pull the config from the webhook, which can only be created after registering the device. Thus, if you're using a version older than 0.104 and doing manual setup, it'll still always fail, but discovery-based will start working after this.
Fixes#380. Fixes#1794. Fixes#350. Fixes#722.
## Summary
- Pulls all of the onboarding steps out of segue-based storyboards and into code.
- Merges authentication with scanning/manual, reducing steps in auth.
- Removes the "checklist" final screen.
- Supports going 'back' through onboarding steps, e.g. an error after entering a URL.
- Moves permissions from an opt-in "which would you like?" to a required "you must accept/decline this permission" for each permission. See notes below for why.
- Removes the team migration warning from last year.
- Adds landscape & dynamic type support to onboarding. I didn't bother to make the DT do live-updating though.
- Fills in internal & external URL, sets active SSID if possible after location permission.
- Connects to internal URL from discovery instead of base (external) URL.
- Allows onboarding to a server which requests, but does not require, client certificates.
- Allows starting Onboarding skipping the Welcome screen, connects this to the 'add server' row in app configuration when in debug mode.
- Stops calling api/discovery_info for testing connectivity.
- Handles Bonjour updates and removals in the scanning screen.
## Any other notes
Apple is actively blocking 2021.10 (only on iOS) because of an unwritten part of [rule 5.1.1](https://developer.apple.com/app-store/review/guidelines/#5.1.1), saying:
> **Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage**
>
> We noticed your app encourages or directs users to allow the app to access the location. Specifically, your app directs the user to grant permission in the following way(s):
>
> - A message appears before the permission request, and the user can close the message and delay the permission request with the "Continue" button. The user should always proceed to the permission request after the message.
>
> Permission requests give users control of their personal information. It is important to respect their decision about how their data is used.
This is of course referring to our screen which looks like this:
<img width="200" src="https://user-images.githubusercontent.com/74188/136716566-349558d4-d343-4ede-acd6-83b4e66742bc.png">
I love that they're cherry-picking the location part of this when we allow users to do a number of things on this screen. I believe the part of 5.1.1 that they are alluding to here is:
> (iv) Access: Apps must respect the user’s permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access. For example, apps that include the ability to post photos to a social network must not also require microphone access before allowing the user to upload photos. Where possible, provide alternative solutions for users who don’t grant consent. For example, if a user declines to share Location, offer the ability to manually enter an address.
They do link to the Human Interface Guidelines' [Accessing User Data](https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/accessing-user-data/) whose section "Displaying Custom Messaging Before the Alert" says:
> **Make it clear that opening the system alert is the only action people can take in your custom-messaging screen.** People can interpret a pre-alert message as a delaying tactic, so it’s critical to let them quickly dismiss the message and view the system alert. If you display a custom screen that precedes a privacy-related permission request, it must offer only one action, which must display the system alert. Use a word like "Continue" to title the action; don’t use "Allow" or other terms that might make people think they’re granting their permission or performing other actions within your custom screen.
I do not believe that we're showing a pre-alert message since we're showing numerous options and allowing the user to pick and choose. Oh well. This new onboarding has improvements in other ways, and maybe is _more_ clear about permissions and what they do, so lemons into lemonade I guess.
Fixes#1657.
## Summary
Adds the `icon` key to actionable notifications' actions, which must be `sfsymbols:`-prefixed strings of SFSymbols names.
## Screenshots
With a payload that looks like…
```js
{
/* … */
"actions": [
{
"action": "SOUND_ALARM",
"title": "Sound Alarm",
"icon": "sfsymbols:bell",
},
{
"action": "SILENCE_ALARM",
"title": "Silence Alarm",
"icon": "sfsymbols:bell.slash",
}
]
}
```
| Dark | Light |
| -- | -- |
|  |  |
## 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#577
## Any other notes
Apple requires that these icons either be pre-baked asset catalog assets, or part of the SFSymbols library (FB9149810), so these are prefixed with `sfsymbols:` to future-proof it.
Depends on home-assistant/mobile-apps-fcm-push#47 which allows the actions to be included in the notification data, and also on-the-fly silently sets the category to `DYNAMIC` which this requires.
## Summary
Allows for specifying the actions for a notification on-the-fly without defining a category. This should allow us to make all of the category config and setup unnecessary, so I'll probably consider marking it as deprecated in this release.
## Screenshots
For a notification that looks like…
```yaml
service: notify.mobile_app_iphone
data:
title: title here
message: body here
data:
actions:
- action: "id1"
title: "id1 title"
# this mirrors the action definition in yaml now, it just _also_ supports what android
- identifier: "id2"
title: "id2 title"
```
## Link to pull request in Documentation repository
- Documentation: home-assistant/companion.home-assistant#496
## Any other notes
- Dynamic actions are visual - we provide custom UI on both iOS and watchOS for the additional actions, which does require we run the app on the given platform; for example, this doesn't yet work on macOS [I need to figure out how to make Catalyst notification content work, if it is] and if you uninstall the watch app these actions will not show up.
- Allows `map` and `camera`-esque notification content on any category. In other words, if you send a notification with `map` it'll still prefer the camera `entity_id` if present. This is largely to continue in the direction of making category deprecated; as long as the content extension launches, it'll figure out what to display.
All of the normal action configuration is allowed in these actions:
- action or identifier
- title
- authenticationRequired (default: false)
- behavior (default: default, aka not textinput)
- activationMode (default: background)
- destructive (default: false)
- textInputButtonTitle (default: nil)
- textInputPlaceholder (default: nil)
Some additional things occur to match existing Android functionality:
- `uri` (or `url`) being provided in the action makes it a 'foreground' action
- action/identifier of `REPLY` changes the behavior to textinput
- `mobile_app_notification_action` is now fired with data that looks like theirs:
```
Sending action: mobile_app_notification_action
payload: ["action": "REPLY", "reply_text": "Reply text"]
```
and
```
Sending action: mobile_app_notification_action
payload: ["action": "id1"]
```
## Summary
Moves the one instance of this call (Intents) to using the WebSocket API.
## Any other notes
- Updates to use the new PromiseKit extensions and automatic connection handling in HAKit.
- Removes now-unused models for Services and already-unused Events.
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.
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.
