Including Swift Package deal Supervisor Help – Half 2


Within the earlier publish I checked out a number of the historical past of how we packaged up our library code to be used by our fellow builders. We checked out a number of the advantages of static libraries versus dynamic frameworks which additionally include headers wanted by the integrator.

Now let’s dive into the steps that had been crucial for me to allow SPM help on the primary few libraries DTCoreText, DTFoundation and Kvitto. It took me a number of days to iron out all of the kinks and I’d like to share with you what I discovered within the course of.

We’re used to utilizing Xcode to explain what goes right into a construct: Which recordsdata to compile, what exterior libraries to hyperlink to, what sources are wanted and likewise basic construct settings just like the vary and varieties of supported platforms. Extra exactly, these settings are contained within the venture.pbxproj file inside your xcodeproj bundle.

With SwiftPM there is no such thing as a such venture file. Relatively every part is outlined in human-readable type within the Package deal.swift file.

For some fundamental terminology: we outline sure merchandise (i.e. static library, dynamic framework, app bundle and so on, useful resource bundle, unit take a look at bundle), that relate to quite a lot of targets (a bucket for a bunch of supply code recordsdata and sources). Here’s a distinction from Xcode the place goal and product is used synonymously.

Package deal Definition

Step one, and most necessary one, is so as to add a bundle definition file to the basis folder of the repository. It must be on this place as a result of Swift Packages are referenced by the repository URL and SwiftPM will solely take a look at the highest folder for Package deal.swift.

Right here’s the definition for Kvitto, for reference. This has all parts you may encounter, together with a dependency on one other bundle, a few sources on high of the definition of 1 product and a number of goal.

// swift-tools-version:5.3

import PackageDescription

let bundle = Package deal(
    title: "Kvitto",
    platforms: [
        .iOS(.v9),         //.v8 - .v13
        .macOS(.v10_10),    //.v10_10 - .v10_15
        .tvOS(.v9),        //.v9 - .v13
    ],
    merchandise: [
        .library(
            name: "Kvitto",
            targets: ["Kvitto"]),
    ],
    dependencies: [
        .package(url: "https://github.com/Cocoanetics/DTFoundation.git", 
		from: "1.7.15"),
    ],
    targets: [
        .target(
            name: "Kvitto",
            dependencies: [
                .product(name: "DTFoundation", 
				package: "DTFoundation"),
            ],
            path: "Core",
            exclude: ["Info.plist"]),
        .testTarget(
            title: "KvittoTests",
            dependencies: ["Kvitto"],
            path: "Check",
            exclude: ["Info.plist"],
            sources: [.copy("Resources/receipt"),
                        .copy("Resources/sandboxReceipt")]),
    ]
)

The primary line may solely seem like a remark to you, however it is crucial for the swift instruments to find out what syntax parts are supported. Model 5.3 is required you probably have sources in any goal. If you happen to set that to one thing decrease you get syntax errors relating to the useful resource definitions. If you happen to set that to five.3 however don’t specify useful resource definitions (for non-standard sources) you’re going to get warnings about unknown recordsdata that you need to both exclude or outline as sources.

I discovered myself conflicted about that, as I had talked about within the earlier article. All code would work on Swift 5.0 and up and solely the take a look at goal has sources. I may get extra inexperienced checkmarks on Swift Package deal Index if I eliminated the .testTarget definition.

On the opposite aspect the swift instruments allow you to run thusly outlined unit exams from the command line and functioning unit exams additionally ought to depend as an indication of excellent library high quality. Lastly, everyone needs to be utilizing Swift 5.3 anyway as that’s the baseline customary because the launch of Xcode 12.

That’s why I selected to go away it at that.

The fundamental setup of the bundle definition is easy. You’ve gotten the bundle title, then some minimal platform variations. Notice that these minimal OS variations don’t imply that that might prohibit the the bundle to particular platforms.

The merchandise part defines what sort of library comes out of the construct course of. The default setting (invisible) is to supply a static library, by specifying kind: .dynamic you get a dynamic framework as an alternative. The targets array specifies which targets will get merged into the ultimate product.

I believed for a second that that may be good to have the sources be added to the framework as an alternative of a separate useful resource bundle, like we’re used to. However alas the dealing with of sources stays the identical they usually get bundled right into a Product_Target.bundle. So subsequently I’d reasonably have the static library – which is able to get merged into the app binary – reasonably than having one more separate framework bundle contained in the app bundle.

As I defined within the earlier article, dynamic frameworks needs to be prevented if the supply code for libraries is public. So we’re pleased with the static library default.

The dependencies part lists the exterior reference to different packages. You specify the repository URL and the minimal variations. The proven means with from and a model would settle for all 1.x.x variations from and together with 1.7.15. There are additionally different methods to specify an actual quantity or sure ranges.

