Tuesday, June 25, 2024
HomeIOS DevelopmentA unique solution to develop SwiftPM Packages inside Xcode initiatives — Erica...

A unique solution to develop SwiftPM Packages inside Xcode initiatives — Erica Sadun


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 essential.

Apple’s Modifying a Package deal Dependency as a Native Package deal assumes you’ll drag in your package deal to an Xcode challenge as an area package deal overrides one which’s imported by means of a standard package deal dependency.

In Creating 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 an area package deal overrides a package deal dependency with the identical title…in case 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 challenge to make use of the package deal dependency once more.”

I don’t use this strategy. It’s not unhealthy or unsuitable, it simply doesn’t match my fashion.

However, opening the Package deal.swift file on to develop has drawbacks in that it doesn’t totally supply Xcode’s suite of IDE assist options but.

So I’ve been engaged on a private answer that greatest works for me. I would like my package deal improvement and its exams to stay individually from any particular shopper app exterior a testbed. I want 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 blissful inexperienced checks.

I set out to determine how greatest, not 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 challenge full with exams and a package deal goal. You should use the --type flag to set the package deal to executable, system-module, or manifest as a substitute 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 Checks/
Creating Checks/LinuxMain.swift
Creating Checks/GenerateTests/
Creating Checks/GenerateTests/GenerateTests.swift
Creating Checks/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 at all times find yourself deleting the .gitignore as I take advantage of a custom-made international ignore file. That is what the ensuing challenge appears to be like like:

As you see, the generated Xcode challenge 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 seemed into utilizing a playground however let’s face it: too gradual, 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 unique solution to construct my base package deal atmosphere. It’s hacky however I a lot choose the end result. As a substitute of producing the challenge, I begin with a testbed challenge after which create my package deal. This strategy 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 exams. The library folder you see right here incorporates solely an Data.plist and a bridging header. It in any other case builds from no matter Sources I’ve added.

I a lot choose this set-up to the generate-xcodeproj strategy, though it takes barely longer to set-up. The rationale for that is that SwiftPM and Xcode use completely different philosophies for a way a challenge folder is structured. SwiftPM has its Sources and Checks. Xcode makes use of a supply folder named after the challenge.

So I take away that folder, add a Sources group to the challenge, and be certain that my construct phases sees and compiles these recordsdata. The Checks want comparable tweaks, plus I’ve so as to add a symbolic hyperlink from Xcode’s exams title (e.g. “ProjectNameChecks”) to my SwiftPM Checks folder on the high degree of my challenge to get it to all grasp 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 fitting 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 robotically initialize model management, I don’t must git init by hand.

I believe it is a short-term workaround as I anticipate the mixing of SwiftPM and Xcode to proceed rising over the following couple of years. Since WWDC, I’ve been significantly enthusiastic about growing, deploying, and integrating SwiftPM packages. I believed I’d share this in case it would assist others. Let me know.

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments