Category: maker stories

Categories
CurrentKey Stats maker stories

[Updated: it’s been approved] Why is CurrentKey Stats not in the App Store? Because it’s been stuck in app review purgatory for weeks.

Update: CurrentKey got approved.

https://twitter.com/SpencerDailey/status/1220142841185341440

The story:

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!

[App Store link]

During the downtime, I got to thinking

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:

https://twitter.com/SpencerDailey/status/1213234878633955329
https://twitter.com/SpencerDailey/status/1213928017992585218
https://twitter.com/SpencerDailey/status/1214957569606914049
https://twitter.com/SpencerDailey/status/1215327385962328064
https://twitter.com/SpencerDailey/status/1217601863312429059
https://twitter.com/SpencerDailey/status/1220029183088304129
https://twitter.com/SpencerDailey/status/1220134256397164545

Categories
CurrentKey Stats maker stories product thoughts

Key takeaway from developing for the Mac App Store: it’s unreliable

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.

Categories
CurrentKey Stats maker stories

Building my first Swift app, from a background of web app hacking

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.

Scavenger hunt driven development

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.

Community

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!

Strongly-typed goodness

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