We all know about the MacOS feature called Spaces, and many of us love splitting our projects, work, and hobbies across our virtual desktops.
What if you could not just assign a name to each Space but also trigger custom events for each one too? A fun and simple example of this is assigning a custom Internet radio station to each one. I wrote about that here, and suggest you skim over that first.
The simplest way to trigger events is in AppleScript itself. Here’s another basic explainer of how that works with CurrentKey Stats. When you change your Room, a file called “ck.scpt” will be called with the name of the new active Room.
From there, there’s a ton of cool stuff you can trigger via AppleScript. If you have greater ambitions than AppleScript automation, then this post is for you.
There are legitimate reasons why you may want to call out into something more powerful, like a Python script.
A quick aside: since you’re still reading this post and are clearly ambitious: CurrentKey also lets you fetch its stats and tell it to go to specific Rooms programmatically. Here’s a post about that.
Let’s talk about why you’d make a shell command from your ck.scpt file. Why? Because doing so means CurrentKey’s Room Change alerts can be a springboard for basically anything. Here, the shell command is to run a python script that writes the latest Room name to a file. Think of it as a “hello world” demo.
The comments in the files themselves tell you where they need to be placed. Once they’re in the right directories on your Mac, and you enable Room change alerts in your Background Services panel, the python script will be called with the Room name each time you change Spaces.
In the example ck.scpt file, you can substitute that command (which runs the python script) for any other shell command you can think of, and it should run it! Enjoy the power.
It finally felt like time to tackle a few ideas I’d been mulling for a long time for CurrentKey Stats. Here are links to a few resource pages on the new features:
I’m looking forward to improving CurrentKey Stats on a frequent basis. This release mainly focuses on new stats features, doubling the timespan of backup-able stats to 60 days, and doubling the hour-by-hour view to 4 weeks. Now, you can also toggle your custom (Space/Room-specific) emoji between appearing dimmer and brighter. This software is 100% free and is maintained as a labor of love.
What’s new in Version 2.7:
Debuts the ability to dim or brighten custom icons when you choose a “custom character” (emoji) for a specific Room.
Debuts a new report letting you back up 2 months of hour-by-hour stats data. Twice the previous limit!
Debuts a “Show next two weeks” button in the 2-weeks hour-by-hour view. So now you can easily compare 4 weeks of stats side-by-side, in very granular detail. Twice what you could before!
Adds better formatting for the Room Explorer: Now the buttons to jump directly to a Room are larger, and the entire row is clickable too.
Fixes several small and quirky bugs. The welcome window is prettier.
The day after Christmas this year I spotted some bugs in my app, I fixed them – I also added a cool new feature, and submitted the new build to the App Store for review as soon as the holiday downtime was over. Within a few hours, my app went into “In review” status. “Awesome!” I thought. My last submission’s review only took about an hour and a half.
A few days passed and it was still “In review”. Very strange, but maybe it was a backlog caused by christmas break. Regardless, in the meantime I had found some other changes I had wanted to make to the app, so I pulled that build from review and submitted a new one. Again, within a couple hours my app had gone into “In review” status. Then began an epic waiting game that continues to this day. I noted it for the first time here.
A break from development, but not on my terms
Three separate builds of my app have been stuck “In review” collectively since December 28th.
I’ve been on the phone 3 times with apple developer customer support reps, basically there is a firewall between anyone you’re on the phone with and the app review team, so I have no idea why. To be clear, during this time, the app has not been Rejected by the reviewers. I have requested an expedited review twice and have been told that it’s been escalated to higher-ups. At the 3 week mark of “in review”, i resubmitted the build and have been, again “in review” for a few days – despite escalating that review too.
A week ago I wrote a blog post outlining my concerns in more detail.
I have fixes for users. The App Store is not letting me push them. So, I’m pulling my app from the Store until the review completes. I’m also looking into distributing the app outside the store. What I found is that the updating-framework of choice, Sparkle, is in a transition period (about to go to a 2.x release). I’m going to wait until that dust has settled before releasing the app outside the store officially.
Despite this app getting approved over a dozen times, I have a bad feeling about what’s happening with my app and the store. With no real intel on this at all, I suspect it’s going to eventually get rejected for some new BS reason that all other builds of this app were approved for. But that’s just a hunch, let’s see how all of this shakes out.
Here is how it looked before I pulled it. So long, and thanks for all the fish! 🐬
If you care about getting this app, or getting updates to this app, please let @Apple and @AppleSupport know about your concerns. Thank you!
Needless to say, I haven’t been writing a lot of Swift code in the last month because of this app review logjam. That gave me time to reassess my opinion of technologies, projects, and platforms. Gatekeepers suck. My last post, Key takeaway from developing for the Mac App Store: it’s unreliable, got me permanently banned from reddit’s r/Apple community. Funnily enough, this post got unceremoniously deleted from r/Apple without explanation (after hitting #1 and getting 9.5K+ upvotes).
I don’t like permission to write opinions or serve software. That’s why my next project is going to be for the open web, a return my roots, in a sense.
To show that pulling my app wasn’t a capricious choice, here are some tweets showing a more complete timeline:
Last May I launched my Mac app, CurrentKey Stats, which helps you keep track of how you spend time across Spaces (virtual desktops) and apps, as well as navigate between your Spaces.
It was not always a foregone conclusion that I’d distribute the app through the App Store. In fact — I had round-tripped the entire stack for delivering outside the Store (including updates through Sparkle and serverside payments). In the end, I decided against it largely because of the friction caused by scary warnings from Chrome and MacOS for software downloaded from the internet (even if the software was notarized).
Note: this entire post probably only applies to the Mac App Store, not iOS App Store.
As someone who genuinely loves writing Swift code and making stuff, my relationship with Apple is important to my ability to continue doing what I love. Ultimately though, my responsibility is to advance what’s in my users’ interests, and – from my experience, when Apple is being slow, the most reliable way to speed them up is by taking your opinion public, so let me tell you the top pros and cons of developing for the Mac App Store.
Pro #1: Essentially free QA
A developer account costs $100/year to keep active, for that – you get a set of trained eyes to check that your app behaves as advertised. It’s not perfect, but it’s worth at least $100/year.
Pro #2: A big credibility boost in the eyes of customers
At several points over the course of developing the app, especially when I was targeting out-of-store distribution) friends made it clear to me they wouldn’t personally download apps from a website. This, coupled with the negative language from Chrome and Mac around website-delivered software made it a major factor. The ability to seamlessly push updates to users (vs a more cumbersome Sparkle method) means they’d come more frequently, which would also boost credibility (but… see Con #2).
Pro #3: Easier fulfillment/payments, at least in theory
Simply put: implementing your own fulfillment generally requires setting up server side logic for receipts and user accounts, which for a team of one – is a major time suck (I’d rather spend that time making my app better!). 30% is a major cut of sales, but theoretically it allows for a far smoother experience for the user (who doesn’t have to pull out a credit card or log in to PayPal, etc).
Con #1: Broken APIs burning developers
Example 1: My first experience of this came early and was flabbergasting. In 2018, Apple brought the Ask for Rating API to macOS. It’s a simple API call, taking no arguments (impossible to screw up). What’s supposed to happen is, when it’s called a box with “Enjoying CurrentKey Stats?” shows up with an option to click 1-5 stars and submit. Simple. What developers were finding was that it would ask “Enjoying (null)?”. So, precisely when devs wanted to ask users to rate their app, a bug would surface (not their fault but users didn’t know that). This stayed broken for over a month and was fixed only after the press reached out about it. The lack of urgency around fixing such a simple bug was disturbing to me.
Very poor timing for a bug!
Example 2: Unbelievably, fulfillment has been a mess. I implemented In-App-Purchases, and I’ve had as many complaints about StoreKit-related issues as any other thing about my app. From purchase restoration suddenly not working, to the simple inability to purchase the IAP — emails from users have steadily flowed in.
When you encounter bugs like this, there’s very little you can do — you are completely reliant on Apple to care enough. It got to the point where I just yanked out the IAPs and made it all free.
Con #2: Unreliable App Review process
I thought that it would be less cumbersome to deliver app updates through the App Store. I’m currently about three weeks into a very frustrating waiting game. On December 30 my app entered into the “In review” status. Never has my app taken longer than a couple days to review and usually just a few hours. My last approval came within a couple hours (and happened right before the holiday black out period that hits the App Store each year). I’ve expedited the review and talked to support reps and even had members of the press reach out to Apple, yet it’s still stuck and no real info has been given on why. Maybe the chairs are being shuffled over there, or it’s a small review team that took a long holiday break. But this has been very demotivating for me as far as continuing app development. Getting the app rejected would be way better. That’s not what this is, the app is just in purgatory and users aren’t getting bug fixes.
Con #3 lack of Mac App Store ads and affiliate links
In 2018, Apple removed its affiliate link program for iOS and Mac apps. It had given bloggers an incentive to cover new apps from the App Store. Since then, bloggers only have an affiliate business model around promoting apps from outside the App Store. You are, as a developer, beholden to the App Store review team to be featured in the Store, which is unreliable and not a healthy power dynamic.
Meanwhile, the Mac App Store does not let developers advertise in the store. This makes it even harder for a new app to get discovered.
Power users of CurrentKey have requested a faster way to jump to specific Rooms. Arguably setting hotkeys for specific Rooms (a feature since v1.6) will always be the fastest way, but otherwise, clicking the popover dropdown is too slow. [App Store link]
Enter Room Explorer, which displays to the left of the pop-up with a list of your Rooms, presenting quick info (last visited and usage time) and a button to take you to any of your assigned Rooms!
You can enable this feature in the Preferences pane of the app.
It’s that simple! You know how CurrentKey Stats already lets you add custom icons per your named Spaces. Well now you can add any character, including emoji. Enjoy! [App Store link]
Click in the popup to quickly go forward and back with daily stats summaries!Dark Mode comes to all the charts in the app too!More pretty dark graphs!2.0 lets you quickly swap a desktop’s Room assignment with another active Room.
In the spirit of John Siracusa’s posts about his OS X reviews, here are some stats. They don’t account for auto generated, 3rd party files, or media management scripts written to support the app:
45 .swift files
48 .xib files (Interface Builder documents)
41,419 total lines in Swift files (including comments)
10,924 lines in the largest Swift file
54 purchases of the Stats Plus upgrade (which has cost up to $10 but is now on sale for just $1!)
Small but quick updates VS bigger, less frequent updates
After getting back from my honeymoon I pushed a flurry of updates, averaging about one per week – from 1.1 through 1.9. I really enjoyed that! It was fun knowing that on any given week I could come up with an idea, bring it into reality, and push it to the apps’ users.
However, I noticed a few things: first (and most importantly for my app) the process of updating was (itself) somewhat disruptive to my power users.
Second: I found myself going primarily for low-hanging-fruit-type features because I knew I didn’t have the length of time necessary to do something super cool and new.
Finally, despite getting a ton of features pushed — no individual update stood out as particularly outstanding. This meant that none of those updates created buzz like the app had on launch day. Fun fact: no bloggers or journalists have written about the app.
All of this to say: with 2.0, I tried something new: a longer release cycle – where I could really reach with my code. Not only did that mean I got to ship very difficult-to-build things – but it meant I had time to experiment with extra deep-dive things that could yield results further down the road.
I think the sweet spot for releases is somewhere in the 4 to 8 weeks range. The caveat to this is of course, the inevitable fixing-issues updates, which will hopefully not be frequently needed.
What’s next? I have already round-tripped (got the proof of concept working for) the key tech in three of the next update’s headlining features. I’ll share more about what the upcoming changes are a couple weeks ahead of launching, on Twitter.
In version 1.8, CurrentKey Stats‘ “30-days” view gets some love. Now, as your stats pile up, you can see how each of the last four weeks measure up, with a total time spent number and downloadable report. [App Store link]
These are formal weekly (7-day) spans, and you can tell the app if you prefer that they start on Sunday or Monday.
Remember: you can filter these stats by Specific Room. So, if you wanted to see how long you spent in a space you called “Client #1” or “Recreation”, just toggle the Specific Room option in the bottom bar, and viola – everything updates accordingly. It’s slick!
