# LicensePlist: generating iOS acknowledgements from Carthage, CocoaPods and SwiftPM

> LicensePlist is a Swift command-line tool that collects dependency licences into plists for an iOS app's Settings.bundle. It is useful when your licences come from several package managers at once, and awkward when every dependency lives in one manifest.

**mono0926/LicensePlist** — A license list generator of all your dependencies for iOS applications

- Repository: https://github.com/mono0926/LicensePlist
- Website: https://www.slideshare.net/mono0926/licenseplist-a-license-list-generator-of-all-your-dependencies-for-ios-applications
- Stars: 2,533 · Forks: 157
- Language: Swift
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/mono0926-licenseplist

## The multi-manager licence problem LicensePlist targets

An iOS app that has been alive for a few years rarely has one dependency graph. A typical project carries a Cartfile, a Podfile, a Package.resolved, and a handful of libraries someone dropped into the repository by hand. Each of those sources knows its own licence, and none of them knows about the others. The App Store expects an acknowledgements screen, and the Settings app is where iOS users normally find it.

LicensePlist is aimed at the person who owns that screen. The README describes it as a command-line tool that generates a plist of all dependencies, including files added manually, or ones added with Carthage or CocoaPods, and states that the licences then appear in the Settings app. The unit of work is the app project directory, not a single manifest, which is why the tool reads several package manager files in one pass.

This matters most for teams shipping a binary to the App Store, where a licence list is part of the release surface. It matters less for a library author who never ships a Settings.bundle.

## How LicensePlist resolves each dependency source

The mechanism is a set of collectors, one per input format, each with a default path that can be overridden. Carthage is read from Cartfile, Mint from Mintfile, Nest from nestfile.yaml, CocoaPods from the Pods directory, and Swift Package Manager from Package.swift. For SwiftPM the README says LicensePlist tries to find YourProjectName.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved and YourProjectName.xcworkspace/xcshareddata/swiftpm/Package.resolved, then uses the newer one. That detail is worth knowing because the resolved file, not Package.swift, is what pins real versions.

There is also a mise collector. The README states that --mise-path defaults to mise.toml and that LicensePlist collects GitHub-hosted tools declared in mise's [tools] table through the github:, ubi: and aqua: backends, with examples such as "github:SwiftGen/SwiftGen" = "6.6.3". Other backends and plain tool names such as node are ignored because they do not map to a GitHub owner and repository. That is a narrow but honest scope: only entries that can be turned into an owner/repo pair are usable.

Licence text itself comes from the GitHub API, which is why the README warns that API limit errors occur and offers --github-token or the LICENSE_PLIST_GITHUB_TOKEN environment variable as the fix, with the repo scope needed on the token. The alternative to network calls is --package-sources-path, which points at a directory of cloned Swift package sources; the README ties that directory to the -clonedSourcePackagesDirPath parameter of xcodebuild. Either way, the output is a directory of plist files under a prefix, by default com.mono0926.LicensePlist.Output.

## Installing LicensePlist and generating a first Settings.bundle

The README carries an explicit warning that Swift Package Manager is not supported, so the SPM entry in Xcode is not the installation path. CocoaPods and Homebrew are both marked as recommended. With Homebrew the command is a single line:

```bash
brew install licenseplist
```

CocoaPods installs the tool alongside your pods, with the README noting the binary lands at ${PODS_ROOT}/LicensePlist/license-plist. Mint users run it through the Mintfile. There is also a release binary and a one-line installer:

```bash
curl -fsSL https://raw.githubusercontent.com/mono0926/LicensePlist/master/install.sh | sh
```

Building from source goes through the Makefile, which builds in release configuration and copies the binary into PREFIX/bin, defaulting to /usr/local:

```bash
git clone https://github.com/mono0926/LicensePlist.git
cd LicensePlist
make install
```

For a first real run, change into the directory that holds your Cartfile or Pods directory and execute the tool with no arguments. The README's usage steps say the com.mono0926.LicensePlist.Output directory will be generated, and that you then move those files into your app's Settings.bundle. Rather than moving files by hand, the README recommends pointing the output straight at the bundle:

```bash
license-plist --output-path YOUR_PRODUCT_DIR/Settings.bundle
```

What you should see afterwards is a Settings.bundle containing per-library plists such as APIKit.plist and Alamofire.plist inside a com.mono0926.LicensePlist directory, plus a com.mono0926.LicensePlist.plist at the bundle root. The README notes the key wiring step: Root.plist must specify com.mono0926.LicensePlist as the licence list file. A sample Settings.bundle is linked from the README. Run license-plist --help to see the full option set.

## Where LicensePlist stops being the right tool

