Fail-able authenticated packages

What is an authenticated package?

In Swift 5.8, SPM allows you to include just about any package you want. This may be a package from a third party like Firebase or a package you created. Many packages are simply previous Cocoapods migrated to Swift Packages. Authenticated Packages are these same packages, but requiring the user to authenticate before they can be downloaded.

How are authenticated packages commenlly used currently?

Authenticated packages are rare and commonly used only in enterprise or private projects where resources are shared within a private group. This is limited as you must always have the key for the project and can never share the package with an optional third party or use it in a project that may or may not contain the package (i.e. you have one app version that uses packages 1, 2, and 3, but another version uses 1, 2, and 4).

Why Allow Fail-able authenticated packages?

Sharing private resources is required for many companies to work. From third party contractors to multi-departmental resource sharing, in these scenarios, we do not always want to share all aspects of our internal code. Currently, SPM does not allow this, requiring the use of Cocoapods or other third party software to create and share resources.

How would this be used?

When resolving the package graph, SPM would instead of presenting an error and stopping, would present a warning (or popup) for the same package(s). This warning would give the chance to update their credentials for the package(s). After updating, the package graph would either resume or resolve the graph again. Authenticated packages would be retained as optional libraries by default, while giving the library author the option to make it a required library (resulting in a hard fail if authentication fails, giving the same or a similar error as now).

Since Xcode already knows how to manage optional libraries, this would not require any additional updates to Xcode itself to manage these changes. No additional changes to SPM would be required outside error handling.

Summary

The goal is to remove reliance off of Cocoapods and others, and move to SPM for enterprise packages that require authenticated resources for some employees, but not all, for shared projects and packages.

Feedback welcome.

3 Likes