building macOS application bundle

[kapitainsky]

Now when I think that macOS compiled application works it is time to make it proper macOS native application bundle.

At the moment binary is generated but when running with GUI it results with opening console (terminal) window - it is ok for debugging but not for normal use.

I have found the way to produce proper macOS style application bundle but in order to make it work I need macOS compatible icon file.

Could you please provide npbackup_icon.ico as ideally svg image format or at least 512x512 bitmap? This is what is required to create icns file. When I have svg or 512x512 bitmap I will create icns and finalize apple app build.

[deajan]

Don't forget that NPBackup is a GUI ... and CLI application.
If you remove the console, you won't get parameters to work anymore.
On Windows, I minimize the console. What will be the effect of creating an application bundle ? Will console arguments still work ?

[kapitainsky]

hmmm... good point. I have to think about it and do some experiments.

[kapitainsky]

OK I think we can forget about it for now.

However I think it would be better to have npbackup-cli and npbackup-gui as separate binaries.

GUI based app should be just GUI based app IMHO with all configuration and options done in UI. Most people expect to click at icon and start app.

[deajan]

I already have a "in program" separation of cli and gui somehow, but here's the problem:

On Windows, I use the GUI to create scheduled tasks, which obviously work as CLI.
Having two different executables will double the size of the distribution and duplicate code.

I'll think about it, maybe have the GUI program just call the CLI to do the actual work.

Until now, I've asked @kayhayen at Nuitka compiler if it would be possible to hide/lower the console window, but it's not as easy AFAIK. I've managed this for Windows, but not macOS.

[abhibeckert]

Mac developer here.

If you're going to bring this to the Mac, I would suggest doing it as a GUI app (the word "program" isn't used on the Mac - we use the term "app" for GUI programs and "tool" for CLI programs). Users need to know it's running - and they should be able to either click the icon in the dock or an icon in the top right menu bar to check the status of the latest backup (the icons should also change if backups failed, or just haven't run for a long time).

Most "background" GUI apps have a setting to enable/disable both the dock icon and the menu bar icon (you wouldn't be able to disable both, but they might both be enabled by default). Disabling the dock icon will also remove your app from the Command Tab app switcher. Most power users probably won't want visible there.

The CLI tool should be entirely separate - either a separate download or inside the bundle for the GUI app. It's pretty common these days for it to be a separate download.

You normally wouldn't compile much logic in the CLI. It should use XPC (or alternatively you could simply use HTTP) to talk to the GUI app. If the GUI isn't running, it should be launched when the CLI tool is run.

The CLI tool shouldn't be large - the one for Visual Studio Code is only a thousand bytes for example - and it's probably more complex than yours would need to be. You could probably just make it a 50 line shell script or something.

[kayhayen]

@deajan with an application bundle, you can choose console or not on macOS these days

[deajan]

@abhibeckert

Thanks for your Mac OS insight. But I'm not planning on full macos support since I don't own any mac.

You could probably just make it a 50 line shell script or something.
Not really portable. The goal is to run on most platforms.