I read this short piece the other day: Why the Facebook innovation machine doesn’t work on mobile devices. It’s an interesting read and I couldn’t help draw parallels with my brief (and aborted) foray into mobile app development. (And I refer here specifically to mobile apps – apps you download in an app store, and not mobile websites … confused on the difference? Check out my post on Mobile Design Considerations.)
The article suggests that Facebook’s problems on mobile are, in essence, due to the difficulties of the process for creating, releasing and updating their mobile app. If you want to release an update to your app there is one major constrictions that just doesn’t apply on the web: you have to release to your entire user base in one hit.
If Facebook want to test anything on their site – the size, colour, position, whatever of a button, a sentence of text, or whatever, they can release that update to a tiny fraction of their audience, get instant feedback from their analytics team, adjust, iterate, re-release to a larger (or smaller) section of their audience, and repeat the process. Any debates that arise or decisions that need to be made, can instantly be informed by a slew of data from their 1bn plus users.
However, with mobile apps, Apple and Google control the distribution – and the app gets distributed in one hit, to everyone. That means the only people who have tested the update are likely to be Facebook employees. Not ideal.
Recently, I developed a mobile app with a colleague of mine. It was a simple enough app – a note taking, storing, and organising app for physiotherapists (helping them to meet their continuing professional development requirements). It’s simple enough – if it had been developed as a website, it was maybe 20 hours work tops. But as an app … well, the process was so frustrating. You can’t write a couple of lines of code and refresh a browser to see how it works. You write a couple of lines and have to recompile the whole app – sending it to an emulator that could (and does) crash constantly. Errors can appear that weren’t there before in identical code, and you have no easy way of telling what piece of code has crashed your app. What you end up doing is writing a lot of code in one hit – because compiling is time consuming – and then spending inordinate lengths of time debugging, before recompiling.
Compared with developing for the web, developing apps is hard. Really hard. It’s one reason why I think that, eventually, mobile apps using HTML5 rather than native technologies will win the day (although that’s some way off yet). And it’s one reason why Facebook (and TickTock) continue to struggle with mobile apps.