I'd always assumed you needed an .xcodeproj file to develop a package, but after watching the WWDC talk I noticed you can create a Swift Package from within Xcode (which doesn't generate a .xcodeproj file) and then simply double-click the Package.swift file and the package opens in Xcode you get a scheme to build your code and test it.
Are there any drawbacks to this approach? It's quite unusual not being able to see targets and build settings, but then I realised you get a framework target with an .xcodeproj file too. So it might depend on your deliverables. Would anyone like to share their experiences, good or bad? I'm really not sure which option to go for.
Also I noticed the WWDC talk seemed to advocate for keeping your package in a subfolder of your original (app) project folder, if you're splitting up your code like that and working on both code bases togther. Is that a good idea? Initially I thought the package code would be stored in your app's repo (which is obviously horrible), but if you choose to create a git repo with Package creation I guess you end up with a git repo inside a git repo. I chose to store my toy/test/dummy package outside my app's folder and it seemed to work ok.