Final come the targets. We have now a daily goal for the bundle and a take a look at goal for all of the unit exams. If you happen to don’t specify a path then SwiftPM expects the supply code within the Sources folder beneath the goal’s folder and sources in a Assets folder. I’ve a unique construction, so I specified a customized path.

I’ve to exclude the Data.plist for each targets as a result of that is utilized by two targets outlined contained in the Xcode venture. And for the take a look at goal I specify two sources to be copied with the trail relative to the goal customized path. These copy directions are crucial as a result of the contained sources don’t have a sort that Xcode is aware of easy methods to deal with. For issues like strings recordsdata or XIBs you don’t must specify something.

Evaluate the dependencies key of each targets. On the one hand you see that I’m referencing the exterior dependency of the primary goal. Then again the take a look at goal requires the primary goal to work. That’s additionally a distinction to Xcode the place the examined code resides inside a number software, the place’s right here it’s compiled into the unit take a look at bundle.

Goal Issues

You may be questioning why there’s a distinction between merchandise and targets in SPM. One cause for that you’ve got already seen: there is no such thing as a cause for the take a look at goal to be represented in a product. Easy packages will usually solely have one product that may solely consist of 1 goal.

Though I already discovered two extra causes, to separate code out into extra particular person targets after which additionally merchandise.

You may assume that Swift Package deal Supervisor would solely all you to have code written in Swift. However you’d be improper, Any language goes, additionally Goal-C and different C dialects. However SPM doesn’t permit you to combine C-based languages with Swift in a single goal.

In a single venture I had some Goal-C code for a operate with plenty of ifs. I rewrote that in Swift solely to seek out that compiling this could take greater than a minute, in contrast to a couple seconds in Goal-C. So I selected to go away the operate because it was. The answer was to place it right into a separate Goal-C goal and refer that to an inside dependency from the primary Swift goal.

The opposite good cause for a separate goal and product was to have some frequent information mannequin code that will be utilized by inside targets and likewise by way of import in an app consuming my library. In locations the place the shopper would solely want the shared definitions he would import the particular module for that. Elsewhere he would import different targets which in flip may additionally make use of these definitions internally.

Every product turns into its personal module.

Resourcefulness

I discussed above you can let SPM do its personal factor in relation to customary useful resource sorts, like localised strings, XIBs, storyboards and asset catalogs. If you happen to use string localisation although, you must specify the venture’s default language.

Different sorts you must both particularly exclude or specify what needs to be carried out for it. You’ll be able to both specify a .copy for every particular person useful resource or additionally for the whole Assets folder. Since I’ve solely two take a look at recordsdata and that’s not going to alter, it wasn’t an excessive amount of work so as to add these individually.

SPM expects sources in the identical folder {that a} goal’s supply recordsdata reside in (or a sub-folder thereof). The rationale for that’s once more that there is no such thing as a Xcode venture file the place you might specify membership of sure recordsdata to particular targets. You specify what belongs the place by how it’s specified by the file system together of the bundle definition.

Say you’ve a single place the place you’ve localised strings recordsdata downloaded from a translation website like POEditor however you need them to be included in numerous targets. A way to realize that’s to create soft-links contained in the goal’s useful resource folders to the recordsdata. I wrote this shell script to create the lproj folders for all languages after which create the hyperlinks.

#!/bin/sh

