Swift Package Collections Manager Beta app ready for testing

Manage package collections for Swift from a Mac desktop app. Generate, validate, sign and diff your package collections from a single GUI.

This is a beta app and needs to be thoroughly tested. Please let me know how it performs from install all the way through to performing its core functionality of generating, validating, signing and diff'ing Swift Package Collections.

Download here:

Please post issues, comments, etc here: https://github.com/frios/Swift-Package-Collections-Manager/issues


Perfect: I’ve made a personal Collection for myself, and something like this will help a lot with maintaining it.

1 Like

I have not tried the app itself, but I do have a comment on the installation process:

In my experience, it's rather unusual to distribute an app in a pkg. Since installing a pkg requires admin privileges, and what is installed from it can also gain admin privileges, they are usually used for things that require root to install or run, neither of which should be the case here.

I don't mean to imply any sinister motives on your part, but the fact that the app is installed via pkg, combined with the missing source code (or is it just meant to remain closed-source?), means I would be wary to install this in anything but a VM, unless it was already rather well established and provided some crucial functionality that isn't available elsewhere.

The usual way to distribute an app would be either a simple zip or a dmg, neither of which require root privileges.

Digging through the pkg I also noticed the app weighs a rather heavy 170mb due to the embedded binaries. There might be some opportunity to slim those down, but the lowest hanging fruit is that the binaries seem to be duplicated:

Package\ Collections\ Manager.app/
└── [ 256]  Contents
    β”œβ”€β”€ [1.7K]  CodeResources
    β”œβ”€β”€ [2.2K]  Info.plist
    β”œβ”€β”€ [ 128]  MacOS
    β”‚   β”œβ”€β”€ [999K]  Package\ Collections\ Manager
    β”‚   └── [ 192]  package-collection
    β”‚       β”œβ”€β”€ [ 20M]  package-collection-diff
    β”‚       β”œβ”€β”€ [ 21M]  package-collection-generate
    β”‚       β”œβ”€β”€ [ 20M]  package-collection-sign
    β”‚       └── [ 20M]  package-collection-validate
    β”œβ”€β”€ [   8]  PkgInfo
    β”œβ”€β”€ [ 288]  Resources
    β”‚   β”œβ”€β”€ [  96]  About_App_About_App.bundle
    β”‚   β”‚   └── [ 128]  Contents
    β”‚   β”‚       β”œβ”€β”€ [1.1K]  Info.plist
    β”‚   β”‚       └── [  96]  Resources
    β”‚   β”‚           └── [116K]  Assets.car
    β”‚   β”œβ”€β”€ [ 24K]  AppIcon.icns
    β”‚   β”œβ”€β”€ [131K]  Assets.car
    β”‚   β”œβ”€β”€ [ 20M]  package-collection-diff
    β”‚   β”œβ”€β”€ [ 21M]  package-collection-generate
    β”‚   β”œβ”€β”€ [ 20M]  package-collection-sign
    β”‚   └── [ 20M]  package-collection-validate
    └── [  96]  _CodeSignature
        └── [6.4K]  CodeResources

Thank you for that feedback. I did not realize that there was a difference between dmg and pkg in that regard. Also, I will look into the duplication of those binaries. This is exactly the kind of feedback I need as this is the first non-app store app I have distributed.

Also, the app and installer are Notarized by Apple so that should alleviate some stress of installing an unknown app. For what it’s worth.

1 Like

Update has been uploaded that changes the installer from .pkg to .dmg. Additionally, it removes the replicated command line tools from the resources folder.

1 Like

A disk image is analogous to a folder (or disk, as the name implies). If you just want to provide an application bundle, that’s all you need.

A package (that is, Installer packages) are basically dedicated installation programs meant to work with the Installer app. This can accomplish pretty much anything, but generally requires admin rights as a result.

For obvious reasons, moving an application bundle from a disk image to the system Applications folder will also require admin rights, but whether to do so is up to the user.

One more thing: like Swift packages, I highly recommend adopting SemVer. Start with 0.y.z releases, since this isn’t ready for primetime yet.

While not yet part of the spec, I recommend applying a further rule: only have breaking changes in 0.0.z, 0.y.0, and x.0.0 versions. If you expect every single update to be breaking, keep it in 0.0.z. Once it achieves a modicum of stability, such that some updates may just be new features or bug fixes, update to 0.1.0. Once you think it is ready, move to 1.0.0.

You can also use the prerelease identifiers and such as you see fit.

Great! Thanks. Will do that.