:loudspeaker: Hi there, we've released Conveyor 1...

# feed

[mikehearn]

📢 Hi there, we've released Conveyor 13, the easy to use packaging tool that supports Compose for Desktop apps out of the box. Use it to package, sign and upload your app for all your supported platforms with one single command (no multiplatform CI or other complicated setups necessary). Smart online upgrades with delta updates support is automatically included.

New in 13:
• Support for signing Windows apps with Google Cloud and Azure HSMs.
• Now automatically detects and fixes the case where you've not supplied intermediate Windows signing certificates.
• Bug fixes and performance improvemets.
Additionally, since the last update I posted here we released Conveyor 12, which added an improved appearance including dark mode support to the generated download page and Windows installer, and ARM support for Windows and Linux (only when all your underlying native libs support it of course). There's also usability enhancements, e.g. we prevent you accidentally leaving out the <http://jdk.crypto.ec|jdk.crypto.ec> module now, to avoid mysterious failures in SSL after minifying the JDK using jlink.

https://conveyor.hydraulic.dev/13.0/

[Samuel Gammon]

This is very cool! We ship binaries for desktop OS and totally need this. I was wondering if I could ask just a few questions

1. I don't think we use the full Compose framework and Kotlin Native, we use GraalVM native image instead, would this be an issue?
2. What about installers? On Windows, msi, and on mac, pkg/dmg? These are a huge pain to build
Just curious and happy to give it a try or potentially contribute 🙂

[Samuel Gammon]

