AppBundler.jl

I have quite a few gripes about the app structure while developing https://github.com/PeaceFounder/AppBundler.jl. The requirement (recommendation) to distribute shared libraries within the Frameworks folder, where each directory follows a strict structure, looks nice, but it’s a hassle to bundle the application that way. I am now using a Libraries folder to bypass this requirement, which appears during code signing. My biggest issue, though, is Apple code signing. It’s already enough that a signature is attached to every binary, which seems wasteful. Why would anyone consider it better than keeping hashes of each file in one place and attaching the signature to them? Then there are entitlements, which are attached to the launcher binary when signed. Why couldn’t these just be stored in `Info.plist` or a separate file, instead of requiring

> The release burden is, well, frankly, daunting for a small project. With its large user base, I would have expected Java to have figured out all the details and offered users a single command-line tool that automatically builds the project into installers. I had adventures with relatable pain points when figuring out how to distribute Julia's GUI applications. Another upcoming difficulty is transitioning to distributing applications that run in the sandbox. Windows has MSIX, Linux has Snap and Flatpack, and macOS has DMGs signed with entitlements. Each has its way of configuring and how it is expected to work, and debugging sandboxing issues is no fun. I made an application bundler specifically for Julia's MSIX, Snap, and DMG applications, which allows the use of the underlying configuration files when configuring the sandbox via a simp

An exciting release with my favourite feature of cache reliability. The arrival of this feature motivated me to making AppBundler.jl, which can bundle GUI applications into familiar installers found on major desktop platforms [1]. I will also enjoy using public keyword when working with submodules to keep APIs more organized. This could also allow to show a tree view of the module functions from `public` and `export` statements. The `[sources]` in Project.toml is useful feature when retrieving projects without a `Manifest.toml` file. A thing I found missing there, is the lack of integration with `Pkg.add` and `Pkg.dev`, where now I need to manually edit the file to keep those things persistent when `Manifest.toml` is not present. Hopefully, that can be improved with future releases. I did not understand the ScopedValues example utility. T