Today’s progress is less about adding another playback feature and more about something just as important: making Fibich ready to become a real released app.

Recently I have been working through the licensing branch, and the shape of the release flow is finally becoming visible. Fibich now has the first serious pieces for license verification, activation state, update checks, release preparation, and the user-facing polish around all of that.

The licensing work started with offline license verification. That is important because a desktop music player should not feel helpless the moment it cannot reach a server. After activation, the app needs to be able to verify that a license is valid in a local, reliable way. The technical challenge is trust: Fibich has to know that the license data was really issued by the licensing system and was not simply edited by hand.

That led to a dedicated license model, error handling, a public-key verification path, and test vectors to prove that the verifier behaves correctly. This is one of those areas where tests matter a lot. A mistake in playback may be annoying. A mistake in licensing can lock out a legitimate user or accept something it should not.

The next step was connecting that licensing state to the app itself.

Fibich can now require activation and show the license owner once activated. That changes licensing from a hidden backend concern into part of the user experience. The app has to know whether it is activated, show the right screen when it is not, keep the main interface from pretending everything is ready too early, and still behave like a normal Mac app.

One small but important detail came from that: the app must still be able to quit while unlicensed. It sounds obvious, but modal activation flows can easily trap the user if they are not handled carefully. A licensing screen should protect the app, not make the app feel hostile.

There is also work around the update flow now. Fibich has the foundation for checking updates, verifying update metadata, preparing update feeds, and connecting that to the release process. I do not want to make the blog too much about the external services behind this, but the goal is clear: once Fibich is released, users should have a safe path to future versions.

That connects to the notarized release workflow added recently. Signing, notarization, stapling, verification, and packaging are not exciting product features, but they are part of what makes a macOS app trustworthy. A native Mac player should not only run on my machine. It should be deliverable to another user in a form macOS accepts cleanly.

The build number and version were bumped as part of that process too, which makes this feel less theoretical. Fibich is getting closer to a real versioned release rather than just a development build.

This week also included cleanup that belongs to the same phase. Debug-facing options are being removed from normal app menus, advanced descriptions are being simplified, and the new About Fibich section gives the app a more finished place for identity and version information. These are small details, but release polish is made of small details.

The hard part of this whole licensing and release phase is that many systems have to agree with each other.

The app has to understand license state. The license server has to issue something the app can verify. The activation experience has to be clear. Offline verification has to work. Updates have to be trusted. The release package has to be signed and notarized. Settings and menus have to feel like they belong in an app users can actually install.

None of that is as visible as CUE playback or playlist search, but it changes what Fibich is becoming.

It is no longer only a capable local hi-fi music player. It is getting very close to a complete working flow: install the app, activate it, use it, receive updates, and keep listening.

That is a big step toward release.