菜单
SwiftUI and UIKit UI conventions for Home Assistant iOS. Use when building views, choosing SwiftUI vs UIKit, bridging with embeddedInHostingController(), building reusable components in the HADesignSystem package, or following the one-struct-per-file, inline-body, and #Preview rules.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Home Assistant iOS project layout, build setup, and the "World" dependency-injection pattern. Use when starting work in the repo, deciding where code lives across targets (App, Shared, Watch, CarPlay, Extensions), accessing dependencies through the global `Current`, or setting up dependencies and code signing.
Swift code style, linting, logging, assets, and idioms for Home Assistant iOS. Use when writing or formatting Swift, running SwiftFormat/SwiftLint, referencing SF Symbols or Material Design icons, logging, or using the with() helper.
Asynchronous code and server networking conventions. Use when writing async/await, Tasks, actors, or Combine, deciding whether to touch PromiseKit, annotating view models with @MainActor, or calling the Home Assistant server via HAKit.
Localization via SwiftGen-generated L10n accessors and the en.lproj .strings files. Use when adding or changing user-facing strings, working with the L10n/CoreStrings/FrontendStrings tables, or dealing with Lokalise-managed translations.
The cross-platform MagicItem action model shared by Widgets, Watch, CarPlay, and App Shortcuts. Use when adding or changing item types or action overrides, or touching anything that persists MagicItem via Codable.
Data persistence across GRDB, Realm, and UserDefaults. Use when adding or migrating a persistent model, choosing a storage layer, implementing DatabaseTableProtocol, or reading/writing config for Watch, CarPlay, widgets, or the entity registry.
| name | ha-ios-ui |
| description | SwiftUI and UIKit UI conventions for Home Assistant iOS. Use when building views, choosing SwiftUI vs UIKit, bridging with embeddedInHostingController(), building reusable components in the HADesignSystem package, or following the one-struct-per-file, inline-body, and #Preview rules. |
View.embeddedInHostingController() for SwiftUI-to-UIKit bridging@MainActorView struct is introduced, put it in its own file. Do not stack multiple view structs in one file.body: build the view's content inline inside body. Do not abstract portions out into separate reusable subviews (helper view structs or computed some View properties) just to break body up. Extract a new struct only when it is genuinely reused elsewhere, and when you do, it gets its own file (see above).#Preview: every SwiftUI view must ship with a preview so it can be checked quickly in Xcode.ha-ios-testing skill).HADesignSystem)Reusable, app-agnostic UI lives in the HADesignSystem Swift package (Sources/HADesignSystem), not in Sources/App. Shared re-exports it (@_exported import HADesignSystem), so anything that already does import Shared sees the design system with no extra import.
HADesignSystem. Only genuinely one-off, app-specific views stay in Sources/App.Current (the World), no L10n product copy, no Server/app models, no MaterialDesignIcons. Inject text, colors, icons, and data through init parameters instead. (This is why a few still-coupled components remain in Shared for now.)UIScreen, UIColor.label, etc.) in #if !os(watchOS).Color+Semantic.swift on ShapeStyle where Self == Color (so both Color.haPrimary and .foregroundStyle(.haPrimary) resolve). Add new semantic colors there, not to an asset catalog.DesignSystemComponent (categorized via ComponentCategory) so it shows up in ComponentsLibraryView, the in-app components explorer/glossary.