Discontinuing MacOS Releases

[vkbo]

I intend to stop providing DMG images for MacOS from 2.9 and on. There are several reasons for this, but the main one is maintainability as I have no way of testing that the images work (the 2.8 pre-release images were broken, and I only noticed by chance). The second reason is that the releases are not signed, so installing them is getting increasingly difficult due to Apple's extremely poor support or open source projects. Finally, I'm not sure there are that many MacOS users of novelWriter. I don't track usage in any way, so I can't really tell, but I almost never hear from users on Mac.

novelWriter can still be run on MacOS, and I will keep testing it and supporting the platform in the code. So anyone with a Python installation on MacOS will be able to run the PyPi package also on Mac. It's a very technical solution, but the DMG image also requires some technical skill to bypass the blockers, so not sure that makes much of a difference.

You can find the PyPi install instructions here: https://novelwriter.io/download/install_pypi.html

Apple is not likely to get less open source hostile in the future, so I don't really see a solution here. Similar issues on Windows were solved by a sponsor who came in an provided the necessary signing service, but on Windows it's at least possible to spin up a VM to test things. This is another thing Apple actively works to prevent.

For Apple releases to return, I think someone will need to pick up and handle those releases. Brew may be an option here too, but I won't be maintaining it.

Unless someone picks this up and takes over MacOS releases, the 2.8 release cycle will be the last to provide them. I will leave a guide for Mac users on the website, but no longer publish DMGs.

[abdoulbasith-coder]

I am one of the Mac users of novelwriter, I use it frequently. Very good software.

[vkbo]

Thank you. I just wanted to make it clear that novelWriter will continue to work on MacOS. I just won't be providing the DMG images any more. Unfortunately, that means it will need to be installed as a Python package in a pre-existing Python environment.

[mozillamonks]

Perhaps it would make sense to provide it only as a brew cask for macOS? Keeps it free from needing to package but lowers the barrier slightly.

[vkbo]

Yes, I've thought of that. But that's not something I can do, so someone would need to contribute and maintain that release feature.

[mxfur]

Good morning. I use MacOS and it seems that software such as NovelWriter could be right for me. I agree with installing from a *.WHL package, leaving the DMG aside. However, when I try to install (pip3 install *.whl), I get the following error: Error: Externally-Managed-Environment. What should I do? Thank you.

[vkbo]

I think it's complaining that you're not generating a virtual environment to run it in. It's the recommended way to install Python packages these days, and at least on Linux they've started to actively block you from installing Python packages on the system directly. There aren't any really good and user friendly ways to run Python-based desktop software directly because the whole Python tooling setup assumes you're installing packages because you're writing code. It's really annoying. You have to manually set up launchers, or you need to run via command line.

The uv tool has made this a little simpler because you can just run uvx novelwriter without permanently installing anything at all and it will set up a temporary virtual environment and install the software for you on the fly.

You can get uv from here: https://docs.astral.sh/uv/getting-started/installation/

It's a solid tool. We use it for work. I should probably update the website to recommend it.

[vkbo]

You can also try the pipx command instead. I've never used it, but it seems to do something similar: https://pipx.pypa.io/latest/installation/

Edit: pipx install novelwriter seems to work really well actually. I've updated the website to suggest this as the default option: https://novelwriter.io/download/install_pypi.html

[mozillamonks]

The pipx form works great; love that solution!

[tawseo]

That is indeed a very sad news, I use mac version, and picket it up due to easy sync between linux and mac.

[vkbo]

novelWriter should still work just fine on Mac when installed as a Python application in a Python environment (see here). I just won't supply the DMG files. Admittedly, setting up the Python environment isn't a good solution for non-technical people/non-developers.

What this project needs is someone who can maintain a Mac release. This is not something I'm currently able to do.

[tawseo]

I understand, and will try to do it on Mac from version 2.9.
But I'd also like to point out that your product deserves more credit. I think on Mac this is the best free writing tool for novels and books. In all fairness, it's arguably a top 3 writing tool for Mac overall, paid or free.
It is fantastic on Mac and Linux. I also set it up on Windows but hardly use it, as for some reason the Mac/Linux environment suits me more for writing, so I really didn't try the Windows version enough to give feedback.
The real unique feature is that it's cross-platform, and with a syncing tool or any drive, it syncs across all devices.
It is a real shame that you struggle to publish it on Mac. Ideally it deserves to be in the App Store.

[vkbo]

For Windows I have a sponsor that signs the installer for free. Since I can run Windows in a virtual machine, I can also test that it works as it should. I have neither of those for Mac, so that's essentially the problem. Apple is not even a little open source friendly. Neither is Microsoft to be honest, and they've gotten worse, but at least there I have a solution.

I can in principle keep building the DMGs, and they may or may not work, and you have to jump through all the hoops to allow them to run while unsigned, but that's a horrible user experience, so I just don't want to publish those on the website.

[tawseo]

Have you considered setting up a donation option? Something like GitHub Sponsors, Open Collective, or Ko-fi? Users who rely on novelWriter might be willing to contribute towards costs like Mac signing certificates or development time. Even small recurring donations from a handful of users can cover those expenses.
I think Linux is growing but still has a relatively small user base. MacBooks, on the other hand, are particularly popular with writers — the long battery life makes them ideal for writing away from the desk. An app with effortless Apple ecosystem support could become exponentially more popular.
I hope many people are ready, myself included, to contribute to someone who actually cares about creating a useful tool — rather than chasing unjustified profits.

