The work and times of the app development team at Steamclock.
Archive (31) RSS Feed @steamclocksw
Allen Pike • September 17, 2019
Fairly often, our clients ask if we should include a “Rate this App” function in their iOS apps. The simple answer is yes – a healthy stream of ratings and reviews is a great thing for increasing downloads of your app.
However, there are enough subtle pitfalls around the relevant APIs and App Store Guidelines that it can be easy to get this wrong. Conversations about app ratings often devolve into debates about what Apple will or won’t allow, and it’s hard to remember the exact details and limitations.
So, for your reference and possible enjoyment: the dos and don’ts of iOS app rating functionality in 2019.
There are two ways a user can leave a rating in an iOS app. The ideal way is the in-app star rating dialog available in iOS 10.3 and later. Using the SKStoreReviewController API, your app can request that iOS show this prompt.
This is a nice way to let users rate your app, and in most aspects is the best way. However, this API has one serious caveat: an app can’t always show this prompt, it can only request it to be shown. If your app has shown this prompt 3 times in the last year, or your customer has turned off review prompts on their device, then nothing will happen when you request this prompt.
Sometimes, not showing a prompt is totally fine. In the case of a “drive-by” request for a rating, the user won’t notice or care if the prompt doesn’t show. However, it’s a serious problem if somebody taps a button that says “Rate this app” and nothing happens. If you’d like users who are browsing your Settings or More page to have the option of rating your app – which you would like, since it’s good for your business – you need to wire up a button that reliably works.
Given that, in cases like this where you’re reacting to a user tap, developers need to use the older rating mechanism: loading a review page in the App Store app. This requires using the
itms-apps:// URL for your app, which jumps users out to write a review.
The App Store link is a reliable mechanism, but it has two serious downsides:
These downsides make many developers hesitant to use the older functionality, even though it’s the only way currently (as of iOS 13) to add a reliable button that lets users rate your app.
Luckily, Apple’s App Review has consistently respected the difference between a “prompt” for ratings where users are interrupted – in which case Apple expects us to use the throttled in-app dialog – and a user-initiated choice to rate, where jumping to the App Store is fine. Countless apps continue to successfully use the
itms-apps:// flow to enable a “Rate our app” function without raising the ire of App Review, and all is well.
Beyond the routine practice of wiring up a simple “Rate this app” function that goes to the App Store, there are some more advanced approaches to streamlining how users are asked for reviews. These may may make sense for your app, depending on your business and how willing you are to risk running afoul of the App Review Guidelines.
If you want to offer a “Rate this app” button but still want the nicer UX of the in-app dialog, you can take the clever approach that Overcast does: the first time a user taps the button, they use
SKStoreReviewController to request a review prompt, which might do nothing, but will usually work. If a user taps again, they jump out to the App Store review page which always works.
You could go a bit further with this by tracking if you’ve called for the review prompt 3 times in the last year, switching between the two APIs as needed, and maintaining this logic if Apple changes the review prompt throttling in the future. Even with the simple dual approach described above though, your users will get the nicer UX most of the time, but still minimize the cases where your “Leave a rating” button feels broken.
If you’re willing to interrupt users with an unexpected rating prompt, it’s worth putting serious consideration into when you want to do this – and how frequently you want to bother people.
The common-sense approach is to only prompt a user for a rating once it seems likely your app has delivered them real value. Usually you want to wait until they’ve used the app multiple times, and had a modicum of success exercising its features.
In terms of frequency, although you can in theory prompt 3 times a year, it’s worth seriously considering if you dial that back, resulting in less annoyed customers and thus more positive ratings when people do see a prompt.
A lot of larger apps, especially SaaS products, will add a custom prompt along the lines of, “Are you enjoying this app?” This can be great for detecting unhappy customers and directing them to customer care to help turn them into happy customers, and it also lets you encourage happy users to rate or review the app on the App Store.
The danger here, however, is that Apple is almost certainly not fond of apps only asking happy users for reviews. This behaviour could easily be construed as a “custom review prompt” as barred by the App Review Guidelines, or more seriously could be considered “manipulating reviews,” which is a bannable offence. From the Guidelines (emphasis mine):
If we find that you have attempted to manipulate reviews, inflate your chart rankings with paid, incentivized, filtered, or fake feedback, or engage with third-party services to do so on your behalf, we will take steps to preserve the integrity of the App Store, which may include expelling you from the Developer Program.
While we have not heard of an app getting banned or even rejected by App Review for only asking happy customers for reviews, doing so would be well within the wording of the guidelines and is the kind of sudden policy change App Review has made in the past.
On the other hand, this would be a hard thing to enforce – while a reviewer might be able to catch some very linear conditional-review flows, it would be fairly easy for an app to simply take note of happy and unhappy users and later “randomly” prompt just the happy ones for reviews.
Overall, our current recommendation on conditional review prompts is to tread carefully and thoughtfully.
Although letting people rate your app seems like a minor consideration, a tiny detail to stick in Settings in the run-up to 1.0, there is actually a lot of thought and consideration that can go into good rating flows. If you’re in the thick of getting an app shipped you may not want to get bogged down in all the ins and outs of this, but once your app is live and you’re working to scale your user base, refining these rating flows can be a great way to spread the word of your app and what makes it great.
Allen Pike • May 10, 2019
While our growth at Steamclock is typically slow and steady, we’ve had a record spring season with a lot of interesting client and internal projects on the go.
Given that, we have openings right now for two – two! – app developers here in Vancouver:
In both cases we’re looking for folks who have experience making nice native apps, and care about the human side of software development. If you’re an experienced app developer in Vancouver that shares our values of creating great experiences, continually iterating, and investing in people, then get in touch!
Brady Valentino • March 29, 2019
There are advantages to working in the same office as your team. Sometimes it’s great to just walk over to a coworker’s desk and answer a question or hash something out. Still, there has been a slow and steady shift taking place: more and more companies are moving towards remote work. Before joining Steamclock last year, I experienced this first-hand: I worked from home full time for more than a year. Toward the end I was given a chance to summarize my thoughts on this working setup:
Working remotely allows the freedom to set my own schedule and to work in the environment best suited to my workflow. Some days it’s my home office, others it’s a coffee shop, and once in a while it’s on the couch with Grey’s Anatomy on in the background.
This still rings mostly true; although I’ve since switched from Grey’s Anatomy to The Sopranos. However, it does brush over the downsides that can come with remote work – in my experience, distractions and losing focus.
Although we mostly work in the same office at Steamclock, we do observe Work From Home Wednesdays™. It’s a special day of the week where most of the team chooses to work remotely. Based on that experience, I’d like to share my preferred approach of working from a home office, and how you can make it awesome.
The key question when working remotely is: “How do I stay fresh and limit distractions while working untethered?”
Enter Brady’s Code for Surviving Your Home Office:
Let’s take a look at these one by one.
It’s important to be aware of what kind of workspace works best for you. Try completing this sentence: “My workspace should be x, y, and z.”
For me, my workspace should be simple, functional, and bring joy.
Let’s break down what makes a workspace optimal for me:
I keep my desktop to just the basics of what’s needed to accomplish my tasks — simple and free of clutter.
The cleaner your desktop is, the more space you have for the items you actually need to be productive. For example, a designer may need space for a drawing tablet, or a writer may need space for a large clickity-clacky keyboard.
Many people use this as an opportunity for a photo of a loved one. For me personally, it’s some juggling balls and a cute piggy succulent planter — but feel free to choose the cute succulent planter that works for you.
An obvious goal, but how should you go about it?
Take a moment to name the things off the top of your head that could pull focus from your daily tasks. TV? A game console? Spouse? Pets? Lack of a Bill Lumbergh type peering over your shoulder to ensure you’re working hard?
Reducing these distractions my be easier said than done, but I’ve found that noise-cancelling headphones and plenty of natural light help me stay focused on my display rather than being drawn towards the Apple TV remote or Xbox controller.
There are plenty of scientific studies showing that light snacking throughout the day is better than eating several large meals at pre-determined times. While this may seem obvious for your health, it also does wonders for mental clarity. Keep it light and healthy as much as possible. Set aside the chips with soda combo, and instead reach for some fruit with water.
My go-to snacks at home are mandarin oranges, or carrots with hummus. A little goes a long way.
Don’t be afraid to step away from your desk. Keep your head clear and your mental acuity will stay sharp. I like to use a variation of the Pomodoro Technique:
The official Pomodoro technique recommends working in bursts of 25 minutes, with a short break after each burst, and then a longer break after 4 bursts. Personally I’ve found myself to be more productive when working in bursts 45 minutes with 15 minute breaks.
It will take a few tries to find the balance that works best for you, but the key thing is not to underestimate the importance of giving your mind a break.
While it’s important to give yourself breaks, it can be all too easy to brush your tasks aside when surrounded by the comforts of home. Staying mindful should help you keep not just a positive headspace, but a productive one too.
So follow my code: use your workspace as a canvas for self expression, focus on being the best you that you can be, get a cute succulent planter, and watch as your productivity reaches new heights. Of course, in the immortal words of Captain Barbossa:
Allen Pike • February 21, 2019
In what could have been a Steamclock blog post, I recently wrote an article on why for new apps, navigation should be boring:
With a delightfully boring navigation scheme, users don’t need to learn how to explore your app. Their “attention span budget” can thus be spent considering how your new thing can fit into their lives, rather than trying to recall how many fingers they’re supposed to drag from the left side of the screen in order to pull out the Alternate Quick Access Wheel.
As fun as designing novel navigation schemes may be, there a lot of better ways to make a new app distinctive and appealing.
Allen Pike • January 7, 2019
Today we’re launching a new Mac app called Quests for tracking issues and pull requests in your menu bar. Here’s how it came to be.
At Steamclock, we work on a variety of projects at once. Between client projects, open source libraries, and internal labs projects – across iOS, Android, Mac, and the web – we have quite a few repositories and issue trackers going around.
We’re also fans of code review. That means team members sometimes review pull requests for projects that they’re not otherwise working on. Code review is a great way to improve quality and reduce the “bus factor” of projects, but it definitely creates more pull requests and issue traffic.
As a result, our pull request and issue notification emails can get rather noisy. Each of us works across multiple repositories, and often even multiple issue trackers or source control systems. At a certain volume, issues or pull requests can get lost in the shuffle, which can really sap a team’s velocity.
So, we thought it’d be nice if you could easily see the pull requests and issues assigned to you. Maybe right up there in your Mac’s menu bar. So we built that, and turns out: it is nice. We called this little app Quests.
At Steamclock we love to iterate, refine, polish, and add to a product until it’s beautiful and exceptional. With Quests, we challenged ourselves instead to ship it, and then polish it to its full potential beauty.
So we have plans for how we’d like Quests to look, and future subscription features that would let us add additional source control and issue tracking systems beyond GitHub.com and GitLab.com. But today, Quests is useful. Almost everybody at Steamclock uses it already.
So today, Quests is available for free on the Mac App Store. If you think it could be useful to you, try it out. If it is useful to you, let us know!