
Show HN: manage & give a persistent name to your Mac's virtual desktops (Spaces) - spenvo
https://currentkey.com/
======
spenvo
Hi! Dev/maker here,

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...](https://itunes.apple.com/us/app/currentkey-
stats/id1456226992)

~~~
mthoms
Nice work, it looks quite useful.

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.

~~~
spenvo
Thank you!

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)

~~~
mthoms
Thanks for the reply. I'm currently learning XCode+Swift and finding out about
the "scavenger-hunt driven development" that you perfectly described.

------
Patrick462
I'd be interested to hear the reasons behind each switch of the business
model.

~~~
spenvo
Sure. Each of these false starts were implemented before being abandoned.
D'oh.

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.