[vkbo]

I've been running a Ko-Fi page for years. It's listed both here on the repo and on the website. It is barely breaking even with the current costs, but slowly improving. There's no room for expensive signing certificates at this time though. Neither do I own any Apple hardware, nor am I willing to spend that much of my own money on a device just to build this app. I have no use for a Mac myself.

I absolutely see the value in a proper Apple app release, but I am not the person to do it. I'm essentially looking for someone to handle it as a contribution. Someone contributed the current build script, but since I cannot sign the DMGs, nor test them, I'm not comfortable releasing them myself.

[markiehill]

I will sponsor the developer licence that would be needed and happy to work on the releases for the time being, hopefully if we have enough interested people we could form a little virtual team so it is sustainable.

[dm807cam]

As for app signing, I've got this working on my fork and successfully signed a release. One caveat: generating the required .p12 certificate requires a Mac, as it's done through Keychain Access. I'm not aware of a workaround for this. Once created the certs live in Github Secret Store but there seems to be no other way to generate the cert.

I see, so I'd be stuck anyway.

If you can maintain a working build workflow for Mac, then I'm happy with that as a solution. Thanks for setting that up. It would be good to have those build scripts merged back into the main repo though.

The next question, then, is how to automate this as safely as possible. I should not have access to your secrets, so one solution is to make parallel releases on your fork when the upstream makes releases. I know how to set up trigger jobs across repos, but it requires some coordination and exchange of scoped tokens. Otherwise, I can always ping you when there is a new release, and you can trigger it manually.

The novelwriter.io repo has tooling to generate new download links and pages from release artifacts. It is not a problem if the DMG release is delayed as I can just re-generate the links when it is. I'm considering redesigning these pages to better allow for delayed releases. Maybe this is a good time to do that. If releases are tagged the same way, I can even set it up to link to the artifacts on your fork and list it as a contributed release.

The novelwriter.io tooling expects there to be a shasum file with each release artifact though. I see you added it for one of the artifacts.

Anyway, most of this can be automated I think, if you prefer that. Otherwise, manual releases is fine too as long as you are up for it. In the past, the challenge has been that people stop updating after a while.

I see three options if you don't want to purchase a Mac. ;)

1. Unofficial build on a fork repo on every release (perhaps you want to link to it from the release page)
2. Semi-official build on a fork repo and if you provide a fine-grained access token the DMG + sha artefact can be uploaded automatically to the release on the main repo
3. The project moves from personal to organisation and you invite the macOS maintainer as a team member to set up the secrets

As for maintaining this. I am very happy to work on the Github Workflows but my developer license is going to run out in a few months and I have no intention to renew it. 99€ is quite a mouthful for just signing an application IMO. Especially since it doesn't really provide much benefit to the user other than eliminating the need to "allow" an unsigned application to run on the Mac. From what I understood @markiehill offered to sponsor the license, so if that is still the case , I am happy to support where I can.

[markiehill]

I wasn't trying to discourage you from taken on this project. Just wanted to provide what I had set up already. Please keep working on this.

Not at all - it's fine but if you have the GitHub actions skills that I don't it would make sense for you to work on those pieces if your happy :) I am happy to run / maintain the build and provide my signing keys etc and keep the developer account active and contribute once you have something your happy with. Divide and conquer ! Just let me know what you're comfortable to do.

[vkbo]

2. Semi-official build on a fork repo and if you provide a fine-grained access token the DMG + sha artefact can be uploaded automatically to the release on the main repo

I was more thinking along the lines of the release on GitHub triggering a subsequent release branch update and auto-release on the fork. This would solve the issue with a delayed release and the need to manually notify the person owning the fork.

3. The project moves from personal to organisation and you invite the macOS maintainer as a team member to set up the secrets

I've considered this. It hasn't been necessary yet since there have been no frequent contributors with the experience to join at that level, but it is certainly an option. I have an org set up already just in case.

As for maintaining this. I am very happy to work on the Github Workflows but my developer license is going to run out in a few months and I have no intention to renew it. 99€ is quite a mouthful for just signing an application IMO. Especially since it doesn't really provide much benefit to the user other than eliminating the need to "allow" an unsigned application to run on the Mac. From what I understood @markiehill offered to sponsor the license, so if that is still the case , I am happy to support where I can.

Sure. Once the setup is there, it's easy enough to make it work on @markiehill's fork too. That's partially why I'd like the working workflows to be merged back into the main repo.

I'm fine with linking contributed artifacts on the website as long as the build is public and auditable, and the download is marked as a contribution for the sake of transparency to the users (which will require a redesign of the website as mentioned).

[dm807cam]

@markiehill @vkbo here is a draft PR: Perhaps we direct our discussion into the PR? #2747

[vkbo]

Ok, I'm back from a longer absence than I expected. Mostly due to work, responsibilities and family stuff. I have some time now, and I'm also planning to do a 26.1.1 release very soon. I have some vacation time coming up in a couple of weeks too.

I'm a little uncertain on how to handle the signing flow still, but I'll re-read the discussion and see where we're at. It would be good to complete this. I also want to look into updating the Windows build and maybe even add Flatpak for Linux.