[SPM] Roadmap?

Regarding IDE integration, Jetbrains staff have said (informally) that the reason SwiftPM is not supported by AppCode and CLion is that the interface keeps changing. So signals towards stabilization could further IDE integration.

As for features, when binary dependencies (needed a crypto library) turned out to be all but impossible, SwiftPM was out for me.

Yes, I would love to start bike-shedding some new SwiftPM features.

Personally, I think bundled assets are a critical missing piece. I can’t even use SwiftPM for running tests on my non-graphical packages because I can’t include any supporting files (e.g. reference server responses). I also can’t easily localise my packages.

I started trying to draft an API for it, but it can be a bit tricky, especially since Apple platforms compile resources in to asset catalogues.

One of my use-cases is a framework I have for building text editors: it includes stuff for reading files, grammar and styling rules, tokenising strings, etc. All of that is platform-agnostic.

  • For iOS, I also provide a native UIView component which is able to access all the internal details of the module, but it also requires some images. When I compile the iOS version of this framework, I expect those images to be in an asset catalogue, just like if I created the project with Xcode, and to refer to them using the standard UIImage(named: "my_image") API.
  • If I was building a linux equivalent (say, using GTK+), I might require some of the same images. Linux obviously doesn’t have asset catalogues, or even frameworks, so the package manager will have to decide where to put those files (alongside the binary? inside the binary? in a special folder in the system?), and we will need an API to get that data/path again.

So platform-specific code is relatively straightforward: we specify some assets, the package manager does the right thing when you build, so you can access the resources using the “standard” APIs for that platform. Maybe you need to call in the package manager to get an identifier/path/blob.

Platform-agnostic code is more tricky. Is there a fallback which I can use to read the contents of my_image.png regardless if it was compiled in to an asset catalogue or placed by itself on the filesystem? I’m not even 100% sure that asset catalogues preserve the original file data in all cases, so that could be a problem.

1 Like

Would love to hear news about this. Even just opening a thread with some insights from the core team so that we can move forward on the subject would be enough IMO :)

I partially agree.
No objection that Xcode provides support for iOS.
But being able to compile and sign iOS projects using SPM would be extremely useful. To do that we would need a plugin/action system (which would be very handy btw) on SPM so that one would be able to provide additional features, one being Xcode for example.

1 Like

it seems assets are archived into a proprietary format

1 Like

You can create packages that wrap system installed C libraries, so wrapping openssl, nacl, … shouldn’t be a problem. Here (https://github.com/IBM-Swift/OpenSSL) is an example of this.

In our case, we were looking at C++ libraries (Botan, Crypto++) that were not installed system-wide. Even if we could have used a C library, we’d have had to ship it with the application.

Background: we have C++, Java, and now Swift clients; we target Windows, GNU/Linux, macOS, Android, and iOS. It would be useful to be able to use the same crypto library everywhere – and with Swift coming in last, and targetting the smallest market, it’s not the environment given the most weight.

Did this proposal ever see the light of day?


@Karl Linux bundles are being developed on the Foundation side ([Proposal] [Foundation] Allowing for system bundles on Linux). Hopefully Swift PM evolves along with it. The details about FHS Installed and Freestanding bundles are available here: https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/FHS%20Bundles.md

1 Like

Yes, I’ve seen that - very exciting! The proposal looks really good.

1 Like