To be honest I was a bit disappointed at WWDC 2018, as I expected that SwiftPM was finally integrated into Xcode and we were able to start replacing Cocoapods and Carthage for iOS projects.
Is this integration still on the roadmap? Can any plans on the time frame be shared with the public?
I agree with the disappointment, but it didn't really come as a surprise, as you can follow SPM's progress in the repo.
In the list of future enhancements @rballard outlined in his talk many areas that cover exactly what we need but of course they can't speak on Xcode specifically (One is open source, the other is Apple's internal project).
I think it is absolutely certain that the things we want are on the roadmap – they are just not there yet.
Sadly we will have to wait at least for another year until those things happen, unless Apple changes Xcode's release cycle 
(which would be quite a good thing seeing that other IDEs are progressing a lot faster in increments). That is a lot more frustrating to me than SPM not being there yet.
Well I can follow progress of SPM in their repo, but I cannot follow the progress on Xcode‘s side, or can I somehow?
Hi @fabb,
As @tkrajacic said Xcode is not part of Swift open source process, the future plans and timelines are not published in public. Also, please read this post if you haven't: [swift-build-dev] [swift-evolution] Swift Package Manager 3.0 Project Status
Thanks for the link.
That was nearly 2 years ago 
Here‘s the link to the same post, but in this forum: Swift Package Manager 3.0 Project Status - #5 by rballard
Yes, disappointing; no SPM Xcode integration.
Extremely disappointing indeed.
On a positive note, this project came recently to my attention:
Seems it can potentially ameliorate the situation...
Interesting, have you tried it? Does it work well?
Not yet. Will give it a try soon(ish).
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:
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")
@yxckjhasdkjh 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.
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.
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.
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.
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.
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?)
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
Maybe Carthage could be leveraged until SwiftPM can stand on its own feet?
https://github.com/Carthage/Carthage/pull/1945
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
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.
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.