claude-code-apple-skills: A 164-Skill Library for Claude Code on Apple Platforms

The gap this fills: Apple platform knowledge as prompt context

Claude Code ships with no opinion about SwiftUI data flow, App Store rejection patterns or Instruments profiling. Left alone, an agent asked to add a paywall will produce something plausible and generic. This repository supplies 164 skill files that act as retrievable instructions for those tasks, grouped into 23 categories including 63 generators, 12 testing skills and 12 App Store skills. The target user is an indie Apple developer already running Claude Code who wants the assistant to reason from a written checklist rather than from model priors. It is not a linter, a build plugin or a package you add to a Swift target. Nothing here compiles. The repository is a directory of markdown skills plus a small set of scripts, and its only runtime is the agent reading them.

How the plugin routes 164 skills through 23 category entries

The mechanism is context budgeting. Installing the plugin surfaces the library as 23 category skills such as /apple-skills:generators and /apple-skills:testing. According to the README, each category skill routes to its sub-skills on demand, so only 23 short descriptions sit in context at any time. That is the design decision worth noting: dumping 164 skill descriptions into every conversation would consume a large share of the context window before the user types anything. The trade-off is an extra routing hop. The agent must first pick a category, then pick a sub-skill, which adds a step where a misclassification can send it into the wrong generator. Manual installs bypass routing entirely: copying skills/ into .claude/skills/ puts every skill in front of the agent, which is simpler to reason about but heavier. The repository also lists three sibling projects forming a four-layer stack: SwiftShip for 53 /apple:* commands, indie-app-autopilot for 7 agents, and asc-metadata-mcp for 65+ MCP tools against the App Store Connect API. This repository is the knowledge layer only; the other three are separate installs.

Installing it: two commands or one copy

The recommended path runs inside Claude Code. First add the marketplace, then install the plugin:

/plugin marketplace add rshankras/claude-code-apple-skills /plugin install apple-skills@indie-apple-stack

Updates come from /plugin marketplace update indie-apple-stack. The README states plainly that plugin installs track main with no version pinning. The manual path avoids that:

git clone https://github.com/rshankras/claude-code-apple-skills.git cp -r claude-code-apple-skills/skills your-project/.claude/skills/

Or globally, into ~/.claude/skills/. For a frozen snapshot, the README points at annotated era tags marking WWDC content boundaries, for example git clone --branch wwdc25-era-final, followed by the same manual copy. There are no config keys to set and no environment variables. The only repository-supplied script mentioned in the material is scripts/check-counts.sh, which CI uses to enforce the skill count. Because the skills are plain files under a directory, removal is a directory delete, which is a real advantage over tools that install hooks or daemons.

Where the library is thin, and where it will mislead you

Coverage is uneven, and the category table makes that visible. Security has one skill, covering privacy manifests and required reason APIs. Performance has two: Instruments profiling and SwiftUI debugging. Core ML has one, watchOS has one, SwiftData has one, MapKit has one, Foundation has one. Meanwhile generators hold 63 skills. That ratio suggests the library is optimized for scaffolding new code, not for auditing or tuning existing apps. A developer joining a large legacy codebase to profile a memory regression will find two skills; a developer starting a new app will find sixty-three. The second limitation is freshness. Skills describing Tahoe APIs, Liquid Glass, Swift 6.2, InlineArray and Charts 3D are tied to specific OS and toolchain versions. The README's use of era tags implies the maintainer expects content to age at each WWDC boundary, but the material gives no compatibility matrix stating which skill targets which Xcode or Swift version. Verify that yourself before trusting a generator. Third, generated code is unverified. The repository does not claim to test its output, and nothing in the material indicates the generators were compiled against a sample project.

Compared with writing your own CLAUDE.md and skill files

The obvious alternative is hand-rolling project instructions: a CLAUDE.md with your architecture rules, plus a handful of skill files for the two or three things you do repeatedly. That approach wins on precision. Your own file can state which networking layer you use, which minimum deployment target applies, and which patterns are banned, none of which a general library can know. It loses on breadth. Writing 63 generator specifications covering logging setup, analytics, auth flows, paywalls, background processing, app extensions and data export is weeks of work, and the Apple-specific detail (privacy manifests, required reason APIs, HIG compliance, App Store rejection patterns) requires research most teams will not do. The practical difference is specificity versus coverage. A second alternative is to skip agent skills entirely and rely on Xcode templates plus SwiftLint, which gives deterministic, versioned output at the cost of doing the design thinking yourself. This library sits between those poles: more structured than an empty prompt, less deterministic than a template.

Maintenance cost, licence and the pinning question

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement, but it applies to the skill text, not to whatever code an agent generates from it; the output carries whatever provenance and licensing your own project requires. This is a description of the licence terms, not legal advice. On maintenance, the repository is not archived and the last push shown is 2026-07-24. There are no retrieved releases, so there is no changelog of versioned artifacts to diff against; CHANGELOG.md is referenced for era tags but the material does not reproduce its contents. The upgrade path for plugin users is implicit: because installs track main, every update pulls whatever landed since. That means an upstream edit to a generator skill can change the code your agent writes between two sessions with no version boundary in between. If that matters, use the manual copy plus an era tag, and re-copy deliberately. The cost of that choice is that you stop receiving fixes.

A concrete adoption test before you commit

Pick the task you actually repeat most, then read the matching skill before installing anything. If you ship paywalls, open the paywall-generator skill in the generators directory and check whether its assumptions match your StoreKit version and your subscription model. If you spend your time on App Store metadata, read one of the 12 app-store skills and see whether the keyword and description guidance reflects current App Store Connect fields or an older layout. Then run scripts/check-counts.sh to see what the CI gate enforces; the README notes that single-skill categories count their category file and other index files are not counted, which tells you the count is a curated invariant rather than a raw file tally. If the skill you read matches your stack, the install is two commands and the rollback is deleting a directory. If it does not match, no amount of additional skills will fix the first one.

Editorial conclusion

Adopt it if you already work inside Claude Code on an Apple platform project and want a structured prompt library for code review, generators and App Store metadata rather than assembling your own. Skip it if you build outside Claude Code, since the skills have no meaning to another agent runtime, or if you need reproducible tooling: plugin installs track main with no version pinning. Before committing, read one generator skill end to end, check whether its output matches your deployment target and Swift version, and run scripts/check-counts.sh locally to see what the CI check actually verifies.

Official sources

1. Issues
2. License: MIT
3. README
4. rshankras/claude-code-apple-skills on GitHub