(Oh, I think I misread, is the generated download page for the user's binary or Conveyor? Maybe you answered question 2 already) @mikehearn

[mikehearn]

Interesting, I think you're the first I've encountered who are using native image. That's great! We did some experiments a while ago, documented here:

https://github.com/hydraulic-software/conveyor/discussions/66

The fixes mentioned in that thread are shipped as part of the product now, so such a config should work out of the box. It's not particularly pretty boilerplate, but especially if we start to get commercial users shipping with native-image we can improve that as it's not hard.

The outputs/package types are documented here: https://conveyor.hydraulic.dev/13.0/outputs/

The generated download page is for your program. See the sample apps linked to from here: https://conveyor.hydraulic.dev/13.0/sample-apps/

[Samuel Gammon]

Wow, dead on for what we need

[Samuel Gammon]

I wish I'd found this a few weeks ago before I wrote our deb/rpm release pipeline!

[mikehearn]

Unfortunately we don't support RPMs at the moment. DEBs+apt we do, though.

[Samuel Gammon]

Our product binary itself is free, but it has an upgrade path to Cloud services, so I think $45/mo is entirely fair. We could probably convert. 😄

[Samuel Gammon]

No worries on RPMs, we could keep that part of our pipeline anyway

[Samuel Gammon]

I'll ping you on Hydraulic's discord. Thanks for sharing! This is fantastic.

[mikehearn]

Sweet, glad you found this announcement helpful. I should remember to do them for every release! 🙂

[Anonymike]

Just mentioning here that I'm very happy to see tools like this and I have several native images I would like to package, particularly for deb, windows, mac, and in hopefully some other generic linux binary for other distros.

[Anonymike]

Side note...I would also love to know if there is a good process for using this with a golang build process.

[mikehearn]

@Anonymike We never tried Golang but it makes native binaries and we support those, so it should work. See the native (C++) tutorial. Of course it's not really C++ specific.

It makes tarballs for non-Debian based distros, but they don't update unfortunately. It's a weakness.

We keep getting more enquiries about native images. It's something we'll look at improving. Unfortunately the process for making them is still quite painful.

[Anonymike]

Thanks for the response @mikehearn. I'll be watching the project and let you know if we try out a go binary. I currently have a Kotlin project using Graalvm that I would like to set up and it currently runs caddy and starts a kotlin based web server on the JVM, so that's another one I'd like to use this for. Looking at the docs, it looks like there is a way to automate setting up a systemd service on linux but nothing for windows or mac for running a process as a service. Am I missing that or is it on the roadmap?

Perhaps I'm also misusing it a bit and its intended for GUI apps, but I would love to package up my service applications with nothing more than a task bar icon and sometimes I don't even need that. A lot of these tools provide background services or servers. I really appreciate you jumping out into the community and interacting with us on your work. I would not have found your product otherwise.

[mikehearn]

@Anonymike We don't explicitly support Windows or Mac background services. On Windows you could do it by adding some lines to your config, we'd have to figure out what those lines are, but Windows service support relies on COM and other Win32 native tech. On macOS you'd use a login item to start your regular GUI app.

It sounds like what you're trying to do is ship a desktop app that's actually a web server and then users browse to it locally? Have you considered using a small WebView in a window using e.g. JavaFX or JCEF? That way you wouldn't need the web server, which can at any rate hit oddness to do with opening local firewall ports and so on.

On Linux yes we support systemd services, and we use Conveyor actually to package and upgrade our own servers including some third party servers we use like TeamCity and Youtrack. Because I prefer it done that way to using Docker, basically. We did do some prototyping of improving support for servers so you could go like conveyor push and it'd package up the server with full systemd support, upload it to the remote machine(s) and then use apt to install it. The idea being that if you use native libraries it would resolve the needed dependencies from your distribution automatically, and then standard Debian stuff like unattended-upgrades and needs-restart can be used to keep your app patched.

BTW we've also considered in the past a new Conveyor mode where it makes a mini-Electron like thing for JVM apps for you. So then you could write your app as a KTor server or whatever, and think of it as being just like a web server, but we'd start up an embedded Chrome or WebView2 for you and route network requests in-process. From the user's POV it'd be a regular desktop app, from your POV it's a standard frontend/backend split except your "backend" runs in-process and can use OS-native APIs. The question is one of commercial demand.

[Anonymike]

We do a mix of things, but no they are not web apps intended to run locally (short of some which are development environments). We do hardware integrations, media encoding on varying machines, security services, and more this way and packaging it is a bit messy becuase of some of these platform specific things, which is why I ask. I do wish JCEF and thers were easier to work with to build UIs. Excited for compose desktop to get more performant and to find a cleaner wrapper for JCEF. To be clear, while some of these tools have an interface, the ability to have services is a requirement. I'm not as confident as to how its done on mac, but on windows there is a command for creating a service so being able to script on install / uninstall may be enough for us to get it done ourselves and be able to consider a move to conveyor. Admittedly, I'm not developing super typical use cases.

[mikehearn]

I see, that's interesting. It may be worth moving this discussion to the conveyor discord as it's getting not really kotlin specific. You can do it for Windows without needing any CLI tool invocations. You'd put something like this in your conveyor.conf :

app.windows.manifests.msix.extensions-xml = """
<desktop6:Extension Category="windows.service" EntryPoint="Windows.FullTrustApplication" Executable="YourProgram.exe">
    <desktop6:Service Name="Your Cool Service" StartAccount="localSystem" StartupType="auto"/>
</desktop6:Extension>
"""

And that would be sufficient. Note however a significant caveat: it doesn't work on Windows Server 2019 (it does in WS2022).

[mikehearn]

Alternatively you could simply set app.windows.start-on-login = true , but then you have a normal app that starts at login rather than a system service.

[mikehearn]

For macOS you would need to register from your code, you can't declaratively request to be started as a server IIRC. There is a library here that makes it trivial: https://github.com/sindresorhus/LaunchAtLogin-Modern

However you'd need a way to call into it from the JVM. Alternatively you could use the SMAppService API directly, assuming you target macOS 13+, there are Objective-C bridges for the JVM so you can do it all without native code. See here: https://developer.apple.com/documentation/servicemanagement/smappservice/3945412-mainappservice?changes=latest_minor&language=objc

[Anonymike]

Thanks @mikehearn Good stuff that we'll have to check out for sure! Once again, I appreciate you being so responsive to folks in the community here! I'll pass all this to my team. Windows Server in general, but 2019 specifically always seems to find a way to be a pain.