The real world can be tough. Your magnificent app passed all the automatic testing in your nice development environment with flying colors? And now that it’s shipped, bug reports regarding code you were sure couldn’t fail are coming in? Welcome to meatspace.
One of the great things mobile development has brought back from the dead, is constraints.
Back when I started, in the glorious time of Mac OS Classic, processors could only go so far, you had a single core, and limited memory. That meant the UI could stutter and die under heavy load, and that you could run out of memory, forcing you to free some, or crash.
The predominant attitude when I taught was “who cares if some users don’t have enough RAM? next year, or 2 years from now, they will all have doubled their specs, we’re fine”. Which at the time was somewhat true, if a bit optimistic. Nowadays, on our computers at least, we do have almost infinite virtual memory, making RAM preservation a bonus, something “elegant” to do when releasing an app. As an example, I have 3 tabs open in Safari, totaling with its helpers a magnificent 400MB of used memory. That’s one quarter of the “standard” 2GB we had only a few years ago. And, the quarter of what we have today on high-end phones. 3 tabs. 150MB per tab. Except it’s not true. Virtual memory has to be shuffled around, making every application, including your own slow.
But, I hear someone shout, we do a lot less on our phones! Really? Don’t you think that having apps like Facebook, always reacting to incoming messages, or Twitter, streaming in the background need some RAM to function? It is so easy to forget your app isn’t running all alone on your phone isn’t it? That’s why I was shocked to discover that “killing apps” isn’t a power feature at all, it’s a standard one. I saw a young woman doing it in the subway and straight up asked here why she was. She told me it made her phone faster. When I asked her why, she answered she wasn’t technically oriented, but that she guessed it limited the number of things her phone was trying to do at the same time, maybe?
Again, it is common knowledge at the base user level that killing apps isn’t a thing you do once a year to fix a nasty glitch, but something you do on an hourly basis so that your phone doesn’t heat up, slow down, or eat its battery. Back in the day, I had trouble explaining to my dad he had to quit his mac applications if he wasn’t using them. Now, maybe he will tell me he kills phone apps every hour to make his device work better.
So, ok, sure, the mobile hardware is following a similar curve the computer was in the nineties and the naughties, but just like the computer curve did, the mobile curve will plateau. And your app could be running on a 3 years-old phone that has half the RAM and three times less CPU power than the fancy new one you are developing on.
A few things to remember when building your next awesome app:
- use system frameworks as much as possible for your animations. They are built to skip frames in case of intensive use, and to coalesce changes to avoid a lot of graphical commands to the GPU
- queue your network commands. Run one or two at maximum speed rather than 20 at slow as hell speed. Worst comes to worst, you can pause your queue and resume commands when the CPU grants you some time
- in the same vein, don’t assume everyone is on ultra fast LTE, with the latest phone, and a full battery. Check for that, pause your queues when you don’t have a good enough network, and resume later. Bonus point to people dumping on disk in case of app termination
- Don’t immediately compute a ton of stuff once you receive a new piece of data. Redesigning the whole screen, or database, because one letter has changed? what’s that? 1967?