Including Swift Package deal Supervisor Assist – Half 1

Spread the love

As of Xcode 12, Apple has matured Swift Package deal Manger to a level the place it is smart so as to add assist for Swift packages to your libraries. There are nonetheless a number of stumbling stones on the trail which don’t have any apparent resolution. So I determine, I’d share with you ways I bought round them after I just lately added SPM assist to DTCoreText, DTFoundation and Kvitto.

Earlier than SwiftPM, my basic method for a library can be to have all library code in a `Core` subfolder, with a `Supply` folder containing code which will get compiled and a Sources folder for all types of assets, like for instance asset catalogs or XIB recordsdata. 

A Little bit of Historical past

For the primary 7 iOS variations the product of this product might solely be a static library, Apple solely launched the flexibility to create dynamic frameworks for Goal-C as of iOS 8. With Swift it was the opposite approach round: you would solely have dynamic frameworks with Swift code. For the primary 4 variations of Swift the ABI (Utility Binary Interface) was an excessive amount of in flux to permit a statically linked product. With Swift 5, in 2019, we lastly bought the required stability and thus Xcode gained the flexibility to supply static libraries containing Swift code. That is additionally the primary motive why Xcode all the time added a bunch of dylibs to your apps, containing Swift wrappers to all of the frameworks your app may be interfacing. These dynamic libraries are the third type of libraries we now have encountered to date.

Oh boy, I bear in mind all of the hackery we needed to do to supply a „pretend“ framework that was primarily a fats static library (with slices for all supported processors) and all public headers. We’d that in order that anyone utilizing our library might drop it simply into their challenge and have all uncovered interfaces be seen. In Goal-C you would wish to have the header recordsdata obtainable for public features and lessons contained within the library. These `.framework` bundles supplied a pleasant encapsulation of that, in order that it was nearly like dealing with a single bundle including a third-party framework to your app.

Dynamic frameworks – in actual life, on gadget – really don’t include any headers any extra as these grow to be ineffective after compiling. The primary advantage of first-party dynamic frameworks is that Apple can have their APIs and code shared between all apps put in on the gadget. The one and solely UIKit framework – put in as a part of iOS – is being accessed by and dynamically linked to all put in iOS apps. Solely a single occasion is current in RAM at any time. Customized frameworks can’t be shared between a number of apps because of all apps being contained in their very own little sandbox. Each iOS app containing DTCoreText for instance has to have its distinctive copy of it inside its app bundle. If an app has an excessive amount of third-party frameworks that strategy of loading all frameworks into reminiscence and dynamically linking can noticeably decelerate app launch.

Swift By no means Had Headers

With the improvements introduced with Swift additionally added the idea of modules to Xcode. The Swift Programming Language Web site presents this definition of modules.

A module is a single unit of code distribution—a framework or utility that’s constructed and shipped as a single unit and that may be imported by one other module with Swift’s import key phrase. Every construct goal (corresponding to an app bundle or framework) in Xcode is handled as a separate module in Swift.

If you import a module in your code, then Xcode in some way magically is aware of all concerning the public interfaces contained in it, with out ever having to have a separate header file. I don’t know the way precisely that works, however I’m glad that it does!

It was the issue of discovering and integrating third-party libraries into your codebase, that Cocoapods was invented to resolve. The primary public launch of it was nearly precisely 9 years in the past, in September 2011. With the default settings – not utilizing frameworks – Cocoapods would compile the third-party code and merge it with your individual, leading to a single monolithic app binary. And naturally it will handle all these Goal-C headers for you. For those who added use_frameworks! to your Podfile then the technique would change to as an alternative create a framework/module per pod/library. And that might be the requirement for if you had been utilizing exterior libraries written in Swift, or so I assumed …

I’ve all the time used that in apps I’m engaged on which use Cocoapods for dependencies. Think about me rambling on to a shopper of mine concerning the disadvantages of dynamic frameworks, making an attempt to persuade him of the advantages of Swift Package deal Supervisor. Think about my shock once we inspected his app’s bundle, solely to search out however a single framework in there. All of the third celebration code he had ended up fused with the app binary, my library – written in Swift and built-in by way of git submodule and Xcode sub challenge – leading to the one dynamic framework in his app.

