That’s a valid concern, but Pakkly has never and never will modify your app. It will be installed exactly as-is, with a proxy launcher to facilitate updates. I’m also working on getting that launcher PGP signed so you can verify it’s from us.

> Pakkly (…) never will modify your app.

Realistically, are you able to make that promise? In practice that would mean you could never sell the company, because current promises go out the window in that scenario (see every company acquired by Facebook).

I haven’t used Sparkle myself so I may be a bit off, but as far as I can see Sparkle requires you to constantly update an xml file so it knows what to update. Pakkly allows you to specify a glob to search for in the releases area. So you can simply target myapp_mac_*.zip and your users will automatically be updated when they next start the app. Notarization is a process I’m planning to integrate via a CLI, if possible.

Also, it’s cross platform, if you ever decide to branch out :)

It uses fairly standard HTTPS for update checking (endpoints). I'm planning to write a detailed blog post on how it works technically so hopefully that will answer your questions.

Completely self-hosted solutions aren't currently planned.

Yes, but cross platform and works with any app. A paid plan is coming soon so it won't only be for FOSS.

Currently there’s have no way of generating checksums or cryptographic signatures as Pakkly doesn’t enforce any structure on apps. They are delivered straight from GitHub releases so the security considerations are the same as downloading from a browser.

I’m developing a CLI tool to allow signing and notarizing your apps and the installer itself. Hopefully that will alleviate some of the concerns you have.

The third-party service angle is understandable, but I’m not certain how it’s any different from any other third-party service.

Yeah, to be honest I just wanted to get this out ASAP to see what people’s reaction would be. Currently that means it only serves direct downloads from https://github.com .

Currently the roadmap looks like:

Add macOS/Linux support with full signing on macOS and Windows. Add hosted binaries and private repos. Add cryptographic signatures both on the developer side and on our side. These are obviously not enough for total opsec, but should mitigate common attack vectors.

But as you said, the intention is to make the process as seamless as possible, that takes some design time though.

A more technical description is coming soon! I’m planning to post a blog post to provide transparency on how the system works. I hope that will clear things up and I hope you will like it ;)

Yes, you are correct, Pakkly adds a thin wrapper to your executable which is built with Rust to be as lightweight and fast as possible. This wrapper adds virtually no overhead besides taking up a bit of memory (around 8mb).

Update checking only happens on startup, currently. Your app performance will not be affected. In case the server is not responding during startup Pakkly will continue, after a brief delay, executing your app. The startup update check will fire at most once every 60 seconds (In case someone starts your app in quick succession).

Update notifications are planned, but these will be optional, and will never stop your app for you.

Kids these days - calling 8mb “a bit of memory” :) (yes indeed it’s not that much these days but I remember when 8mb was enough to run a multitasking OS with a ton of high-end applications.

That particular figure makes me think of the derisive backronym for emacs ("Eight megabytes and constantly swapping").

(Long-time emacs user here)

back then IT was not the workhorse of 95% of modern life, and only a handful of physicists needed computers for very niche usecases that needed next to nothing in resources

You can run a fully functional voip and chat client within that order of magnitude (Ripcord) whereas the 'real client' (Discord) doing the same thing is 10x that.

Don't downplay the resource wastes on nothing of value.

I'd understand if this were about something taking half a giga of ram like too many applications do nowadays. But this is a wrapper adding 8mb of ram. Your efforts should be re-directed somewhere else.

The pricing hasn't yet been finalized but it will be fixed per app.

I would post something up as soon as you can. You're front page of Hacker News but right now no one with a commercial app can really think about using it without some sense of pricing.

You can always change it later. Call it introductory pricing or something.

I'm hesitant to share my personal email publicly, but you can contact me at contact@enatik.com and I will get back to you ASAP.