# Apple Design Skill review for Flutter, Tauri, Electron, and React Native > Apple Design Skill is an agent skill that reviews application interfaces against Apple Human Interface Guidelines and translates its findings into framework-specific suggestions. It is most useful to developers who want structured design and accessibility reviews, although it remains guidance rather than an executable UI validator. **dickwu/apple-design-skill** — Cross-platform UI/UX design reviewer based on Apple HIG. Works with Flutter, Tauri, Electron, React Native. Compatible with Claude Code, Cursor, Codex. - Repository: https://github.com/dickwu/apple-design-skill - Stars: 1,951 · Forks: 165 - Language: JavaScript - License: not declared - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/dickwu-apple-design-skill ## Apple Design Skill's cross-platform review boundary Apple Design Skill addresses a narrow but practical problem: interfaces often follow familiar visual patterns without following the platform conventions that users expect. The project packages Apple Human Interface Guidelines as an agent skill, so a compatible agent can read relevant guidance before reviewing a screen or proposing changes. Its stated users are developers working with Flutter, React Native, Tauri, Electron, SwiftUI, UIKit, and AppKit. The project is not an SDK that renders controls or changes application code. It is a set of instructions, generated reference pages, a routing table, and helper resources that shape an agent's design response. According to the README, each finding is organized as a What, a Why with a guideline file and heading citation, and a Fix written for the selected framework. That report structure makes the intended behavior explicit, but the README does not say that findings are machine-enforced or that the skill can inspect a running application by itself. Its scope is broader than a visual taste check. The documented review areas include accessibility, platform conventions, visual design, interaction, content, onboarding, permissions, dark mode, Liquid Glass, navigation, forms, and components. This makes it relevant to teams that want one design vocabulary across mobile and desktop stacks. It does not establish that a cross-platform interface can reproduce every native system behavior, so developers still need to inspect the framework implementation and actual device output. ## How guideline routing builds the review The repository layout points to a file-driven review process. `SKILL.md` defines the agent's stance, principles, review lenses, report format, and improvement mode. `references/hig-lookup.md` acts as a routing table containing Apple's summaries and change dates. The generated files under `references/hig/` contain 123 pages plus a curated guide. The expected data flow is instruction, then lookup, then review. An agent receives a design-review request, follows the skill instructions, routes the topic through `hig-lookup.md`, and loads the relevant `references/hig/*.md` pages before writing feedback. The Codex instructions make this explicit by telling the agent to follow `.design-rules/SKILL.md`, use `.design-rules/references/hig-lookup.md` for routing, and load relevant `.design-rules/references/hig/*.md` files. The cross-platform reference is important because Apple documentation uses names that do not map one-to-one to Flutter, React Native, Tauri, or Electron. The repository includes `references/cross-platform.md` for translating Apple's vocabulary. It also includes a curated `liquid-glass.md` page with review rules and a checklist. The design principles are described as Apple's eight principles: purpose, agency, responsibility, familiarity, flexibility, simplicity, craft, and delight. This design reduces unsupported advice, but it depends on the agent being allowed to read the referenced files. A host that installs only a shortened rule file could lose the intended routing behavior. The README does not document a validator that checks whether those files were loaded. ## Accessibility and platform conventions in a review The documented accessibility pass is blocking, which means the skill treats accessibility as a required review area rather than an optional visual refinement. It covers text scaling, contrast ratios, control sizes, screen readers, keyboard access, motion, and transparency settings, with numeric values drawn from the relevant guideline pages. The README says that findings include a citation to the guideline file and heading, which gives developers a way to inspect the reason for a recommendation. Platform conventions differ between mobile and desktop. For mobile, the review includes tab bars, toolbars, sheets, search, and safe areas. For desktop, it includes the menu bar, windows, sidebars, shortcuts, and settings. Light and dark appearance are treated as review contexts. These topics matter for Flutter, Tauri, Electron, and React Native applications because a shared visual component may still need different placement, behavior, or navigation treatment on each platform. The iPhone Duo mode is a more specific example. It walks through the outer display, inner display, partial fold, and Split View. The documented checks favor size classes over fixed widths, keeping the same functions available on both displays, leaving toolbars and tab bars in their system placement, and keeping content away from cameras and the fold. It also warns about bars and dialogs drawn by Flutter or JavaScript that may not receive automatic system adaptations. That warning identifies a real limitation: the repository can identify where system adaptation may be missing, but it cannot confirm that an application's custom layout has implemented the required adaptation. That remains an implementation and device-verification task. ## Installing Apple Design Skill with the skills CLI The shortest documented installation uses the skills CLI. This command adds the repository as an agent skill for supported agents, including Claude Code, Codex, Cursor, OpenCode, and Windsurf: ```bash npx skills add dickwu/apple-design-skill ``` The README provides agent-specific and user-wide variants. The following command installs for Claude Code only: ```bash npx skills add dickwu/apple-design-skill -a claude-code ``` For a user-wide installation, use: ```bash npx skills add dickwu/apple-design-skill -g ``` To preview what would be installed, use: ```bash npx skills add dickwu/apple-design-skill --list ``` The repository also documents an update command for later maintenance: ```bash npx skills update apple-design ``` After installation, the first real use is a design-review request rather than an application command. The README gives prompts such as reviewing a Flutter home screen against Apple's guidelines, auditing a Tauri application for accessibility, checking whether a settings screen follows macOS conventions, or asking whether a Flutter application is ready for iPhone Duo's two displays. These prompts trigger the skill according to the host agent's configuration. The repository does not provide a CLI review command or a separate server, so the first use depends on the agent being able to load `SKILL.md` and the referenced guideline files. ## Manual installation paths for Claude Code and Cursor Claude Code can use a manual project-local or user-level skills directory. The README documents `.claude/skills/` inside a project and `~/.claude/skills/` for the user. This command clones the repository into the user-level directory: ```bash git clone https://github.com/dickwu/apple-design-skill.git ~/.claude/skills/apple-design ``` The documented invocation is a design-review request or `/apple-design`. The skill is described as triggering on design-review requests, but the README does not explain how host-specific trigger detection behaves in every Claude Code setup. Cursor has a separate installation path. The README presents `npx skills add dickwu/apple-design-skill -a cursor`, which is convenient because it uses the same skills CLI as the general installation. It also permits cloning the repository into a project and keeping `.cursorrules` next to the project's own rules. In that setup, the user asks: ```text Review this screen against Apple's HIG ``` The Cursor file is an entry point, while the substantive guidance remains in `SKILL.md` and the `references/` directory. A manual installation that copies only `.cursorrules` would therefore need to preserve the repository's reference files as well. The repository does not document a native graphical installer, a package published to a package registry, or a binary. Installation cost is therefore mainly repository access, agent compatibility, and making sure the reference tree remains available. ## Improvement mode and Liquid Glass guidance Improvement mode extends the review beyond identifying violations. According to the README, it starts with the product context, then plans a token system containing a palette, type roles, a layout wireframe, one signature element, and motion. It critiques that plan against generic defaults before proposing changes. The fix sequence is documented as accessibility first and visual polish later. This is a useful distinction from a static guideline checklist. A review can identify an accessibility failure and also address whether the result has a coherent visual identity. However, the README does not say how the skill validates that a signature element suits a particular product, nor how it evaluates subjective craft decisions. Those parts remain dependent on the reviewing agent's interpretation and the quality of the product context supplied in the request. Liquid Glass receives its own curated reference. The repository describes this page as containing rules, a review checklist, and cross-platform translation. The use examples include asking how to implement Liquid Glass in React Native. The README supports design review of the appearance and platform treatment, but it does not claim to provide a runnable React Native component or a framework-specific rendering implementation. The same boundary applies to app icons, onboarding, permissions, and single-component reviews. They are documented review modes, not independent tools with their own APIs. ## Limitations, alternatives, and maintenance cost The main limitation is the gap between design guidance and runtime correctness. Apple Design Skill can recommend accessibility targets, platform placements, and interaction patterns, but the README does not say that it runs the application, measures contrast, exercises screen readers, or verifies behavior on iPhone, macOS, Android, Windows, or Linux. It should not replace device testing or application-level accessibility testing. A real alternative is a conventional platform design system used directly by the application team. A Flutter team can inspect its own component library and native widgets, while a SwiftUI or UIKit team can work from Apple platform components and its own established review process. That approach is more integrated with implementation and runtime tests, but it does not provide this repository's cross-framework translation layer or its file-routed HIG review format. Apple Design Skill is consequently a review aid, not a replacement for a platform-native component and testing strategy. The repository is not archived, and its last push was on 2026-10-02, so it is not stale under the maintenance rule used for this review. There are no GitHub releases, and the README provides an update command rather than release notes or a changelog. The license is listed as unknown, so organizations should verify licensing before distributing the skill or incorporating its reference files into a product workflow. Maintenance cost is low in terms of commands, but the reference pages depend on the agent reading the repository files and on the team accepting the generated HIG summaries. ## Conclusion Developers building Apple-oriented or cross-platform applications should consider Apple Design Skill when they need source-linked design feedback expressed in their framework. It is not a substitute for testing real devices, operating systems, assistive technologies, or implementation behavior. Before adoption, verify that its agent installation path, `SKILL.md`, routing table, and selected guideline files are available in the working environment, then confirm that its findings can be traced back to the documented HIG sources. ## FAQ ### What is Apple Design Skill used for? It is an agent skill for reviewing mobile and desktop interfaces against Apple's Human Interface Guidelines. The documented output includes what was found, why it matters with a guideline citation, and a fix expressed for frameworks such as Flutter, Tauri, Electron, or React Native. ### How do I install Apple Design Skill? The README documents `npx skills add dickwu/apple-design-skill` for supported agents. It also documents agent-specific installation, user-wide installation, and manual cloning for Claude Code. ### Does Apple Design Skill check accessibility and iPhone Duo layouts? According to the README, accessibility is a blocking review area covering text scaling, contrast, control sizes, screen readers, keyboard access, motion, and transparency. iPhone Duo mode covers the outer and inner displays, a partial fold, Split View, size classes, system bar placement, and camera or fold clearance. ## Sources - [dickwu/apple-design-skill on GitHub](https://github.com/dickwu/apple-design-skill) - [Issues](https://github.com/dickwu/apple-design-skill/issues) - [README](https://github.com/dickwu/apple-design-skill/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dickwu-apple-design-skill