By default, CocoaPods had been doing all alongside what we all know to be the smarter alternative: if third celebration code is offered, to merge the thing code it into the app binary. After all closed-source frameworks that are solely obtainable as dynamic framework binaries depart you with out this selection. Personally I attempt to keep away from these, just like the satan avoids holy water.

Oh and I additionally would be the first to confess that I might by no means heat myself to Carthage. I’ve by no means checked out it. So far as I perceive, the distinction in method versus CocoaPods is that Carthage solely wants a repo URL so as to add a part, whereas CocoaPods wants a Podspec and can generate an Xcode workspace for you the place all dependencies are arrange in a Pods challenge. I imagine it may be this workspace wizardry which may put some individuals off Cocoapods.

Resourceful Swift Packages

Earlier than the present model 5.3 of SPM the 2 large remaining ache factors have been the shortage of dealing with of assets and no assist for distributing binaries as packages. These have now been remedied and what’s one of the best half is that Swift packages now have correct integration in Xcode 12.

One other large benefit that CocoaPods had over different dependency managers was the existence of the “trunk”, a centralised repository of obtainable pods. There you would search and discover libraries that might fulfil sure wants of yours. One other necessary side can be that for a model to be launched on the CocoaPods trunk, you would need to “lint” your pod spec which might validate the syntax and guarantee that the library builds with out errors or warnings.

Apple (and the SwiftPM open supply group) have labored on sharpening the instrument itself. However the central repository with validation side of bundle administration was unfilled. Till Dave Verver stepped and established the Swift Package deal Index. In his personal phrases:

The Swift Package deal Index is a search engine for packages that assist the Swift Package deal Supervisor.

However this website isn’t merely a search instrument. Selecting the best dependencies is about extra than simply discovering code that does what you want. Are the libraries you’re selecting nicely maintained? How lengthy have they been in growth? Are they nicely examined? Choosing high-quality packages is tough, and the Swift Package deal Index helps you make higher selections about your dependencies.

Dave launched the SwiftPM Library within the fall of 2019 which in June 2020 bought re-engineered because the Swift Package deal Index which we use right now.

It was this implementation of a central index, focussing on bundle high quality, that pushed me over the sting to lastly begin embracing SPM. With CocoaPods it has been a tedium to arrange a CI server to maintain constructing your libraries for each change to guarantee that nothing breaks. In contrast, SPI builds your bundle with Swift variations 4.0, 5.0, 5.1, 5.2, 5.3 for iOS, macOS Intel, macOS ARM, Linux, tvOS and watchOS and can then present on the bundle’s web page the place that labored.

This web page offers a really good overview by which builders can acquire an concept as to the standard of this library. And for us challenge house owners it supplies an incentive to attempt to maximise the variety of inexperienced checkmarks you see.

SPI nonetheless tracks 5.3 as “beta” though Xcode 12 has gone gold a month in the past. The reason is that Apple has rushed out Xcode 12 and the finalised assist for constructing common apps that may additionally run on Apple Silicon shall be in Xcode 12.2 – obtainable later this 12 months.

I additionally like how SPI tracks each the newest steady launch (by way of tag on grasp) in addition to the progress on the develop department. I wanted for these builds to be coming sooner, ideally proper after pushing modifications to the GitHub repo, however typically it could possibly take a very long time for the builds to be scheduled. Additionally a technique to retry a failed construct can be very good, as we’re used to from Travis-CI or GitLab-CI.


At this level I needed to enter the issues I realized so removed from including SPM to a few of my libraries, however I’m nonetheless combating with SPI over a few of these coveted checkmarks. Additionally this text has already turned out longer than I needed it to, that I’ll try this within the subsequent one.

Let me know if that’s of curiosity to you, by dropping me a tweet. Are you contemplating including SPM your self? Which half did you wrestle with?

Half 2 is right here.

Additionally revealed on Medium.

Classes: Administrative

Leave a Reply

Your email address will not be published. Required fields are marked *