Coding to keep the lights on

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!

iKanji touch’s mascot: Tsutsune

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 (ツ).

Tsutsune sketches

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.

app-tsutsune

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.

Christmas Savings!

This is just a reminder that we’re offering a 10% discount until the 1st of January 2016 on iKana, iKanji and NewsLife when you buy directly from us. Just use coupon code XMAS10. Order securely through our FastSpring store using the payment method of your choice.

xmas-banner2015

This offer isn’t available on the Mac App Store as we want to reward customers who buy direct – you’ll also get faster access to updates and new versions.

The Mac App Store and the future of indie development

If you’ve been keeping an eye on the Mac App Store over recent years, you will have noticed a couple of things; how little it has improved since its launch five years ago and secondly how a steady stream of big name developers from Barebones to Panic, have been forced to pull their apps due to its limitations. The most recent refugee being popular design app Sketch.

I was initially very enthusiastic about the Mac App Store (MAS), but as the years have ticked by with literally no improvements, that enthusiasm has waned to be replaced firstly by concern and now increasingly by anger and frustration.

I’ll give the briefest of summaries of the main pain points with the MAS, as you’ve probably heard them all before:

  • No demos or trials. Apple won’t even let us link to or mention that we offer these from our websites.
  • No upgrade pricing for existing customers.
  • No way of handling refunds or addressing support requests left in reviews.
  • No bundles (even though we have this on iOS!)
  • The huge 30% cut Apple takes of every sale.
  • Long delays in getting updates approved by Apple’s review team.
  • Mandatory stringent sandbox restrictions.

Having just one or two of these problems to deal with wouldn’t be insurmountable, but dealing with all of them, along with many others, just feels like death by a thousand cuts.

Now if you’re not a developer you probably appreciate the convenience and security of the App Store and all these other issues may seem fairly peripheral. You would like things like trials and discounts, if you remember what buying software used to be like, but it’s not the end of the world now that you don’t have them.

Indeed the problems almost all fall into the developer’s lap. We get the blame when Apple screws up and receipt checking fails spectacularly. We get the anonymous 1 star reviews we can’t respond to. We get the angry users who can’t download updates because they’ve been stuck in review for a month on some technicality. We watch our sales dip ever lower with no conventional means of reinvigorating them.

Developers and users ultimately have a symbiotic relationship, one can’t survive without the other. Eventually the pain inflicted on them will also impact on all of us. Either they give up because it’s no fun fighting with the platform owner for survival or they go bankrupt because business conditions have become so hostile. Then that shiny piece of software you invested in stops getting updates, there’s no one there to respond to your emails when something goes wrong. Your data is held hostage in a dead app. It’s on you to have to go through the troublesome task of finding a replacement, migrating your data and learning something new just to get back to where you started. All the time hoping the same fate doesn’t await this new app.

I’ve worked with a lot of Mac developers over the years and I’m sad to say a large number of them are no longer in business, or they’re just barely clinging on if they are.

In some cases like with Microsoft and Adobe or Barebones and Panic, they have enough clout to survive outside the MAS. But for smaller developers, including ThinkMac, the MAS has sucked so much oxygen out of the rest of the world, that it would be suicide to pull out. So we stick around, accruing cuts and counting down the days until we finally succumb to them.

I live in hope that Apple will announce some changes to improve the Mac App Store (and frankly the iOS store too) in 2016, but I have to confess I’m growing more pessimistic about the future of indie development on the Mac. The clock is ticking Apple, the ball is in your court and it’s getting dusty!

Further reading:

Too late to save the MAS? by Manton Reece
Bohemian Coding Pulls Hit App Sketch from Mac App Store by John Gruber
The Mac App Store: Not gone, but certainly forgotten by Macworld
The Mac App Store Needs Paid Upgrades by Wil Shipley
NSFW: Apple’s benign neglect of the Mac App Store by Peter Cohen
Mac App Store: The Subtle Exodus by Milen

Updates, updates everywhere!

Hard to believe 2015 is nearly over already isn’t it? Lately I’ve been hard at work on a bunch of updates to my various Mac apps. All of which are live for direct download customers. If you use the Mac App Store, so far only the iKana update is live, but the others should get there eventually. In semi-related news, I’ve now migrated the ThinkMac Store over to FastSpring. This should make the process of buying my apps and getting your license file a bit smoother. It also handles the troublesome new VAT legislation problem that had meant I was unable to sell directly to EU customers for much of the year (cheers bureaucrats).

iKanji 2.0.7

This is actually a biggish update and adds some requested new features like JLPT vocab sets, the ability to set the length of training sessions and increases font sizes in various places to improve legibility. This also squashes some bugs and fixes some text rendering glitches when running on El Capitan.

iKana 2.1.1

This update (finally) adds retina graphics throughout the app and gives the interface a refresh to look more modern. There are also various bug fixes and tweaks to improve stability.

NewsLife 2.2.3

This version has some visual tweaks for El Capitan as changes to the way fonts are rendered in the new OS left the default text looking very spindly and hard to read.

Lastly but not least(ly), on the iOS front I have a nice update to iKanji touch in the works. I hope to have that on the store before Christmas.