There is potentially one detail I jumped over that is relevant — are you expecting clients of your library to build from source, or to consume a pre-compiled library? I had assumed it was a pre-compiled library based on the .a file mention. I think that's accurate, but it would be good to confirm that. If the library is intended to be a pre-compiled asset, then what you'd deliver to the client is an XCFramework. This is meant to be a single container that has everything a library client needs — copies of a built binary for each platform and simulator your library supports, plus the header files. While you can hand your clients the XCFramework so they can drag-and-drop it in their Xcode project, one nice vehicle you can use for distribution is a Swift package, which will point to a compressed (zipped) copy of the XCFramework, along with a checksum for verifying its integrity. This way, it's easy to ship updates of the library to your clients. Distributing binary frameworks as Swift packages has the de
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags: