Packages are not designed to be “installed”. The idea is you declare them as a dependency in your own package in order to have direct access to the source code. It works wonderfully on desktop platforms, but since there is no support for resources yet, application and framework bundles are not directly supported. A consequence is that the CocoaTouch platforms have no viable product types and have to work around it through generate-xcodeproj. (I posted a precise walkthrough over on this thread.)
Theoretically, someone who wants to use your library should simply create a package of their own that depends on it. Exactly how your package’s sources end up built into their product is then their own decision—including whether or not to use Xcode, Mint, Accio or whatever other package handling tools are out there. Note for example that by default, package libraries do not produce any executable‐like output file of any kind, but are built right into whatever depends on them. Eventually the intent is that optimization will be able to cross module and package boundaries, resulting in tailored optimizations according to how the library’s symbols are actually used.
There is no reason your package has to only be a Swift package. If you think your users would prefer it, you can simultaneously vend it for use through other dependency managers like Carthage or Cocoapods.