A few SwiftPM contributors (@neonacho, @aciid, @rballard, and me) met to discuss the draft proposal for package resources from last year, especially in light of the recent discussion and pitch for resource targets on the Swift forums.
The discussion came to the following observations:
In the interest of providing incremental improvements, we believe that the initial proposal should focus on how resources are defined in packages, and provide only the basic means necessary to access them at runtime (through Bundle, initially). We all agree that type-safe access to individual resources is important in the long-term, but believe that it can be separated into a follow-on proposal that builds on the initial one. Adding type-safe access later should not introduce incompatibilities with existing packages or prevent optimizations, and we shouldn’t delay the basic support for resources while discussing how to get the type-safe access correct across the various platforms.
The basic choice for how resources should be specified comes down to whether to require all resources to be put into a directory with a special name (such as “Resources”) or whether to allow resources to be intermixed with source files. There are a number of tradeoffs, and the answer is less clear for resource types that are processed to generate both data and source code. Using a directory with a special name might be simpler for the most common cases, but might also require files to be moved in the file system when adding SwiftPM support for existing code bases that don’t already have their files arranged that way. On the other hand, allowing resources to be intermixed with source code is more flexible, and perhaps a more natural fit for file types that conceptually straddle the boundary between source code and resources (such as Metal shaders), but requires some way of indicating which files should be treated as resources based on their type alone. Those rules can get complicated and cause confusion.
There is a question of how much to teach SwiftPM about resource types that are special to various platforms and IDEs, such as .xib files and .storyboards, while keeping the basic feature generic enough to support new platforms, IDEs, and resource types in the future. How extensible is this to other file types on other platforms?
Since the .xcassets asset catalog format is a JSON-based documented format, there was discussion about whether it could be used for specifying resource variants (for all platforms). This would provide a standard way to specify variations, such as light vs dark mode, on all platforms that support such distinctions. This would require SwiftPM to be able to read the JSON files that are part of that format.
The next step will be to update the draft proposal with more details and alternatives, focusing on the specific goals that the feature needs to address.