Roadmap of SwiftPM Integration into Xcode

You appear to be approaching this with the assumption that reluctance from the Xcode team is the problem. I don't have any information, but I highly doubt that is the case. Try to imagine which concrete features you want from an IDE-SPM integration, and you will quickly see the package manager is deficient for doing anything interesting right now. There is some progress, though.

AFAIK, SPM is already supposed to be a lower-level description than an Xcode project of what to build and how. That's why you can generate the IDE projects from the SPM package description.

2 Likes

It does seem that reluctance is a problem, but even if it isn't: I don't think it's a good sign for an open-source programming language to be so dependent on a closed-source IDE. The current discussion ("we can't give a roadmap for XCode-SPM integration because XCode is closed source") is a good indicator for why this is a problem. The other problem is that, even if the XCode team does happen to finish SPM integration in the next couple of months, as far as I understand it the XCode release schedule means we won't be getting that until next year. (All IMHO, of course).

I'll agree that the SPM is not fully-featured enough yet, though.

3 Likes

Just to be clear, SwiftPM aims to be an independent cross-platform project and is not driven by needs of any IDE. Also, providing a great command-line development experience is one of the major goals of SwiftPM. I highly recommend watching the WWDC session about SwiftPM to know more about where SwiftPM currently is and what it could evolve into.

4 Likes

Adding SwiftPM support to XCode, however preliminary and not as main project model (yet), would certainly bring a lot more attention (and potentially helping hands) to its development.

Right now, with none of the (major) IDEs supporting it, I don't get much out of using SwiftPM unless I want to stick to editors and/or rely on the "create XCode project from SwiftPM" pipeline.

The fact that most "big" libraries support CocoaPods and maybe Carthage but certainly not SwiftPM just adds to the pain. I do have one project (which I need to run from a CLI script) that consists of a SwiftPM file, a Pods file, and constructs an XCode workspace it then uses to build things. That was messy. (Any interest in a blog post on that?)

3 Likes

At this point I think that a lot of the Apple dev community would be happy with clear documentation on using Xcode with SPM. They would be thrilled with iOS support, let alone some sort of IDE support.

We are a macOS dev shop and are about to try using SPM to maintain modules and build a shipping project out of them. If successful I'm going to write it up as well. We currently use Carthage for maintaining some of our internal dependencies, but then everyone, including build servers, needs to install and configure Carthage. SPM is built-in which is one of the primary draws it has for me.

The thing that trips Xcode up more than anything seems to be the fact that SPM isn't just a package manager, it also is the build chain and testing rig. This means you need to do things like add a swift build script step to the Xcode build process and then you end up duplicating lots of work. All I really want is a way to just easily compose macOS apps from separate modules that we create and maintain internally.

Testing is more of the same. I love that I can test non-exectuable bundles and modules with it, but I also wish that testing integrated well into Xcode. I can write my tests in the test editor in Xcode, but then I need to drop out to the terminal to test them and I don't get code coverage. I can deal with this, but it's annoying.

I think some of the posts you see these days are the result of Xcode/SPM frustration. After three years in the world it feels like the SPM teams don't care about Xcode users. To be clear I know that's not the case. If it were, things like these forum threads wouldn't exist! This year at WWDC the people sitting on either side of me walked out of the SPM session because it didn't cover iOS or Xcode.

I know that SPM aims to be IDE and platform agnostic, but I also know that the majority of the Swift user base are developers with Apple tools, on Apple platforms, for Apple platforms. I also realize that the Xcode issue isn't for the SPM team to solve, it's in Xcode's court. (Yes, I've filed radars on Xcode but I was internal at the time and no longer have the numbers as that developer account is dead.)

If this comes off as a rant I don't mean it to. The Apple developer community is just so close now to having really great ways to compose and maintain Apps.

Thanks,
Josh

1 Like

Maybe Carthage could be leveraged until SwiftPM can stand on its own feet?

Still there‘d be a gap of missing features in SwiftPM to make this the new de-facto standard. Top of mind would be build settings (SR-3948; at least iOS deployment version) and packaging resources (SR-2866).

More nice-to-have features are mentioned in this thread: Swift Package Manager Evolution Ideas

1 Like

I very much sympathise with this view.

Rather than couching it in negative terms ("divorcing from Xcode"), I'd rather look at it from a positive point of view - that the Swift project needs to actively work to make Xcode unnecessary for Swift development. Which is another way of saying that it needs to actively support and enable other IDE efforts.

There are some community efforts to build a Swift implementation of the language server protocol, which seems to have become a de-facto standard for providing language support to IDEs.

