As you know, CurrentKey Stats helps you track how you’ve spent time across your apps. With version 1.7, Stats Plus users can now back up a month’s worth of hour-by-hour app stats (accurate down to the minute) for a 30 day time span. That’s powerful! Like all the dozen reports the app can generate, this one downloads as a .csv to your preferred location. [Homepage Link]
One of the most-requested features from CurrentKey Stats’ biggest fans (and earliest beta testers) has been: the ability to use hotkeys to jump to *specific* Rooms on your Mac (which are assigned to Spaces/virtual desktops). While users have been able to do this via the dropdown, with version 1.6, CurrentKey Stats gets a new “Rooms Manager”, which lets you assign hotkeys to Rooms. (If you aren’t familiar with the app, here is the link to the App Store, and here is the link to its main site.)
It may surprise you, but Macs already let you assign hotkeys to Spaces, so I had to offer something significantly different (and hopefully better than) that system to make it worth it (to me and users). The way the Mac’s native hotkey-for-Spaces system works is: you can add a “Control” + Number for the first, second, third space, and so on. So, with Apple’s system, you can add a “Control + 2” hotkey for the second space. While that’s awesome, (CurrentKey lets you do the same), here is how CurrentKey Stats improves on that:
Other features in the new “Rooms Manager” are in response to feedback from power users, giving them: the ability to merge two Rooms’ stats into just one Room, the ability to delete Rooms, and more.
Thanks everyone, I hope you continue to enjoy the app!
Since launching CurrentKey Stats, the strongest reaction to the app has been around its workflow management features. To celebrate that: all Spaces customization features in CurrentKey Stats are now free 🧙♂️ (many were previously an in app purchase). (Spaces are what Apple calls Macs’ virtual desktops found in Mission Control).
CurrentKey Stats allows you to give a persistent name to each of your Macs’ virtual desktops, and jump directly from one of them to another, by selecting their name from a dropdown. No other modern Mac app that I’ve found lets you do this!
CurrentKey lets you give each virtual desktop a unique menubar icon, so that you can know at a glance (as you’re swiping between them) which one you’re in. Today, for free: all CurrentKey users can add a unique color and border to each of their menubar icons, and now get access to 250+ new solid-art icons to choose from!
There has never been a better time to try CurrentKey Stats, please give it a shot – it’s a free download and has a privacy-first design! App Store link | Website link
Here’s a short one-minute video showing off the features described above, as well as: the “Room Stats” feature, which show you how you’ve spent time across your virtual desktops, and App Stats filtering by Room, to show you how you’ve spent time in apps, specifically by the Room you were in.
Finally, the video also shows off a new feature: the ability to quickly share your top-used apps of the day, with one click!
Every feature shown off in this video (and more) are completely free forever:
Quick note/disclaimer: This blog post is from a historically introverted solo hacker, who – aside from personal-use command line tools – has exclusively shipped web app projects until this app.
A long time ago I took a day in the library with my (still shiny new) mid-2011 Macbook Air and poked around Xcode with the intention of getting into app development. Objective-C’s bracket syntax was a pain and Interface Builder seemed too “magical” (why couldn’t everything be laid out programmatically like in HTML/CSS?). By the end of the day, my curiosity had been rerouted to (what were then) hot web technologies, probably Node, Coffeescript, or whatever was being talked about that week on Javascript Jabber.
That perceived friction made a lasting impression, and it wasn’t until I had an idea for a (weekend project) Mac app that I pushed through it. That idea came to me while I was exploring a few different web projects, each split into different Mac desktops (called Spaces). When I opened the lid of my laptop one evening I realized I was shuffling through browser tabs to reorient myself: which Space was I in? Only took a few seconds to find out, but I wanted an instant reference: Each Space should have a unique menubar icon! And a new side project was born. Within a couple of weeks I had a working prototype. (It was months later I decided to add app usage stats and ship it.)
As far as early resources went, a few one off blog posts for beginners really helped, like @Bgreenlee‘s https://footle.org/WeatherBar/. For round-tripping Swift concepts and tricks, I really enjoyed Bob the Developer’s articles https://blog.bobthedeveloper.io/. I lament that Bob’s writing has stopped, by the looks of it he has been really distracted by crypto. At times, Ray Wenderlich’s site came in handy. A common sense reminder: even tutorial code usually has onerous licensing/copyright terms, so only grok concepts and do your own implementations.
The resources listed above were indispensable in getting basic (but important) things running for the first time in Xcode. However, very quickly I was needing to go deeper than what had been written about on the web.
Online documentation for macOS (AppKit) app development is not much help, largely because of its spread-out nature. However, when accessed from within Xcode, by having the IDE’s autocomplete surface lists of attributes and functions directly on the object of interest, you have a nice way to discover things to tinker with. Sounds simple, but as a web developer who has stuck to text editors like Sublime (which I love), discovering API capabilities in this fashion was actually pretty fun, if slow going.
If you’re a web programmer, you’re in the Wild West. You just are. I’ve been to web dev conferences before, even around specific, opinionated languages like Ruby. Even at those, everyone skins the cat differently. That can be fun for the personal journey, but (for introverted me) it makes it hard to have productive conversations with strangers. So having a common set of tools and experiences actually opened doors here.
Pretty quickly I had found myself at a meetup (WeirdSwiftATX) asking about the trade-offs of the myriad ways to persist data. Everyone at the table had an opinion about each option. Amazing! Early on I also got a great recommendation on charting solutions, Vega.js, and knew I had some locals with whom I could commiserate if need-be. I’m going to give a talk at different meetup in a couple weeks, right around the time of WWDC, should be fun!
Although I had played around with Typescript, I’d never built any of my big web projects from soup-to-nuts with strongly typed languages. (I really like/d the pythonistic Coffeescript language, which meant I was trendy in 2013!) Without an extreme level of discipline (which I lack), projects written dynamic languages tend to be hard to refactor (and sometimes just understand after enough time has passed). At a very basic level, Swift’s predisposition toward using structs (and enums) sets you up for being productive in the long run.
My Mac app has passed that threshold in project complexity where I’m SO thankful to have left a trail of well-defined data structures along the way, they’re basically a form of useful (always correct) comments that kill painful type-check bugs. Glorious.
This was the first of a multi-part series on writing my first Swift app. Future parts will cover technical challenges, business model dilemmas, what it’s like launching in the App Store, and experiences from launch day. Thanks for reading! – Spencer
