It’s been awhile since I introduced a new app, well actually it’s been ages – iKana nōto was the last one and was introduced in 2011! There have been a lot of app updates to my other apps since then of course, but the only ‘new’ apps I’ve launched have been for clients, so it’s really great to finally be releasing something new under the ThinkMac banner. So today, please welcome to the stage Watermarker Pro.
I’ve been an avid photographer for almost as long as I’ve been an app developer so this is something near and dear to my heart. The fact is images are stollen every second of the day – a lot of the time this is done innocently enough, you Google Image Search a photo and then stick it on your website or you share a photo you like on your Facebook account. No big deal right? But yeah actually if you’re the owner of that photo it kind of sucks, especially if you’re either counting on licensing it to make money or if you’re sharing it in the hopes of driving people back to your site or feed.
So what to do? Well honestly you have limited options, barring simply not posting your images online, but one thing you can do is watermark your images! That means to put a stamp onto the image that identifies it as yours. That might be your company name, your Instagram username, a logo, a web address or whatever you like. Your image can and likely will still get used without your permission but now people at least know who the image belongs to and hopefully if they see a big fat © in the middle of a photo they’ll think twice and maybe try and get in touch to find out how much it would cost to get a version without that mark on it. Of course if you’re a Photoshop wizard you can potentially edit out a watermark, but most people aren’t Photoshop wizards and a watermark can therefore be an effective deterrent.
Beyond the simple protection angle though is the idea of using watermarks as part of your brand strategy. Let’s face it, we’re all building brands these days, whether as companies or individuals. We sell our lives, our art and our products on social media and we want to make sure people know when an image is ours. Imagine if your image goes viral – how great would it be if your logo and web address were burned into it? There’s no point in getting a ton of exposure for your work if no one knows it’s your work.
Anyway enough sell on the concept – Watermarker Pro is designed to be intuitive and fast to use. It’s as simple as 1 – choose an image, 2 – design a watermark or choose one you created previously, 3 – place the watermark and share the image.
Watermarks can be composed of a combination of up to 20 symbols, text elements or arbitrary images and you can save an unlimited number of them on your device. Just drag elements into position with your finger, they’ll snap to guides to help you align them, pinch to resize and you’re done.
Then you can use a very similar interface to place the watermark on your photo, set the colour, opacity and shadow to make it stand out. When you’re happy with the layout, you’re just a tap away from saving the image back to your photo library or sharing it directly to Instagram or another social network. Watermarker Pro will of course remember things like the opacity, colour and position of the watermark to speed things up next time.
If you share images online, whether as a photographer, a brand or as an influencer check out Watermarker Pro on the App Store – available now from just $2.99 with no ads, no in-app purchase and no subscriptions. Proper software; you pay for it, you own it!
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!