Roadmap of SwiftPM Integration into Xcode

This may be a fringe opinion, but IMHO the best way Swift can become truly cross-platform and viable as a backend language is if it starts divorcing itself from XCode as much as possible. It appears that SPM integration - and in general, better support for non-iOS development - is not an Apple priority.

To me that would mean things like:

  • Starting/continue developing plugins for major plugins/IDEs (some work has already happened there, but the situation can still improve)
  • Ditch XCTest and write a test runner that works reliably on Linux (without LinuxMain hacks), supports common use cases such as pending tests and parameterised tests, has good console output and ideally even pluggable reporting (look at other languages for prior art)
  • Make the REPL more fully-featured and integrate it with the SPM, so "playing around with a new library" becomes the same trivial matter as it currently is in e.g. Ruby

That of course would depend on who cross-platform Swift is intended to target. If it's trying to target iOS developers who don't want to learn a new language for the backend, the situation is probably "fine" and attempting to move away from XCode would maybe alienate developers; if it's trying to attract developers from other communities (such as Ruby, Python, Rust, Java, ...), I think it's exactly the other way around, the unnecessary coupling to a particular IDE makes little sense.

Currently the situation seems to be "we kind of have to work with XCode, sort of, but XCode doesn't work with us and we have no control over it", which I would argue is a very difficult position.

In the best of all possible worlds, this would lead to the development experience outside of XCode to become so awesome that even hard-core XCode users would find it compelling to stop using XCode (or minimise the use thereof), in turn increasing the pressure on Apple to make XCode better.

(Of course, this is a lot of wishful thinking; I realise that the default response to these requests would be "why don't you build this yourself?" to which the answer is "because I don't know how and don't have the resources")

12 Likes

@Fryie I think we all want a proper cross-platform IDE for Swift. But unfortunately, that's not something a couple of developers can do in their free time.

I know JetBrains is working on SPM support for CLion (which has Swift support but still relies on CMake), so that's something to keep an eye on.

If only someone could convince Microsoft to get involved with Swift and add support for Windows and VS Code... That would give Swift a major boost in education.

3 Likes

Actually, I wouldn't even need an IDE. A couple of editor plugins and good command line tools would already work; but I agree that building good command line tools is not a trivial thing either.

The problem with developing tools IDE-first is that this doesn't generalise and you can't use that stuff on CI; I you start from CLI tools, adding IDE support for them is (in theory) much easier.

I remember the days when building Java projects would depend on how you had configured your IDE; nowadays the good IDEs just call CLI tools like maven / gradle and parse their output.

2 Likes

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.

7 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