February 1, 2024
In this technical article we go into the depths and best practices around
- Working efficiently on a commercial SDK in a larger team
- How to compile and distribute your iOS SDK as a pre-compiled xcframework automatically
How to build and debug an iOS SDK?
At ContextSDK we have our whole iOS Swift codebase in a single local CocoaPod. This allows us to iterate quickly as a team, and have our SDK configuration defined in clean code in version control, instead of some plist Xcode settings.
During development, we want to easily edit our codebase, run the Demo app, and debug using Xcode. To do that, our Demo app has a simple Podfile referencing our local CocoaPod:
pod install will then nicely setup your Xcode workspace, ready to run the local ContextSDK codebase:
Editing a ContextSDK source file (e.g.
Context.swift) will then immediately be accessible and used by Xcode during the next compile. This makes development of SDKs extremely easy & efficient.How to compile a CocoaPod into a static binary (xcframework)?The requirement for commercial SDKs is often that its source code isn’t accessible to its user. To do that, you need to pre-compile your SDK into an .xcframework static binary, which can then be used by your customers.
Thanks to the excellent cocoapods-pack project, started by Dimitris by Square, it’s easily possible to compile your SDK for distribution to your customers. After installing the gem, you can use the following command:
pod pack ../ContextSDK.podspec https://contextsdk.com --skip-validation
Now open up the folder
./zips/ContextSDK/3.2.0/ and you will see a freshly prepared
ContextSDK.zip. You can't distribute that zip file right-away, as it contains an additional subfolder called
ios`, which would break the distribution through CocoaPods when we tested it.
As part of our deployment pipeline, we run the following Ruby commands to remove the
ios folder, and re-zip the file:
ContextSDK.zip is now ready for distribution. If you unzip that file, you’ll see the ContextSDK.xcframework
contained directly, which is what your users will add to their Xcode project, and will be picked up by CocoaPods.
How to distribute your SDK?
1) Manual Installation
There are no extra steps needed: the ZIP file you created above is everything that’s needed. Now you can provide the following instructions to your users:
- Download the latest release: [URL to your ZIP file]
- Drag & Drop the
ContextSDK.xcframeworkfolder into the Xcode file list
- Go to your project settings, scroll down to
Frameworks, Libraries, and Embedded Content, add
ContextSDK.xcframework, and select
Embed & Sign
2) Through CocoaPods
Distributing your pre-compiled .xcframework file through CocoaPods requires some extra steps.
You need a second
ContextSDK.podspec file, that will be available to the public. That podspec will only point to your pre-compiled binary, instead of your source code, therefore it’s safe to distribute to the public.
Make both your podspec, and your ZIP file available to the public. Once complete, you can provide the following instructions to your users:
- Add the following dependency to your
pod 'ContextSDK', podspec: '[URL to your public .podspec]'
3) Through Swift Package Manager (SPM)
Create a new git repo (we called it
context-sdk-releases), which will contain all your historic and current releases, as well as a newly created
You can use the same zip file we’ve created with SPM as well. Additionally, you’ll need to make use of git tags for releases, so that your customers can pinpoint a specific release. You can either make this repo public, or you’ll need to manually grant read permission to everyone who wants to use SPM.
To your users, you can provide the following instructions:
As we were building out our automated SDK distribution, we noticed there aren’t a lot of guides online around how to best develop, build and distribute your SDK as a pre-compiled binary, so we hope this article helps you to get started.