Show HN: manage & give a persistent name to your Mac's virtual desktops (Spaces)
currentkey.com
currentkey.com
This app helps you track time spent across apps and virtual desktops on your Mac and is free in the store today. [0]
I'd be happy to answer any questions about the making of the app or macOS/AppKit development in general. This took about 12 months to complete, was my first Swift app (been programming other stuff, mostly web, for like 8 years) and originally started as a project focused solely on adding a unique icon for each virtual desktop (those things that Macs let you create in Mission Control, they call them Spaces). The project veered toward stats (which have way more mainstream appeal) about half way in -- so the end result is app stats which have rich context (which virtual desktop you were in you used them).
The business model has changed multiple times and landed on freemium via the App Store. Originally it was to be delivered outside the store, then it was going to have free trial, then, finally, freemium.
[0] - https://itunes.apple.com/us/app/currentkey-stats/id145622699...
One question: Did you have to modify or remove any features you wished to include in order to get accepted into the App store? For example, features that use private APIs?
Good luck on the launch.
I'll take your question in two parts:
Fortunately this app uses public APIs only, none of which are marked as deprecated (yay!). Because it's delivered via the store it's fully sandboxed and only needs a couple of (pretty pedestrian) entitlements
You never know until you submit to the store for review what will happen, and they ended up being completely cool and helpful. I did have a backup plan in place (i had round-tripped all that was needed for out-of-store distribution), but I'm really glad it didn't come to that.
This is my first Swift app, so maybe that has a lot to do with it, but I found macOS development requires "scavenger-hunt driven development", where you're literally using Xcode autocomplete to discover attributes and methods on system-provided objects. It's doable, but there's a lot of sleuthing involved and docs and tutorials can be a bit sparse.
Finally, the app did have to go through a couple rejections, but those were for missing some aspects of the Human Interface Guidelines, not the app's core functionality. All-in-all, by the time I launched, I think four versions of the app had been accepted (but not released to the public). (The first one was before I added in-app purchases, to test the waters)
First: I planned on delivering outside the Mac App Store. This involved updating via the Sparkle cocoapod framework and fulfillment through Stripe. What I found was that the whole process, from downloading and getting going to paying, was very high friction. Every middleman was scaring the potential user: Chrome would warn about the .zip file. MacOS would warn with a scary dialog (even if the app had been notarized). As someone who is wary of downloading apps off the internet, it crossed the line from what I would have done.
I'm also a one-man shop, so I was spending an inordinate amount of time working on fulfillment infrastructure, not improving the app itself. Enumerating other considerations: outside the store I'd have to know more about my user (a bad thing for me since I'm privacy-first), the long-term drain on resources (time and server costs) is higher, system complexity is way higher than through store.
You can always decide to launch outside the store at a later point in time if it's justified, and i've already round tripped the fulfillment process, so that wouldn't be too hard to roll out. All that said, I decided to target an App Store launch in early February.
Next up: I implemented Free Trial. Users would have 14 days to try the entire app for free, then have to make a decision. Ultimately, this also proved high-friction because Apple requires users to "Buy" (not "Get") the free trial as an in-app purchase before they could start using the app, which meant another ~90 seconds and potential confusion on the user's part before getting to try the app.
I landed on freemium for a few reasons: 1.) I know the basic free app can stand on its own as something users would enjoy, 2.) it was frictionless for users to get started, 3.) the install base would be higher because there's no "buying cliff", 4.) it allows me to package two completely different power user sets into distinct upgrades-and therefore, hopefully, capture more total value.