Binary targets and trendy Swift packages
Swift 5.6 launched various new options for the Swift Bundle Supervisor infrastructure. We had been already capable of outline binary targets, and use xcframeworks as binary goal dependencies for our apps. They work nice in case you are concentrating on Apple platforms, however sadly the xcframework format shouldn’t be suitable with Linux distributions, to not point out the Home windows working system.
That is the place artifact bundles may also help. If you’re growing apps for a number of platforms now you can create an artifact bundle, place all of the suitable variants into this new construction and SPM can select the appropriate one based mostly in your structure. 💪
Earlier than we truly dive in to our important matter, I’ll rapidly present you how one can create an xcframework and ship it as a binary goal by way of SPM.
XCFrameworks and SPM
Earlier than the introduction of the brand new format we needed to fiddle with FAT binaries to help a number of platforms. I’ve a deep dive article about frameworks and instruments that you should use to assemble a FAT binary, however I not advocate it since XCFrameworks are right here to remain. 🔨
With a purpose to construct an XCFramework, it’s important to use Xcode and a course of could be very easy. You simply have to pick the Framework kind below the iOS tab while you create a brand new challenge. Be at liberty to call it, add your Swift supply code and that is it.
You’ll be able to construct this challenge utilizing the command line for a number of platforms by way of the next script.
# construct for iOS units
xcodebuild archive
-scheme MySDK
-sdk iphoneos
-archivePath "construct/ios_devices.xcarchive"
BUILD_LIBRARY_FOR_DISTRIBUTION=YES
SKIP_INSTALL=NO
# construct for iOS simulators
xcodebuild archive
-scheme MySDK
-sdk iphonesimulator
-archivePath "construct/ios_simulators.xcarchive"
BUILD_LIBRARY_FOR_DISTRIBUTION=YES
SKIP_INSTALL=NO
# construct for macOS units
xcodebuild archive
-sdk macosx MACOSX_DEPLOYMENT_TARGET=11.0
-arch x86_64 -arch arm64
BUILD_LIBRARY_FOR_DISTRIBUTION=YES
-scheme "MySDK"
-archivePath "construct/macos_devices.xcarchive" SKIP_INSTALL=NO
# mix the slices and create the xcframework file
xcodebuild -create-xcframework
-framework construct/ios_devices.xcarchive/Merchandise/Library/Frameworks/MySDK.framework
-framework construct/ios_simulators.xcarchive/Merchandise/Library/Frameworks/MySDK.framework
-framework construct/macos_devices.xcarchive/Merchandise/Library/Frameworks/MySDK.framework
-output MySDK.xcframework
You’ll be able to even construct variations for Catalyst and different working methods, if you perform a little search you may simply work out the required parameters and configuration. Lengthy story brief, it’s extremely simple to create an xcframework output together with all sort of platform slices for particular units. 😊
Now if you wish to use this XCFramework, you may merely drag and drop it to your Xcode challenge and it ought to work with out additional points (if it comprises the mandatory slices). Alternatively you should use Swift package deal supervisor and create a binary goal an hook up your exterior framework bundle by way of SPM. That is how a quite simple configuration file seems to be like.
import PackageDescription
let package deal = Bundle(
identify: "MySDK",
merchandise: [
.library(name: "MySDK", targets: ["MySDK"]),
],
dependencies: [
],
targets: [
.binaryTarget(name: "MySDK", path: "./MySDK.xcframework")
]
)In your challenge you should use the library product as a regular dependency, and the underlying binary goal will maintain importing the mandatory header recordsdata and linking the precise library. The one downside with this strategy is that it’s macOS (or to be much more exact Apple OS solely).
Say whats up to artifact bundles for Swift PM
All proper, so XCFrameworks cannot be used below Linux, however individuals like to write down command line scripts in Swift and use them for server facet tasks. In some circumstances these scripts (or plugins), want to name exterior scripts that aren’t put in on the system by default. That is the place artifact bundles may also help, as a result of it makes attainable to ship a number of variations of the identical executable binary file. 🤔
Artifact bundles aren’t a substitute for xcframeworks, however extra like an addition, or enchancment because the proposal title signifies this, for the Swift package deal supervisor plugin structure. They permit us to ship precompiled binary recordsdata for a number of platforms, this manner plugin authors do not need to compile these instruments from supply and the plugin execution time will be closely lowered.
There’s a nice weblog submit about wrapping the SwiftLint executable in an artifact bundle, so I do not actually wish to get into the small print this time, as a result of it is fairly simple. The proposal itself helps rather a lot to know the essential setup, additionally the older binary dependencies proposal comprises some associated information good job Swift group. 👍
I might like to offer an honorable point out to Karim Alweheshy, who’s actively working with the brand new Swift package deal supervisor plugin infrastructure, he has an incredible repository on GitHub that demos artifact bundles so please have a look if in case you have time. 🙏
Anyway, I’ll present you how one can wrap an executable into an artifact bundle. At the moment there is not any solution to wrap libraries into artifact bundles, that is going to be added afterward.
# create a easy whats up world executable challenge
mkdir MyApp
cd $_
swift package deal init --type=executable
# construct the challenge utilizing launch config
swift construct -c launch
# copy the binary
cp $(swift construct --show-bin-path -c launch)/MyApp ./myapp
# init a brand new instance challenge
mkdir MyPluginExample
cd $_
swift package deal init
mkdir myapp.artifactbundle
cd $_
mkdir myapp-1.0.0-macos
cd $_
mkdir bin
Now the file construction is prepared, we should always create a brand new information.json file below the artifactbundle listing with the next contents. This can describe your bundle with the accessible binary variants, you may check out the proposals for the accessible triplets variations.
{
"schemaVersion": "1.0",
"artifacts": {
"myapp": {
"model": "1.0.0",
"kind": "executable",
"variants": [
{
"path": "myapp-1.0.0-macos/bin/myapp",
"supportedTriples": ["x86_64-apple-macosx", "arm64-apple-macosx"]
}
]
}
}
}
Copy the myapp binary below the myapp-1.0.0-macos/bin/myapp location, and eventually we will make a quite simple command plugin to take advangate of this newly added instrument.
import PackagePlugin
import Basis
@important
struct MyDistCommandPlugin: CommandPlugin {
func performCommand(context: PluginContext, arguments: [String]) throws {
let myAppTool = attempt context.instrument(named: "myapp")
let myAppToolURL = URL(fileURLWithPath: myAppTool.path.string)
let course of = attempt Course of.run(myAppToolURL, arguments: [])
course of.waitUntilExit()
}
}Watch out with the paths and file names, I used lowercase letters for every thing on this instance, I like to recommend to observe this sample while you create your artifact bundle binaries.
swift package deal plugin --list
# ‘whats up’ (plugin ‘HelloCommand’ in package deal ‘MyPluginExample’)
swift package deal whats up
# Whats up, world!
That is it, now we have got a working artifact bundle with a customized made executable accessible for macOS. We will use this artifact bundle as a dependency for a plugin and run the instrument by utilizing the plugin APIs. I might actually love to have the ability to cross compile Swift libraries and executable recordsdata afterward, this might make the event / deployment workflow a bit less difficult. Anyway, artifact bundles are a pleasant little addition, I actually like the best way you may ship binaries for a number of platforms and I hope that we’re going to have the ability to share libraries as effectively similarly. 😊
