Xcode 11 understands packages natively. It can load and manipulate them directly. It does not need you to convert them to Xcode projects first.
I have assumed you use source control. In the event you do not and those are terms you have never heard before, then you can simply ignore what follows, since you will never encounter the situation described. But if you understand the words and are instead asking why they are relevant, here is the longer explanation:
While swift build does not require regenerating Xcode 99% of the time, several distinct concepts can stack op together to create a corner case where it might end up necessary.
Package.resolvedand its corresponding checked out dependency files will not be modified byswift buildand similar commands as long as they remain valid. They would only become invalid if you change the version restrictions in the manifest (which would already have been a reason in and of itself to regenerate the Xcode project).- If there is no
Package.resolvedyet, thenswift buildwill resolve dependencies and construct one. - Most developers (and the default
.gitignorecreated byswift package init) havePackage.resolvedchecked into Git, so the resolver only makes its decisions once and then they are persisted, even across repository clones. Every clone checks out the dependencies in the exact same arrangement. swift package generate-xcodeprojis just likeswift buildin that it needs to either use an existingPackage.resolvedor make decisions to create a new one.- Most developers (and the default
.gitignorecreated byswift package init) make Git ignore the Xcode project. So new clones do not come with an Xcode project and you have to generate your own. Generating it will createPackage.resolved, so by the time you actually have an Xcode project,Package.resolvedwill already be finalized and in a valid and stable state. - But let’s say you do not belong to the “most developers” mentioned above. Let’s say you check in your generated Xcode project. After a fresh clone, you will have an Xcode project, but all the dependency files it expects will be missing, because the package manager hasn’t fetched them yet. You need to do
swift package resolveso that the package manager fetches the dependencies (swift buildorswift package generate-xcodeprojwould also trigger this). Since it will respect the existingPackage.resolvedto the letter, all the files will end up back in the exact same spot and the Xcode project will be valid again even without regenerating it. - Let’s say you do things even more unusually and you make Git ignore your
Package.resolved. When you make a fresh clone of that package, it comes with an Xcode project but noPackage.resolvedfile. You need to doswift package resolveto fetch the dependency files to where they need to be. Most of the time, just like the last bullet point, they land right where the Xcode project expects them, so all is well. - Now let’s say one of your dependencies release a minor version. Some time after that, you make a fresh clone of your package. Its included Xcode project points at files that were there when you made the commit, and that the package manager has been faithfully putting back in the same place for a while now. But you are in for a surprise. The clone did not come with a
Package.swift, so when youswift build, the package manager will make a new one. Since it prefers the more recent releases, and there is a shiny new one to try, it selects it and resolves the whole graph differently. Different versions mean different files in a different arrangement, so now Xcode is out of sync with the file system andswift package generate-xcodeprojis in order.
So yes, swift build can cause circumstances that change files behind Xcode’s back, but you really have to leave the beaten path to encounter it.
I suppose if you add “git checkouts or cloning” to the list in my previous comment then that list would cover absolutely everything.