There are also projects to integrate Swift directly in VS Code and Atom (full disclosure: I'm working sporadically on the Atom one).

Most of these build on SourceKit - which is excellent - but there's definitely a lot more that the Swift project (and community) could do to help with this. The language server implementation, in particular, would be invaluable if it was adopted by, and shipped with, every Swift distribution, as it would very much simplify the process of bringing up things like syntax colouring and auto-completion within IDEs.

4 Likes

Apple obviously supports this, as it extracts things from Xcode into separate opensource projects. For example the new build system in Xcode uses swift-llbuild which afaik is the same one that SwiftPM uses.

3 Likes

It's both. The biggest hole so far has been resources. SPM didn't have a way to define them for applications/libraries/tests. You can't create many interesting GUI applications without images (e.g. no application icon).

We just got bundle support for Linux. A proposal for SPM resources is apparently being worked on, and will be coming in the fall. That means it will finally become practical to define and build GUI applications using SwiftPM.

The Xcode team's goal is to improve the developer experience on- and for Apple platforms. I'm sure they would love to implement native integration with Swift's official package manager. It's not going to stop people editing, building or debugging their applications in Xcode. I find it surprising that anybody would suggest they might have some kind of pathological hatred of SwiftPM.

3 Likes

Support for SPM is about to land in CLion (from 2018.3).

2 Likes

And already available free of charge (albeit for limited time) in the EAP.

And entirely free of charge for higher education :wink:

1 Like

I noticed that there is an Eclipse-based IDE for the Swift programming language. Has anybody used it yet?

Eclipse-based IDE for the Swift programming language

Has anybody used it?

Xcode integration finally landed :tada:
Resources are still not supported, so let‘s hope this will be implemented soon.

8 Likes

I'm new to SwiftPM and first trying it in Xcode 11's new Swift Packages feature and was hoping to be able to make edits to the package which there isn't a menu options for, so in trying "swift package edit MyLibrary --branch bugFix" fails without a manifest, doesn't appear to be a Package.swift instead there is JSON at project.xcworkspace/xcshareddata/swiftpm/Package.resolved looking similar to a package.swift. The actual checkout is in the DerivedData again no Package.swift there either, there is a manifest.db however:

DerivedData/MyApp/xxx/SourcePackages/
checkouts/
dependencies-state.json/
manifest.db
ManifestLoading
repositories

Does anyone know how to run swift package commands for a Xcode 11 project?

The "Development" section of the forums is used for development of Swift, not development using Swift.

For help with using Swift, you can try the "Using Swift" section of the forums, and for help with Apple developer tools, the Apple developer forums.

Hi there,

I was at the WWDC and was happy that Swift Packages are now integrated on XCode. I did have some conversations at the packages lab, regarding resources support and he told me to better write directly here. So, my module now has a CoreML model which I usually ship it as a resource (in cocoapods and carthage). Since the file itself it's the CoreML model, as well as a wrapper for the type safe class and functions in swift, I was wondering if this will also work with the current bundle/ressource approach? The swift wrapper in every .mlmodel generates a class class MyModel { } and instantiates the model inside as

let bundle = Bundle(for: MyModel.self)

I was wondering if this autogenerated wrappers will still be available in XCode (they are generated at build time) or if the current resource approach will practically just copy the file and we will have to instantiate it "manually"? It would be nice to sill have a nice and tight XCode integration of CoreML models in Swift Packages so these autogenerated wrappers still work.

Is this the right place to discuss this? or if there are other threads I should take a look into, please let me know, this is my first post... :grimacing:

1 Like

I think that's a better fit for the resources conversation, since that's what's missing for that kind of support to happen.

2 Likes

Hello. I tried new Xcode that's a bomb. But I have a problem in some situation. I have a package with products.

products: [
    .library(name: "Vecors", targets: ["Vecors"]),
],
targets: [
    .target(
        name: "Vectors",
        dependencies: [...]),
    .target(
        name: "States",
        dependencies: [...]),
...

Then I installed that package in iOS project in Xcode. And the module Vectors appeared in the project. Thеn I change the product in the package to

products: [
    .library(name: "States", targets: ["States"]),
],
...

Then I update package in the Xcode project. But Xcode dose not see the new module States.

The .target(...) declarations are the modules. A .library(...) is a group of modules which can be used as a dependency by another package.

The way your first example is written, you had a Vectors library containing only the Vectors module. The States module was not formally accessible from outside the package. (Such modules are similar to internal declarations in source code, but at the package level.)

After your change, you have a States library containing only the States module. The Vectors module is internal to the package.

What you want is one of these two:

products: [
    .library(name: "Vecors", targets: ["Vecors"]),
    .library(name: "States", targets: ["States"])
],
products: [
    .library(name: "Vectors & States", targets: ["Vecors", "States"])
],

With the first option, client packages can use one or the other or both.

With the second option, client packages have to depend on both whether they actually use both or not. This can simplify the declarations in your Package.swift and the client’s Package.swift, but it also may mean some modules end up being built for no reason.

1 Like
Terms of Service

Privacy Policy

Cookie Policy