Day 6: Plumbing — Licensing, Updates, and Distribution

The theme for today is plumbing.

Namely, figuring out what plumbing needs to be built to handle things like:

  1. Free trials
  2. Licensing distribution
  3. Automatic updates

We dive into some of the details for this.

App

How should you handle distribution of a paid app?

This is kinda a philosophical question as much as it is a technical question.

Do you just eat the 30% cut from Apple and distribute through the app store? You may recall from yesterday, we don’t like this option.

Not doing so means we need to sort out some important — but unsexy — things. This is what we dub, plumbing.

It feels like plumbing because figuring it out feels like, well…I won’t say it here.

It’s not the same as working on a feature that you know will feel really nice once implemented. This is the type of stuff that makes us feel: make it stop, I don’t want to think about this anymore, I just want it to release my app.

But none the less we have to.

The key players in this whole thing are the Sparkle package (for handling automatic updates), railway (for hosting compiled releases), polar (for distributing licenses), and the user side instance of the app.

There’s a lot we thought about in terms of how we believe these players should communicate with each other, and we believe we have an executable plan for tomorrow…we hope. We may make changes but that depends on how executions goes tomorrow.

Today, was a day of planning and weighing our options. Tomorrow we execute and build.

Website

Today was the first day that the bulk of our changes weren’t ready to be deployed by the end of the night!

Mostly we’ve just been getting things ready: captchas, payments, and file serving.

We did push one change to the website; hybrid rendering. We were running into some issues using server-side rendering for the blog, so the site was statically generated for a while.

Today we switched to hybrid rendering (static site generation for the homepage and blog, but server-side rendering for everything else).

To test this change, I created a development environment in Railway, staged the changes there first, and then pushed them to the site.

It doesn’t really matter since we have zero users, but it was nice to try out that work flow.

You may be interested to know that switching from SSG to hybrid rendering seems to have increased our RAM usage from 19 MB to 46 MB.