For a decade iKana and iKanji touch (yeah it’s been that long!) have generally enjoyed really good search rankings on the App Store. For pretty much any combination of relevant search terms they would show up within the top 10-20 results. For all those years my apps have enjoyed 4-5 star overall ratings and seen regular updates.
Then something went wrong. I’m not entirely sure when exactly, as the effect has been gradual rather than overnight and I have to admit I’d not previously really kept a close eye on my rankings because they’d always been fine and for the past couple of years contract work has been my major focus. But over the last year or so it seems both apps have slid down (and down) the rankings until the point where they’ve become so buried I’ve started to regularly see days with low single digit, or even zero sales. When you’ve been selling apps for a decade and had previously been able to count on one hand the number of days you’ve had zero sales this sets alarm bells ringing very loudly.
It’s hard to overlook the major changes Apple made to the App Store with iOS 11 – search results are now extremely low density. You can barely see two results on a screen at once on a 4.7″ device, so if you’re say 40 or 60 places down your visibility is near zero. But that doesn’t explain my apps amazing fall down the rankings. In fact the most confusing thing is seeing apps which haven’t been updated in years – some of which look like first attempts at programming, with zero reviews, ranking tens of places above mine. What bizarre algorithm sees two apps with the same keyword, and ranks the one with no reviews that hasn’t been updated in 3 years above my 5 star one, updated a week ago? Clearly some other factors are weighting the results, probably ones completely outside my control – but it’s hard to imagine what or how this is helpful for your typical App Store customer or why Apple is doing it.
It seems the best way to to improve your app’s rankings is still to keyword load its name. Although this is tricky now you only have 30 characters to do it. Given this is a practice Apple themselves asks you not to do (although it remains unenforced), it’s ridiculous that the search algorithm still weighs the name above all else. An app with no reviews, not updated in years but called “Hiragana” will rank over my app if I just call it “iKana touch” and have “hiragana” as a keyword instead. In renaming iKana touch to “iKana – Hiragana and Katakana”, it now at least breaks the top 20 for a search of “Hiragana and Katakana”, but still falls behind less up-to-date apps with lower or no ratings.
It would all be that bit less terrible if it were possible to easily play with keywords, app title and so on to see what magic combination would claw you a few spaces up the results. But of course you can’t do that without annoying your users with an endless stream of largely identical ‘bug fixes and improvement’ type updates because Apple deems almost any change to your app listing post review as verboten.
I’m really starting to reach my wit’s end with this now. I’ve never felt especially unfairly treated by Apple, but having my business slowly destroyed by this infuriatingly crap, opaque search algorithm makes me very bitter.
After much deliberation, I’ve decided to make a big change to the way iKana touch is sold on the App Store with version 2.7. Before I get into that, let me give you some background. Since it first appeared on the App Store, nearly 10(!) years ago, iKana touch has used the paid up front business model. You bought the software, then it was yours to use on all your devices forever.
The App Store didn’t allow us to offer a free trial or to charge for upgrades in the way that has sustained developers like ThinkMac since the dawn of the home computer revolution, but for a good few years that simply didn’t seem to matter. The iPhone was on a near exponential trajectory and sheer size of the expanding market kept a decent amount of revenue coming in. Unfortunately while the market was growing, a parallel force was also at work – the now infamous race to the bottom in App pricing.
Apps backed by venture capital or from major developers with other income sources, or with no real sustainable business model to speak of, have pushed the price people are willing to pay up front to basically zero dollars.
For a good amount of time ThinkMac’s apps managed to escape this trend, as niche markets continued to get away with charging non-zero sums up front for apps. However it’s increasingly apparent that the writing is on the wall for us now too. In fact, to be honest if I relied solely on income from my apps to survive, I’d have been forced to throw in the towel a few years ago. Contracting has helped me keep my bills paid and a glimmer of the indie developer flame alive since 2014.
What brings us to where we are today, is that the main client I’ve been working with over the last few years unexpectedly went out of business at the start of the year, and this has thrown the now dire sales performance of my apps into stark focus. I want my apps to generate me a basic income I can survive on as contract work comes and goes. To do that I’ve had to think long and hard about changing my business model to one fit for the App Store of 2018 and beyond.
So freemium, also known as ‘free to play’, refers to any app that is free to download on the App Store but which offers in app purchases (IAPs) to unlock features or content. There are a lot of companies using this business model unethically – deliberately crippling gameplay for example to coax users into paying for speedups and cheats, that themselves are quickly exhausted. That’s not my intention at all.
With iKana touch IAPs will be used to unlock the hiragana and katakana character sets, either individually or all at once. Once you’ve paid to unlock them they will remain that way. There will be one consumable IAP called the Day Pass that lets you effectively trial the app fully unlocked for 24 hours, but everything else will unlock things permanently for you. Before you purchase one of the IAPs you will get a limited subset of kana unlocked to try the app with.
Now you might be wondering what this means if you’ve already purchased iKana touch – will you need to buy these IAPs to gain full access the app again? The simple answer is no, iKana touch will check your purchase receipt from the App Store and automatically enable all the kana sets if you have bought version 2.6 or earlier.
Now there are some downsides of this model that I want to acknowledge – it will no longer be possible to buy a discounted bundle of iKana touch and iKanji touch going forward due to limitations of the App Store. It will also no longer be possible to bulk buy iKana touch for education.
Finally you may wonder why I went for a freemium model and not a subscription. Simply put I don’t think a subscription model is well suited to an app like iKana touch, which has fixed content and no online component. iKana touch is also not an app most people would likely use for more than maybe 6 months, which negates any of the long term benefits of choosing the subscription model in terms of lower fees from Apple etc.
Finally before I thank you for reading all this shop talk, let me say that yes things will be changing for iKanji touch too in the near future. Exactly how will depend in part on the success of iKana touch’s new model.
So yes, thank you for reading this. I hope this makes clear why this change of business model has become unavoidable and allays any fears that it might be a raw deal for previous customers. If you have any thoughts or questions about this please drop me a message.
This has been a really busy year of coding for me so far – not that you’d be able to tell from looking at any of my own apps, which haven’t seen as much activity this year as I’d have liked. With ever declining App Store revenues, I’ve had to start spending a lot of my time doing contract work. The upside is this keeps the lights on and the rent paid, but the downside is obviously fewer updates to my own apps. They’re not forgotten of course, but I feel they’re all generally in a stable and mature enough state that they don’t desperately need monthly updates. Still I don’t wear “last updated in 2015” as a badge of honour, so things are in the works, however slowly they may come to fruition!
Despite the diversionary nature of contract work, I have been rather enjoying it. I’m lucky to have found a really excellent client that I’ve been working with for the last two years on a couple of apps. This year I built them a new app from the ground up and it’s been a great learning experience and a chance to dig into some new technologies and master others. For example this is the first time I’ve really dug deeply into the Facebook Graph API to get things accomplished that are outside the functionality offered by the SDK.
I’m still convinced Swift isn’t quite ready for prime time yet, and it certainly wasn’t when I started this most recent app, so it’s been a great exercise in writing the cleanest, most modern Objective-C code I can. If at some point a migration to Swift is required, it will be a less onerous task as a result. Whether it’s specifying the nullability of method parameters, using dot syntax as extensively as humanly possible, having everything be asynchronous and block based and trying to avoid some of the old design patterns that have fallen out of favour. That said I’ll take singletons to the grave with me! I’ve yet to be convinced that passing around endless model objects, which are only ever instantiated once during the lifespan of an app, is anything other than hair shirted asceticism for the sake of trying to look clever.
After inheriting a big project from another developer when I first started working with this client, I came to really appreciate the importance of good code documentation. Not that the code was bad, it wasn’t, it was just written in a different style to what I was used to and it was almost entirely uncommented, and where it was, often in unhelpful ways. There’s nothing like finding a nice “//TODO: fix this” comment where you’ve no idea what is broken in the first place! As such I took pains to make sure that every method in this new app had Appledoc formatted comments explaining what it was doing and how it should be used. This is incredibly handy with the Quick Help inspector open in XCode, as you can see what any method call is doing just by selecting it. Given the amount of time we spend reading and trying to understand code (even if we’ve written it ourselves), the extra minute or two it takes to document as you go is a drop in the ocean.
Something else I’ve done for the first time in this project was to create my own logging function to use instead of the venerable NSLog. In particular I was keen to log messages both into the console for my own debugging purposes, and into a log file that I could then display within a debug screen in the app and that testers could easily email to me. As the log will only contain things that I am specifically choosing to write to it, that helps cut down on the the inevitable noise you get in the standard console log. In an app that makes extensive use of web API calls it’s really useful to be able to clearly see the chain of events and any error return codes those may have generated. I think I’m going to adopt this strategy in all of my apps going forward because it’s just so much more flexible. It also makes it possible to completely turn off console logging of spurious debug messages in release versions of apps very easily using preprocessor directives.
Anyway I’ll leave it there, but in summary although I’m having to divert attention from my core apps at the moment, what I am working on is helping to make me both a better developer and expanding the technologies I know how to use. When you’re just working on your own projects all the time its very easy to get stuck in a technological rut and frankly it feels pretty good to get out of those once in awhile!
The idea of having a mascot character for an app may seem a little strange at first, especially in the West where mascots are more usually associated with things like sports teams and fast food. But in Japan mascots are ubiquitous; most companies have their own, each prefecture has one, and even buildings like the Tokyo Skytree use them. As an important part of Japan’s modern culture, I felt it was a nice idea to have one in iKanji touch too.
When you think of characters in software you may remember old versions of Microsoft Office with its frequently unhelpful and annoying virtual assistant, Clippy. That was definitely not the direction I wanted to take with iKanji touch. The mascot is something intended to add visual flavour and personality to the app (and hopefully make you smile), but it’s not something that should get in the way or make the app feel jokey or cartoonish.
I had the idea of having a little fox character be the mascot. Foxes are culturally important in Japan and are seen as messengers of the god Inari. I tasked my friend Craig Ede with designing the character and he came back to me with these sketches and the name Tsutsune (pronounced tsu-tsu-neh). A play on the word kitsune (fox in Japanese). You may notice Tsutsune’s spiky hair looks like the katakana character tsu (ツ).
Within the app Tsutsune keeps a watchful eye while you study without distracting. When you’re taking a test you may notice he’s started smiling, a sure indication that you’re doing well. If he’s frowning on the other hand things may not be going quite so well! The only time he pops down from the top bar of the app, is to offer some words of encouragement (or admonishment!) once you’ve completed a test and the score is revealed.
Here are some fun Tsutsune facts:
- His hair looks like the character tsu (ツ).
- He gets cross if you poke him too much!
- He uses “Tsu!” as an exclamation.
- He was “born” on March 3rd 2009.