echo "Eradicating current strings"
rm -rf ../TFMViews/Assets/*.lproj
rm -rf ../TFMExtension/Assets/*.lproj

PWD=`pwd`

for entry in *.lproj
do
  echo "Linking $entry..."

  mkdir ../TFMViews/Assets/$entry
  ln -s ../../../Strings/$entry/TFMViews.stringsdict 
     ../TFMViews/Assets/$entry
  ln -s ../../../Strings/$entry/TFMViews.strings 
     ../TFMViews/Assets/$entry

  mkdir ../TFMExtension/Assets/$entry
  ln -s ../../../Strings/$entry/TFMExtension.stringsdict 
     ../TFMExtension/Assets/$entry
  ln -s ../../../Strings/$entry/TFMExtension.strings 
     ../TFMExtension/Assets/$entry

carried out

The identical strategy of soft-links may also be employed for Goal-C primarily based packages the place you may hyperlink to all related public headers in an embody folder.

Platform-specific Code

Because the bundle has no facility for limiting particular supply code to particular platforms or OS variations, you’ll face the scenario that sure code received’t compile for different platforms. A workaround for this limitation is using conditional compilation directives.

For instance, every part that references UIKit can’t be compiled for macOS or watchOS, so I’ve a number of locations in DTCoreText or DTFoundation (each written in Goal-C) the place the whole implementation is enclosed in:

#import <TargetConditionals.h>

#if TARGET_OS_IPHONE && !TARGET_OS_WATCH
...
#endif

I additionally discovered that generally I needed to additionally import the TargetConditionals header for the defines to work. Specifically sure Goal-C class extensions in DTCoreText wouldn’t be seen within the public interface if I didn’t import this header. I’ve no clarification as to why, however including the import for the header mounted it.

Contained in the Xcode Undertaking

The modifications for conditional compilation apart, there’s nothing you have to change in your Xcode venture – until you wish to. The principal setup for the bundle occurs in Package deal.swift. You’ll be able to construct the bundle with issuing swift construct.

I discovered it handy so as to add a reference to the bundle contained in the Xcode venture as a result of this lets you debug your code within the context of being compiled for a bundle. If you happen to drag any folder (containing a bundle definition) into the venture navigator pane, Xcode will add an area bundle reference for you, with an emblem of a cute little field.

In Xcode 12 there’s a bug that in the event you try this for the venture folder itself, it appears to work, however when you shut the venture and reopen it once more, the reference turns into defunct. The best way to repair it’s to alter the reference to “Relative to Undertaking” and open the folder selector by way of the folder button and re-select the venture root folder.

This additionally creates a scheme for constructing the bundle and the bundle’s merchandise change into obtainable to hyperlink/embed to your app. Package deal merchandise have an icon of a greek temple. If they’re static libraries then they’ll get merged into the app binary, dynamic frameworks shall be added to the app’s Frameworks folder.

Xcode additionally creates a scheme for the bundle, putting it in .swiftpm/xcode/xcshareddata/xcschemes/. I moved it into the shared schemes folder of the xcodeproj and renamed it to Kvitto-Package deal.xcscheme.

I had the watchOS platform builds on Swift Package deal Index fail as a result of xcodebuild insists on constructing all targets, together with the take a look at goal. This fails as a result of unit exams require XCTest which doesn’t excite for watchOS.

By offering an aptly named shared scheme it should solely construct the primary goal and I achieved inexperienced checkmarks for watchOS on SPI.

Library Unit Checks

To run the unit exams contained within the take a look at goal, all you have to do is to run swift take a look at on the command line, from the repository root folder.

Results of operating the Kvitto unit exams from the command line

Some magic was required to get that to work as a result of take a look at recordsdata required by the unit exams usually are not bundled within the .xctest bundle. For normal packages a useful resource bundle accessor is being routinely generated, which you should use with Bundle.module.

The accessor works by figuring out the trail of the executable and establishing a bundle title from names of bundle and goal. Within the case of unit exams the executable is xcrun contained within the Xcode.app bundle the place it has no likelihood of discovering the Kvitto_KittoTests.bundle.

My ugly, however practical, workaround for that is as follows:

func urlForTestResource(title: String, ofType ext: String?) -> URL?
{
	let bundle = Bundle(for: kind(of: self))
		
	#if SWIFT_PACKAGE
		
	// there's a bug the place Bundle.module factors to the trail of xcrun contained in the Xcode.app bundle, as an alternative of the take a look at bundle
	// that aborts unit exams with message:
	//   Deadly error: couldn't load useful resource bundle: /Functions/Xcode.app/Contents/Developer/usr/bin/Kvitto_KvittoTests.bundle: file KvittoTests/resource_bundle_accessor.swift, line 7
		
	// workaround: attempt to discover the useful resource bundle on the construct path
	let buildPathURL = bundle.bundleURL.deletingLastPathComponent()
		
	guard let resourceBundle = Bundle(url: buildPathURL.appendingPathComponent("Kvitto_KvittoTests.bundle")),
	   let path = resourceBundle.path(forResource: title, ofType: ext) else
	{
		return nil
	}
		
	return URL(fileURLWithPath: path)
		
	#else
		
	guard let path = bundle.path(forResource: title, ofType: ext) else
	{
		return nil
	}
		
	return URL(fileURLWithPath: path)
		
	#endif
}

This depends on the truth that the useful resource bundle shall be created parallel to the xctest bundle, in the identical construct folder. The #if SWIFT_PACKAGE conditional compilation will solely be added if this code is constructed as a part of a swift bundle. With this workaround, the earlier mechanisms of operating the unit take a look at scheme by way of Xcode continues to work.

The beauty of Swift being open supply, is that we will additionally examine the code for the useful resource accessor on GitHub. It seems that the talked about bug has already been addressed there. The repair was made too late to make it into Swift 5.3 in Xcode 12 however has been confirmed to be current in Xcode 12.2.

Conclusion

I discover that the evolution of Swift Package deal Supervisor as progressed sufficiently to start out including help for it to my libraries. It’s potential and advisable to take action along with different methods of integration, like Xcode subproject, Cocoapods or Carthage.

Essentially the most annoying limitation remaining is that you just can’t restrict targets to sure platforms or specify a variety of supported OS variations per goal. However these can simply be labored round with conditional compilation directives.

The standard standards partially enforced by the Swift Package deal Index coupled with the discoverability of elements additionally make it enticing for library distributors to think about supporting Swift Package deal Supervisor. Having the dependency administration taken care of by Xcode is the best function of all.



Additionally printed on Medium.


Classes: Administrative

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles