Just to make it clear: this is an ALPHA release, so bugs are definitely possible. If you run into anything, please feel free to message me or report it. I’m actively looking for testers to help uncover issues.
The application is also going to evolve quite a bit, especially in terms of UI/UX and general polish, so if you’re testing it, I’d recommend checking the repository from time to time for new releases.
I didn’t know about Seki Player before your message, it’s a shame we choosing the same name… However, regarding the resemblance between my goban and stones and those of Go Magic, it’s simply because I’m using the Go Magic theme for Sabaki
Usually, at this point, I can go to System Settings, then click Privacy & Security in the sidebar, then scroll down a bit to “Security”and click “Open Anyway”, but here I don’t see anything. (My setting is “Allow applications from App Store & Known Developers”.)
So… maybe the first time I accidentally downloaded the x64? But I’d think the Crash Report would tell you which version it was?
Anyway, now I cannot open the app (Right-click resp. control+click doesn’t work either, unsurprisingly.)
(I know that I could opening it with bypassing security stuff, I’d have to restart, boot into recovery mode and do some voodoo dance but I’m not going there.)
How about making it available through TestFlight?
whether Seki crashes immediately before showing a window, or after the UI appears
it was directly after launch, before showing me anything. But now I doubt that this information is worth anything
Thanks, this is very useful, and I think there are actually two separate macOS issues here.
The current alpha macOS builds are not signed/notarized with an Apple Developer ID yet, so Gatekeeper can reject them more aggressively than the usual “Open Anyway” case. That’s a distribution problem on my side, and I need to fix it.
So for now I would consider the macOS alpha package not properly distributable yet.
The crash from your first attempt is still very interesting, though. And yes: the crash report should normally tell us whether the executable was ARM64-native or x86_64/translated, so if you still have that report, I’d definitely like to see it, you can now create issue on this repo.
I also noticed the GitHub repository was incorrectly restricting issue creation — thanks for pointing that out. I’m fixing that setting so external testers can report bugs normally.
Regarding TestFlight: it’s technically possible for macOS apps, but for Seki I think the more appropriate first step is to properly sign and notarize the GitHub DMG builds so they can be downloaded and opened normally without bypassing macOS security. I’m working on the release pipeline now.
And good catch on the Go position in the app icon, it’s the Sabaki icon that I haven’t modified yet I’ll fix that as well.
I’d encourage you to set up TestFlight distribution sooner rather than later, if only because it includes automated crash report submission that doesn’t require users to open a GH Issue and paste in a crash dump.
Thanks for the suggestion about TestFlight, I looked into it.
For now, I’ve decided not to use TestFlight or Apple’s Developer ID signing/notarization process.
The reason is fairly simple: distributing a macOS application through those official Apple channels requires a paid Apple Developer membership. Seki is an open-source project, and at this stage I don’t want to pay a yearly fee just to make an open-source desktop application installable on macOS.
Unfortunately, that means unsigned macOS builds can be blocked by Gatekeeper, sometimes with misleading messages such as “the app is damaged”. I also don’t want to ask users to disable security features or use system-wide workarounds just to run Seki.
So my current plan is:
Windows and Linux will remain the primary prebuilt release platforms.
I’m going to stop presenting the unsigned macOS DMG as a normal supported release artifact.
I’ll keep the macOS build infrastructure around for development/testing, and I’ll still investigate genuine macOS crashes such as the one already reported.
macOS users who want to experiment may still be able to build Seki from source.
I may revisit proper macOS distribution later if the situation changes, for example if the project eventually has funding or another practical signing solution.
This is not a technical decision against macOS itself, it’s specifically about the distribution requirements.
Make it Donationware, and I’m sure you’ll soon have the money needed for notarization, and probably more, as macOS users usually are not cheapskates, and willing to pay for the privilege of having a (relatively) secure, stable, and easy to use system. At least that’s the case for myself and the Mac users I know.
I gave the donationware idea some more thought, and I think it actually makes sense for Seki.
I’ve now added an optional Ko-fi support link to the project. Seki will of course stay completely free and open source, with no features locked behind donations.
The first concrete funding goal is macOS: if community support can cover the roughly $100/year Apple Developer Program fee, I’ll reconsider official signed and notarized macOS builds.
So macOS isn’t gone for good, it’s just on hold for now.
Thanks for pushing back on this. I probably dismissed the idea a bit too quickly the first time around
(Right-click resp. control+click doesn’t work either, unsurprisingly.)
I’ll fix that as well.