AcknowList puts your app's dependency licences on screen

A licence screen fed by the manifests your build already produces

AcknowList is an acknowledgements screen displaying a list of licences, for example from CocoaPods and Swift Package Manager dependencies. That is the entire scope, and it is a narrower and more useful scope than it sounds.

The problem it solves is a compliance chore that every app with dependencies has and most apps get wrong. The licences of the libraries you ship are legally required to be reproduced, and the usual approach is a hand written plist that lists them. It is correct on the day you write it and wrong the next time you add a dependency, and nobody notices until a review.

AcknowList removes the hand written step by reading the files your build tool already produces. The feature list says it can load acknowledgments from CocoaPods generated files, the Pods-###-acknowledgements.plist, and from Swift Package Manager files, Package.resolved. It can also fetch missing SPM licences from the GitHub API, which is what makes the Package.resolved route practical, because that file records versions and repository URLs but not the licence text.

The audience is an iOS or macOS developer with a shipping app and a compliance checklist. The library is written in Swift, the licence is MIT, the recent releases are 3.4.3 on 2026-06-22, 3.4.2 on 2026-04-18 and 3.4.1 on 2026-03-03, and the last push was on 2026-06-22.

The repository also carries an Examples/ directory with three separate example projects, one for each installation route: AcknowExampleCocoaPods, AcknowExampleManual and AcknowExampleSPM. That is a good sign for a library whose whole value is in the integration details.

CocoaPods: the plist goes in the target, it does not get copied

The CocoaPods installation is three steps, and the third one is where people get it wrong.

Add the pod to your Podfile:

1. Add `pod 'AcknowList'` to your `Podfile`.
2. Run `pod install`.

And then add the Pods-#target#-acknowledgements.plist file generated by CocoaPods to your main target. The instruction is specific about the mechanism: drag and drop the file from the Pods/Target Support Files/Pods-#target#/ folder to your Xcode project, and do not copy the file, leaving Copy items if needed unchecked.

That last clause is the whole trick. A file added to the target as a reference stays a reference at build time, and the library finds it in the app bundle at runtime, where it can read the acknowledgement entries. A file that is copied into the bundle becomes a second, independent copy, and the library's default lookup by bundle name will not find the one it needs, so the screen comes up empty or with the wrong content.

The library is helpful about the default behaviour, which the README describes as the controller trying to load acknowledgements from a CocoaPods plist file by guessing its location based on the bundle name, as well as from a Package.resolved file. So for the common case, with the plist added as a reference, the default initialiser finds the file without any path plumbing.

Swift Package Manager: Package.resolved has to be in the target too

The Swift Package Manager route has the same shape and the same trap.

AcknowList can be installed with the Swift Package Manager, which requires Xcode 12 for localized resources. The steps are to use the Add Packages command in the File menu, enter the repository URL, select the version, and then add the Package.resolved file generated by Xcode to your main target, again by dragging and dropping it into the Xcode project without copying it and with Copy items if needed unchecked.

The README is precise about where the file lives, and the location depends on the project type. For single Xcode projects the file is in the appName.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/ directory. For Xcode workspaces, for instance with CocoaPods, it is in the appName.xcworkspace/xcshareddata/swiftpm/ directory.

That distinction is worth internalising, because a project that uses both package managers has both of those paths, and the one that is not the project's actual workspace will be the wrong one.

The requirement of Xcode 12 for localized resources is also a deployment decision in disguise, since the library ships localized strings for 13 languages and the older resource layout needs a newer toolchain to be read correctly. The Examples/AcknowExampleSPM project in the repository is the place to look at the whole arrangement end to end.

Three initialisers, and the controller you push

Using the library is a view controller that you push onto a navigation controller, and the README gives three ways to create it.

The default one guesses the file locations:

let viewController = AcknowListViewController()
navigationController.pushViewController(viewController, animated: true)

If the file name does not follow the convention, you can name it:

let viewController = AcknowListViewController(fileNamed: "Pods-AcknowExample-acknowledgements")

