# swift-ios-skills and the licence that makes it a non-commercial tool > This repository is 86 self-contained instruction files for coding agents working on iOS 26 and Swift 6.3, installable through a skills CLI or a plugin marketplace, and the one thing an adopter has to know before reading a line of it is that the licence is PolyForm Perimeter, a non-commercial grant, not the MIT the topic list's neighbours suggest. **dpearson2699/swift-ios-skills** — Agent Skills for iOS 26+, Swift 6.3, SwiftUI, and modern Apple frameworks - Repository: https://github.com/dpearson2699/swift-ios-skills - Website: https://skills.sh - Stars: 1,167 · Forks: 61 - Language: Python - License: NOASSERTION - Published: 2026-09-30 · Updated: 2026-09-30 · Language: en - Canonical page: https://hysenlabs.com/projects/dpearson2699-swift-ios-skills ## Eighty-six Markdown files that teach an agent current APIs The deliverable here is not a library and not a build tool. The repository contains 86 agent skills, which are instruction documents a coding agent loads into its context to guide how it writes code for a particular area, and the README describes them as optimised for iOS 26 and later with Swift 6.3 and modern Apple frameworks. The scope claim is specific and checkable. All code examples, patterns and guidance target the latest APIs, naming Liquid Glass, approachable concurrency, Foundation Models, StoreKit 2, SwiftData and async and await URLSession, and the README states there are no deprecated patterns. For a coding agent, that last part is the entire value. The failure mode of an AI writing Swift is not that it cannot write a view, it is that it writes the view the way it was written three years ago, with a deprecated API that still compiles and produces a warning nobody reads. So the value of a curated skill set is negative space as much as positive. A skill that says how to do something with a current API also implicitly says do not do it the other way, and for an agent that is the more useful half of the instruction. The skills are organised into ten categories in the table of contents: SwiftUI, core Swift, app experience frameworks, data and service frameworks, AI and machine learning, iOS engineering, hardware and device integration, platform integration, and gaming. That taxonomy is a reasonable map of what an iOS application actually touches, and the AI and machine learning category alongside Foundation Models in the scope claim tells you the set is tracking the platform as it ships rather than as it shipped. The most important structural property is stated plainly: every skill is self-contained, no skill depends on another, and you install only what you need. That single design decision removes the dependency-resolution problem that usually makes a large instruction set unusable, because there is nothing to resolve. ## PolyForm Perimeter, and why GitHub calls this licence unclassifiable The licence is the most important fact in this repository, and it is stated in the README badge and the LICENSE file rather than buried. The project is licensed under PolyForm Perimeter 1.0.0. GitHub could not classify it, which is why the repository's licence field reads as a custom licence rather than one of the familiar identifiers. PolyForm Perimeter is a source-available licence, not an open source one, and the distinction that matters is a single word: non-commercial. The grant of use extends to non-commercial users. It does not extend to commercial use. This is worth being precise about, because the practical consequences vary a lot depending on who you are. An individual building a personal app, a student, a researcher, or a hobbyist working on a side project is squarely inside the grant. A company building a commercial iOS product is not, and neither is a consultant doing paid work, even if the resulting code never ships. The line is on the user's status, not on the distribution of the output. That last point is the one that generates the most confusion. Non-commercial source-available licences are unusual in that the output is not automatically free of the restriction. A permissive licence like MIT places no conditions on what you do with the output. A non-commercial grant may leave the restriction attached to what you made with it, which is a question about your specific licence and your specific situation rather than something to guess at. The honest position is that the text is in the LICENSE file and it is worth reading before you rely on it, and that this article is not legal advice. The context makes the choice more explicable, if not more defensible. A set of eighty-six curated documents representing a substantial and ongoing investment of someone's time, tracking a platform that moves every year, is exactly the kind of work that commercial licences exist to protect. A volunteer writing specification-grade guidance for a rapidly moving framework has a reasonable interest in not having that work absorbed into a commercial product without recourse. The tension with the open standard the skills follow is real: the repository advertises compliance with the open Agent Skills standard and compatibility with a long list of coding agents, which pulls in an ecosystem that assumes permissive licensing, while shipping a non-commercial grant. For an evaluator, this is a dealbreaker question, not a preference. Everything else about the project can be assessed on merit, and the licence decides whether you are allowed to use it at all. ## Installation, and the context window problem behind the bundles There are several install paths and the README is clear about which one it recommends. The primary method is a skills CLI run through npx, and the plain interactive form opens a UI where you choose which skills to install and which agents to install them for: ```sh npx skills add dpearson2699/swift-ios-skills ``` You can skip the UI and take everything for any coding agent with an all flag, or name individual skills with a repeated skill flag. There are also two maintenance commands, one to check for updates to installed skills and one to update them, and the README notes these apply after installing through the CLI rather than through the plugin marketplace. For Claude Code there is a second path through a plugin marketplace, where adding the marketplace is a one-time step and then either all skills or a themed bundle can be installed. That last distinction contains the most practically important sentence in the install section. The README explains that bundles limit how many skills load into the context window, and that if you want everything you should use the all bundle rather than installing multiple bundles. The context window is the binding constraint here and it is worth understanding why. A coding agent's context is a fixed budget shared between the conversation, the code it has read, and its instructions. Eighty-six skills is a lot of text, and if they all load on every request they compete with the actual work for the same budget, and the agent's effective attention on your code degrades. The bundle mechanism is the mitigation: install the SwiftUI bundle and the data framework bundle, and only those inform the agent. The all bundle exists for the case where you genuinely want the whole set resident, which is usually a project-wide standard rather than a single feature. This also explains why the self-contained property matters so much. A skill that referenced another would force the whole dependency closure to load, which would defeat the bundling. Making each skill independent is what makes selective installation a real optimisation rather than a nominal one. The compatibility claim is broad: Claude Code, OpenAI Codex, Cursor, GitHub Copilot, and forty or more other agents, following the open Agent Skills standard, with the project's own homepage at a skills directory. The breadth comes from adopting an open standard rather than a proprietary format, and the standard is the right choice for something meant to be installed into tools the author does not control. ## The iOS 26 and Swift 6.3 floor, and what it means for anyone not on it The version targets are stated in the title, the badges and the scope claim, and they are the project's single most consequential constraint after the licence. The skills target iOS 26 and later with Swift 6.3, and the platform badge covers iOS, iPadOS and macOS. A developer on iOS 18 or on Swift 5 cannot use this set as written, because the guidance is explicitly for the current APIs and explicitly free of deprecated patterns. Those two properties are the same property. A skill that avoided deprecated APIs would be useless on an older platform, and a skill that supported older platforms would have to teach the deprecated ones. So this is a bet on a specific generation of the platform, and the bet has a cost that grows the longer you hold it. If your application's deployment target is the current iOS and you are starting new work, the set is well matched. If you maintain an application that must run on older systems, the guidance is actively wrong for the code paths that support them, and an agent following it will write code that fails to compile against your target. The README has a section on upgrading from version 2.x, which tells you the set has been through a major structural revision, and the release history is recent and frequent: v3.8.0 in July 2026, v3.9.0 two days later, v3.9.1 the same day as the last push. That cadence is what you want from a document set tracking a moving platform, and it is also a cost, because a fast-moving set means your agent's instructions change under you and a behaviour that worked last month may have been rewritten this month. The middle version, 3.x, is worth noting. A pre-1.0 project makes no stability promise, a 3.x project makes a compatibility promise within the major version, and this project is at 3.9.1 with a changelog maintained at the top level of the repository. For an instruction set, the changelog matters more than for a library, because the failure mode is not a runtime exception but an agent quietly producing different code after an update, and a changelog is how you notice that before it reaches a pull request. ## What the repository does not tell you about whether the guidance is right The top-level entries include two directories that are unusual for a repository of documentation, and neither is explained in the visible part of the README. There is an `evals` directory and a `tests` directory. For a project whose entire output is prose guidance for an AI, those two directories are the only evidence in the repository about whether the guidance is correct, and their presence says the author considers the question worth measuring rather than assuming. That is a stronger claim than most documentation projects of this kind make. A set of skills for coding agents can fail in at least three distinct ways, and only the first is obvious. It can be factually wrong, where a skill describes an API that does not exist or an initialiser with the wrong signature. It can be outdated, where the guidance was right when written and the platform has moved. And it can be ineffective, where the instructions are accurate but an agent following them produces worse code than one working from its own training, which is a possibility nobody outside measurement can rule out. A directory named evals is the standard name for the first two of those, tests for the third or for the mechanical checks. Neither is documented in the README text available here, so what they actually contain and how they are run is unknown, and that is the honest statement. The correct thing to do before relying on this set is to read them, and if they are substantive, to run them. The rest of the repository structure supports the packaging story. There is a `.claude-plugin` directory, which is the plugin marketplace definition the Claude Code install path uses, and a `.tessl-plugin` directory with a `tessl.json` alongside it, which corresponds to the tessl registry badge in the README. There is also a `.mcp.json`, so the project is configured to expose a Model Context Protocol server to the agent, and an `AGENTS.md` for instructions to agents working on the repository itself rather than using it. The `skills` directory is the payload, and the other three directories are the distribution channels. Four distribution mechanisms for one set of files is a lot of surface area to keep in sync, and it is a maintenance cost the author has taken on. It is also what makes the set installable in whichever tool you happen to use, which is the reason to accept the cost. ## Conclusion Adopt these skills if you are building an iOS 26 application for your own organisation and want the agent to target current APIs rather than deprecated patterns, installing only the skills you need rather than all eighty-six. Do not adopt them in a product you sell, because PolyForm Perimeter grants use only to non-commercial users, and confirm that reading against your own counsel before assuming an internal tool at a commercial company is covered. Verify first by installing one skill and reading its file end to end, confirming the licence text in the LICENSE file matches the badge, and checking the evals and tests directories, which are the only evidence in the repository about whether the guidance is measured rather than asserted. ## FAQ ### What is swift-ios-skills? It is a repository of 86 agent skills, which are self-contained instruction documents for coding agents working on iOS 26 and later with Swift 6.3. The guidance targets current APIs including Liquid Glass, StoreKit 2, SwiftData and Foundation Models, and the README states it contains no deprecated patterns. ### What licence is swift-ios-skills under, and can I use it commercially? It is licensed under PolyForm Perimeter 1.0.0, which GitHub could not classify. That is a non-commercial source-available grant rather than an open source one, so the grant of use extends to non-commercial users and does not extend to commercial use. Whether the restriction carries into your output is a question for the licence text and your own counsel. ### How do I install the skills? The recommended method is a skills CLI through npx. Running npx skills add dpearson2699/swift-ios-skills opens a UI to pick skills and agents, an all flag installs the full set, and repeated skill flags install named ones. For Claude Code there is also a plugin marketplace path with all-ios-skills and themed bundles. ### Why does the README warn about installing multiple bundles? Because bundles limit how many skills load into the context window. Installing several bundles competes with your code and conversation for the agent's fixed context budget, so the README says to use the all-ios-skills bundle if you want everything rather than combining multiple bundles. ### What iOS and Swift versions do these skills target? iOS 26 and later with Swift 6.3, across iOS, iPadOS and macOS, with no deprecated patterns. Guidance written this way is actively wrong for an application that must support older systems, since it will not contain the older API paths. ### How do I know the skills are correct rather than plausible? The repository contains evals and tests directories, which is the evidence that the guidance is measured rather than only asserted, but the visible README does not describe their contents or how to run them. Reading and running them is the check to do before relying on the set. ## Sources - [dpearson2699/swift-ios-skills on GitHub](https://github.com/dpearson2699/swift-ios-skills) - [Issues](https://github.com/dpearson2699/swift-ios-skills/issues) - [Project website](https://skills.sh) - [README](https://github.com/dpearson2699/swift-ios-skills/blob/main/README.md) - [Releases](https://github.com/dpearson2699/swift-ios-skills/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dpearson2699-swift-ios-skills