WWDC gave us many causes to each migrate libraries to SwiftPM and to develop new ones to assist our work. The combination between Xcode improvement and SwiftPM dependencies retains rising stronger and extra vital.
Apple’s Enhancing a Package deal Dependency as a Native Package deal assumes you’ll drag in your package deal to an Xcode venture as a neighborhood package deal overrides one which’s imported by means of a traditional package deal dependency.
In Growing a Swift Package deal in Tandem with an App, Apple writes, “To develop a Swift package deal in tandem with an app, you may leverage the conduct whereby a neighborhood package deal overrides a package deal dependency with the identical identify…in the event you launch a brand new model of your Swift package deal or need to cease utilizing the native package deal, take away it from the venture to make use of the package deal dependency once more.”
I don’t use this method. It’s not dangerous or mistaken, it simply doesn’t match my fashion.
Alternatively, opening the Package deal.swift file on to develop has drawbacks in that it doesn’t totally provide Xcode’s suite of IDE assist options but.
So I’ve been engaged on a private answer that finest works for me. I would like my package deal improvement and its checks to stay individually from any particular shopper app outdoors a testbed. I would like to make sure that my code will swift construct and swift check correctly however I additionally need to use Xcode’s built-in compilation and unit testing with my completely satisfied inexperienced checks.
I set out to determine how finest, no less than for me, to develop Swift packages beneath the xcodeproj umbrella.
I first explored swift package deal generate-xcodeproj. This builds an Xcode library venture full with checks and a package deal goal. You need to use the --type flag to set the package deal to executable, system-module, or manifest as an alternative of the default (library) throughout swift package deal init:
Generate% swift package deal init Creating library package deal: Generate Creating Package deal.swift Creating README.md Creating .gitignore Creating Sources/ Creating Sources/Generate/Generate.swift Creating Assessments/ Creating Assessments/LinuxMain.swift Creating Assessments/GenerateTests/ Creating Assessments/GenerateTests/GenerateTests.swift Creating Assessments/GenerateTests/XCTestManifests.swift Generate% swift package deal generate-xcodeproj generated: ./Generate.xcodeproj
Though SwiftPM creates a .gitignore file for you as you see, it doesn’t initialize a git repository. Additionally, I all the time find yourself deleting the .gitignore as I take advantage of a custom-made international ignore file. That is what the ensuing venture seems to be like:
As you see, the generated Xcode venture has every part however a testbed for you. I actually like having an on-hand testbed, whether or not a easy SwiftUI app or a command line utility to play with concepts. I appeared into utilizing a playground however let’s face it: too sluggish, too glitchy, too unreliable.
It’s a ache so as to add a testbed to this set-up, so I got here up with a special option to construct my base package deal surroundings. It’s hacky however I a lot want the result. As an alternative of producing the venture, I begin with a testbed venture after which create my package deal. This method naturally packs a pattern with the package deal however none of that pattern leaks into the package deal itself:
I find yourself with three targets: the pattern app, a library constructed from my Sources, and my checks. The library folder you see right here accommodates solely an Information.plist and a bridging header. It in any other case builds from no matter Sources I’ve added.
I a lot want this set-up to the generate-xcodeproj method, though it takes barely longer to set-up. The explanation for that is that SwiftPM and Xcode use totally different philosophies for a way a venture folder is structured. SwiftPM has its Sources and Assessments. Xcode makes use of a supply folder named after the venture.
So I take away that folder, add a Sources group to the venture, and be certain that my construct phases sees and compiles these recordsdata. The Assessments want comparable tweaks, plus I’ve so as to add a symbolic hyperlink from Xcode’s checks identify (e.g. “ProjectNameAssessments”) to my SwiftPM Assessments folder on the prime stage of my venture to get it to all cling collectively. As soon as I’ve achieved so my inexperienced checks are prepared and ready simply as if I had opened the Package deal.swift file instantly. However this time, I’ve all the appropriate instruments at hand.
Since I’m speaking about set-up, let me add that my duties additionally embrace organising the README, including a license and creating the preliminary change log. These are SwiftPM setup duties that swift package deal init doesn’t cowl the best way I like. I trash .gitignore however since I’ve Xcode set-up to mechanically initialize model management, I don’t must git init by hand.
I believe this can be a short-term workaround as I count on the mixing of SwiftPM and Xcode to proceed rising over the subsequent couple of years. Since WWDC, I’ve been notably enthusiastic about growing, deploying, and integrating SwiftPM packages. I assumed I’d share this in case it would assist others. Let me know.