Or you can pass a URL directly, which is what you do when the plist is somewhere else in the bundle:

let url = Bundle.main.url(forResource: "Pods-AcknowExample-acknowledgements", withExtension: "plist")
let viewController = AcknowListViewController(plistFileURL: url)

There is also a fourth route for the cases the manifests do not cover. If you want to include licences that are not part of a plist or a resolved file, you can create new Acknow instances and use them for the acknowledgements array of the controller:

let acknow = Acknow(title: "...", text: "...")
let viewController = AcknowListViewController(acknowledgements: [acknow])

That last one is what you use for a first party component that carries a licence of its own, or for a licence the GitHub API could not fetch. It is also the escape hatch that makes the library usable in a project whose dependency metadata is not in either standard file.

Header, footer, table style and subclassing

The customisation surface is small and mostly text.

The controller can display a header and a footer. By default they are loaded from the generated plist file, and you can also set the properties directly:

viewController.headerText = "We love open source software."
viewController.footerText = "Powered by CocoaPods and SPM"

The controller title is a localized value for acknowledgements, and the README points out that you might want to use that same localized value for the button that presents the controller:

button.setTitle(AcknowLocalization.localizedTitle(), for: .normal)

That is a small detail that shows the library was written for apps that ship in several languages, because a hard coded title in a localised app is a bug.

The table style is configurable too, since by default the controller uses the grouped table view style:

let viewController = AcknowListViewController(plistFileURL: url, style: .plain)

And for anything beyond that, the README says you can subclass its classes if you need to further customize the appearance or behavior.

The feature list also covers the presentation details that matter on a modern device: tappable links in the header, footer and acknowledgment text, removal of unnecessary line breaks from licences for better text wrapping, Dark Mode support, Dynamic Type support, storyboard support, and localisation in 13 languages.

Two interfaces with two different floors, and the CocoaPods tax

The platform table in the README is the part to read before you pick an installation route, because the two interfaces do not have the same minimum.

The UIKit interface supports iOS 9.0 and above, and tvOS 9.0 and above. The SwiftUI interface supports iOS 13.0 and above, tvOS 13.0 and above, visionOS 1.0 and above, watchOS 7.0 and above, and macOS 10.15 and above. watchOS and macOS are marked as not supported for the UIKit interface, which is the expected split, since the SwiftUI interface is what makes those platforms possible at all.

And then there is the warning. If you install AcknowList with CocoaPods or Swift Package Manager, it will require iOS 13 and tvOS 13. To support earlier versions, you are told to import the library manually and ignore the SwiftUI classes, or to use the Objective-C version, VTAcknowledgementsViewController, instead.

That is a real constraint rather than a technicality, and the reason is worth understanding. A package manager dependency is a binary or a resource bundle linked into the app, and if the package was built against a newer SDK or ships resources in the newer layout, the app cannot support the older OS. Importing the source manually into the project avoids the packaging problem, and ignoring the SwiftUI classes avoids the API availability problem, but it means copying source into your repository instead of taking a versioned dependency.

The Objective-C sibling is the other option the README points at, and it is maintained by the same author. The requirements are Xcode 12 and above, and the library is written in Swift 5, with the podspec and two Package.swift manifests, one for Swift 5.10 and a newer one, in the repository root.

Editorial conclusion

Adopt AcknowList if you ship an iOS or macOS app with third party dependencies and you need a licence acknowledgements screen that reads the dependency manifests you already generate, rather than a hand maintained list that drifts. Do not adopt it if your app has no third party dependencies, since the whole library exists to render that list, and note the platform split, where the UIKit interface supports iOS and tvOS from version 9 while the SwiftUI interface needs iOS 13, tvOS 13, visionOS 1, watchOS 7 and macOS 10.15. Before you add the dependency, check whether installing through CocoaPods or Swift Package Manager raises your deployment target, because the README says those routes require iOS 13 and tvOS 13 and that supporting earlier versions means importing the library manually and ignoring the SwiftUI classes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vtourraine/AcknowList on GitHub