The GitHub API dependency is the sharpest edge. Every licence that is not read from cloned sources can require a network call, and the README acknowledges that API limit errors happen and that a token with repo scope is the workaround. On a shared CI runner without a token, a build that suddenly resolves a new dependency can fail on rate limiting rather than on anything in your code. That is a release-pipeline failure mode, not a cosmetic one.

The tool also only produces plists for an iOS Settings.bundle. If your acknowledgements screen is a view controller rendering a text file, the generated plist format is the wrong output, even though --html-path exists for an HTML acknowledgements file. And the SPM warning cuts both ways: a project that has migrated entirely to Swift Package Manager still installs LicensePlist through Homebrew, CocoaPods, Mint or a release binary, because the README states SPM is not a supported installation route.

Finally, the manual-libraries path is a YAML config file, default license_plist.yml, where you declare GitHub libraries introduced by hand and libraries to exclude. Anything not discoverable by a collector and not listed there simply will not appear in the output.

## LicensePlist compared with AcknowList

AcknowList is the other name that comes up in searches around this problem, and the difference is in where the licence data is assembled. AcknowList is a runtime library: the acknowledgements are bundled with the app and rendered by its own view controller, so the list is data you ship rather than a screen the system draws.

LicensePlist takes the opposite route. It is a build-time generator whose output is plist files placed in Settings.bundle, and iOS itself renders the list inside the Settings app. The README's screenshots show exactly that shape: a root settings row, a licence list, and a licence detail page.

That distinction decides the choice. If you want the acknowledgements inside your own UI, with your own styling and navigation, a runtime component fits. If you want the system Settings screen to carry them and you want the content produced by a CLI that can run in CI, LicensePlist is the closer match. They are not mutually exclusive, but running both means maintaining two acknowledgement surfaces.

## Maintenance, licence and upgrade cost

The repository is not archived, and its last push was on 2026-09-09. Releases 3.28.1 and 3.28.2 both landed on 2026-09-09, with 3.28.0 on 2026-07-28, so the release cadence at that point was active rather than dormant. The project is written in Swift, and the README badges reference Swift 5.3 and a Swift Package Manager compatible build.

LicensePlist itself is MIT licensed, which places few obligations on how you use the tool. That is separate from the licences of the dependencies it collects, which are the ones your app has to satisfy; LicensePlist only reproduces their text into plists and does not evaluate compatibility. Nothing here is legal advice, and the tool does not attempt to be.

Upgrade cost is mostly a matter of install channel. Homebrew and Mint users get a new version by upgrading the formula or the Mintfile entry. CocoaPods users get it through pod install, and the README notes the binary path inside PODS_ROOT, which means a pod update can change the tool version your script invokes. If you pin the version, pin it in whichever of those channels you actually use, because the CLI flags you rely on are tied to the release you installed.

## Conclusion

Adopt LicensePlist if your iOS app pulls dependencies from more than one package manager and you want the acknowledgements to live in Settings.bundle without hand-editing plist files. Skip it if every dependency resolves through a single Package.resolved and a generated markdown file is enough, because the tool exists to merge heterogeneous sources. Before wiring it into CI, verify three things: the exact spelling of the output directory your target expects, whether your run needs --github-token or LICENSE_PLIST_GITHUB_TOKEN to stay under the GitHub API limit, and whether the licence text you need is reachable from the cloned sources so you can use --package-sources-path instead of network calls.

## FAQ

### How do I install LicensePlist on macOS?

The README marks Homebrew as recommended, with brew install licenseplist, and also lists CocoaPods, Mint, a release binary, and a one-line install script. It explicitly warns that Swift Package Manager is not supported as an installation route.

### Does LicensePlist support Swift Package Manager dependencies?

It reads SwiftPM dependencies from Package.resolved, looking in YourProjectName.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved and the workspace equivalent, and using the newer one. The README's installation warning about SPM concerns installing LicensePlist itself, not collecting SwiftPM dependencies.

### Why does LicensePlist hit GitHub API rate limits?

The README states that LicensePlist uses the GitHub API and that API limit errors sometimes occur. It suggests passing --github-token, with repo scope, or setting the LICENSE_PLIST_GITHUB_TOKEN environment variable, and notes that --package-sources-path lets the tool use cloned Swift package sources instead.

## Sources

- [License: MIT](https://github.com/mono0926/LicensePlist/blob/main/LICENSE)
- [mono0926/LicensePlist on GitHub](https://github.com/mono0926/LicensePlist)
- [Project website](https://www.slideshare.net/mono0926/licenseplist-a-license-list-generator-of-all-your-dependencies-for-ios-applications)
- [README](https://github.com/mono0926/LicensePlist/blob/main/README.md)
- [Releases](https://github.com/mono0926/LicensePlist/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mono0926-licenseplist