Currently we have a "bundle" module, which, on Apple platforms, allows users to create "packaged" products. Application executables correspond to application bundles, shared and static libraries correspond to frameworks, and plugins correspond to plugin bundles. All of these bundles are implemented as a directory structure on the filesystem.
However, other platforms have the concept of packaged products as well. On Android we have APKs (application package), which are specially structured ZIP files. We also have AARs, which package together native shared libraries with Java code and resources - also implemented as specially structured ZIP files.
In the Universal Windows Platform, there is also APPX packages, which again are specially structured ZIP files.
Currently, we create "packaged" products on Apple platforms by expressing a dependency on the bundle module. An application executable gets "upgraded" to an app bundle, a shared library to a framework, etc. On Android, the situation is a bit different - we have a dedicated AndroidApk product type, which is necessary because native code must be packaged into shared libraries - typical Android apps cannot use actual ELF executables since (as far as I can tell) you need root to actually execute them.
So all this culminates into the big question: should we try to abstract "package" products to be handled in a central way, so that users can create a shared library project which automatically becomes a framework on Apple, an AAR on Android, and a normal shared library on other platforms, and so that users can create an app project which automatically becomes an app bundle on Apple and UWP, an APK on Android, and a native executable on other platforms?
Should we introduce an apk module and appx module, and then have a "package" module which depends on bundle, apk, or appx depending on the platform? Should we re-use and abstract "bundle" across these three platforms?
Qbs should be both easy to use and powerful. We should provide access to the underlying platform functionality while at the same time not requiring a ton of boilerplate to get a simple app running on the three major app platforms: UWP, Android, and Apple.
Please offer your thoughts in the comments.