Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 48 minutes and 18 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis change adds comprehensive Apple platforms documentation to the Home Assistant project website. Navigation configuration is updated to include "Apple platforms" in the navbar menu, sidebar structure adds a new "Apple" section with eight documentation pages, and the homepage is updated with Apple platforms references. Eight new documentation files provide getting started guides, architecture overview, build targets information, testing procedures, CI/CD setup details, code style guidelines, and contribution submission instructions. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
docs/ios/ci.md (1)
44-50: Avoid hardcoding CI runtime versions in docs.Pinpoint values like
Xcode 26.2/iPhone 17/iOS 26.2will go stale quickly and cause doc drift. Prefer wording like “current CI Xcode/simulator versions” and link to the workflow file as source of truth.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/ios/ci.md` around lines 44 - 50, Replace hardcoded runtime/version mentions ("Xcode 26.2", "iPhone 17", "iOS 26.2") in the docs snippet and instead describe them as the "current CI Xcode/simulator versions" and refer readers to the CI workflow as the source of truth; update the Fastlane description that references the `Tests-Unit` scheme and `HomeAssistant.xcworkspace` to say it runs the unit tests on the CI-configured simulator (rather than naming a specific device/os), and add a link or pointer to the workflow file where the exact Xcode and simulator versions are defined.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/ios/get_started.md`:
- Around line 85-90: Reword the run steps to use location-first phrasing and
bold UI strings: change each step to start with the target (e.g., "In Xcode,
open **HomeAssistant.xcworkspace**"), "In the scheme selector, choose
**App-Debug**", "In the device selector, choose an iOS simulator or a
development device", and "In Xcode, build and run." Also make **App-Debug** and
other UI labels bold to match repository style.
- Line 100: Replace the fragment heading "Autocorrect supported issues:" with a
goal-fronted, action-oriented label such as "Run autocorrect on supported
issues" (or "Apply autocorrect to supported issues") in the
docs/ios/get_started.md heading; update the visible heading text where the
string "Autocorrect supported issues:" appears to use that imperative phrasing
to comply with the Microsoft Style Guide.
In `@docs/ios/submit.md`:
- Line 2: The page title "iOS submit contribution" is awkward; update the title
value in the frontmatter (currently title: "iOS submit contribution") to a more
natural phrase such as "Submit an iOS contribution" or "iOS contribution
submission" so navigation and headers read clearly.
In `@docs/ios/testing/introduction.md`:
- Around line 61-64: Reword the Xcode instruction to front the location phrase
and format UI-facing strings in bold: change the sentence to start with the
location ("In Xcode, open **HomeAssistant.xcworkspace**") and render the test
scheme names as bold UI strings (e.g., **Tests-Unit**, **Tests-UI**) instead of
inline code; update the sentence containing "run the relevant test scheme
directly" so the location phrase leads and the scheme names use bold formatting.
---
Nitpick comments:
In `@docs/ios/ci.md`:
- Around line 44-50: Replace hardcoded runtime/version mentions ("Xcode 26.2",
"iPhone 17", "iOS 26.2") in the docs snippet and instead describe them as the
"current CI Xcode/simulator versions" and refer readers to the CI workflow as
the source of truth; update the Fastlane description that references the
`Tests-Unit` scheme and `HomeAssistant.xcworkspace` to say it runs the unit
tests on the CI-configured simulator (rather than naming a specific device/os),
and add a link or pointer to the workflow file where the exact Xcode and
simulator versions are defined.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 84df2848-fe4b-4d5c-b502-400d1dc0012c
📒 Files selected for processing (11)
docs/ios.mddocs/ios/architecture.mddocs/ios/ci.mddocs/ios/codestyle.mddocs/ios/get_started.mddocs/ios/submit.mddocs/ios/targets.mddocs/ios/testing/introduction.mddocusaurus.config.jssidebars.jssrc/pages/index.js
Co-authored-by: Joost Lekkerkerker <joostlek@outlook.com>
There was a problem hiding this comment.
🧹 Nitpick comments (2)
docs/ios/get_started.md (2)
112-114: Add a direct link to the README section for frontend testing.The text now clarifies that "frontend" refers to the embedded WebView, but redirecting readers to "the repository README" without a specific link or inline summary makes it harder to find the workflow. Consider adding a direct link to the relevant README section or providing a brief inline summary of the steps.
📝 Suggested improvement
If a specific README anchor exists:
-If you only want to validate frontend changes, you can install the simulator app artifact produced by CI and debug the embedded WebView with Safari Web Inspector. The repository README documents that workflow in more detail. +If you only want to validate frontend changes, you can install the simulator app artifact produced by CI and debug the embedded WebView with Safari Web Inspector. The [repository README](https://github.com/home-assistant/iOS#frontend-development) documents that workflow in more detail.Alternatively, provide a brief inline summary:
-If you only want to validate frontend changes, you can install the simulator app artifact produced by CI and debug the embedded WebView with Safari Web Inspector. The repository README documents that workflow in more detail. +If you only want to validate frontend changes, you can install the simulator app artifact produced by CI and debug the embedded WebView with Safari Web Inspector: + +1. Download the simulator app artifact from a CI run. +2. Install it on an iOS simulator. +3. Open Safari Web Inspector to debug the WebView. + +The [repository README](https://github.com/home-assistant/iOS) provides additional details.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/ios/get_started.md` around lines 112 - 114, The "Testing just the frontend" section should include a direct pointer to the exact README section or a short inline summary of the workflow; update the heading content to either add a link to the specific README anchor for frontend/WebView testing (the README section that describes installing the simulator artifact and using Safari Web Inspector) or insert a one- or two-sentence inline summary of the steps (e.g., download/install the CI-produced simulator app artifact, launch the simulator, enable the embedded WebView remote debugging and open Safari Web Inspector) so readers can immediately follow the workflow without hunting for the referenced README.
16-16: Consider adding installation links for Ruby version managers.While the dependency installation section below provides concrete examples, adding direct links to Homebrew, rbenv, or mise installation pages here would help new contributors quickly set up their environment.
📚 Suggested enhancement
-- Ruby 3.1 with either Homebrew, `rbenv`, or `mise` +- Ruby 3.1 with either [Homebrew](https://brew.sh/), [rbenv](https://github.com/rbenv/rbenv), or [mise](https://mise.jdx.dev/)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/ios/get_started.md` at line 16, Update the "Ruby 3.1 with either Homebrew, `rbenv`, or `mise`" line in docs/ios/get_started.md to include direct installation links for Homebrew, rbenv, and mise (e.g., link text to their official install pages) so new contributors can click through; ensure the sentence still mentions Ruby 3.1 and retains the inline code formatting for `rbenv` and `mise`.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@docs/ios/get_started.md`:
- Around line 112-114: The "Testing just the frontend" section should include a
direct pointer to the exact README section or a short inline summary of the
workflow; update the heading content to either add a link to the specific README
anchor for frontend/WebView testing (the README section that describes
installing the simulator artifact and using Safari Web Inspector) or insert a
one- or two-sentence inline summary of the steps (e.g., download/install the
CI-produced simulator app artifact, launch the simulator, enable the embedded
WebView remote debugging and open Safari Web Inspector) so readers can
immediately follow the workflow without hunting for the referenced README.
- Line 16: Update the "Ruby 3.1 with either Homebrew, `rbenv`, or `mise`" line
in docs/ios/get_started.md to include direct installation links for Homebrew,
rbenv, and mise (e.g., link text to their official install pages) so new
contributors can click through; ensure the sentence still mentions Ruby 3.1 and
retains the inline code formatting for `rbenv` and `mise`.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 13e6576c-58f3-4909-b985-4807da511b33
📒 Files selected for processing (4)
docs/ios/ci.mddocs/ios/get_started.mddocs/ios/submit.mddocs/ios/testing/introduction.md
✅ Files skipped from review due to trivial changes (3)
- docs/ios/testing/introduction.md
- docs/ios/ci.md
- docs/ios/submit.md
Co-authored-by: Martin Claesson <43297668+Claeysson@users.noreply.github.com>
Co-authored-by: Martin Claesson <43297668+Claeysson@users.noreply.github.com>
…nt into ios-docs # Conflicts: # docs/ios/ci.md # docs/ios/get_started.md # docs/ios/testing/introduction.md
| ```mermaid | ||
| flowchart LR | ||
| App["Sources/App<br/>(iPhone and iPad app)"] --> Shared["Sources/Shared<br/>(cross-target logic)"] | ||
| Shared --> Extensions["Sources/Extensions<br/>(widgets, App Intents, notifications, …)"] | ||
| Shared --> CarPlay["Sources/CarPlay"] | ||
| Shared --> Watch["Sources/Watch and Sources/WatchApp"] | ||
| graph TD; | ||
| App[Sources/App - iPhone and iPad app] | ||
| Shared[Sources/Shared - cross-target logic] | ||
| Extensions[Sources/Extensions - widgets, App Intents, notifications] | ||
| CarPlay[Sources/CarPlay] | ||
| Watch[Sources/Watch and Sources/WatchApp] | ||
| App --> Shared | ||
| Shared --> Extensions | ||
| Shared --> CarPlay | ||
| Shared --> Watch | ||
| ``` |
There was a problem hiding this comment.
I start to like the graph, I think it adds a lot. Mind if I throw you something?
I think currently it kinda shows the flow chart from the steps down below, but would it make more sense to have it explain the structure for the user? So
- If I have the WatchOS app, what components are involved? From what I understand now it'd be App, Shared, Watch (and maybe Extensions)
- If I maybe want to make a change to the shared part, Can I see in one view where this is used?
- I think it'd be cool if we can remove
Source/(or maybe play with adding a<br />so the location is on a single line as now it breaks off. - You can add links to these models, so you could link it to the iOS repository
There was a problem hiding this comment.
Ok, I tried to ask claude but it failed, looks very wrong, I will play with it a bit
3 participants
Proposed change
Add a dedicated iOS developer documentation section, modeled after the existing Android developer docs and based on the current Home Assistant iOS repository structure and contributor workflow.
This PR adds an iOS landing page plus contributor-focused pages for getting started, architecture, targets, testing, code style, CI, and submitting changes. It also updates site navigation so the new iOS section appears in the homepage, navbar, and left sidebar like the Android docs.
Type of change
Checklist
Additional information
Summary by CodeRabbit