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