In 2006 I wrote about how the fear of installing desktop software accelerated the move to the web. Security warnings, firewall alerts and antivirus popups made installing software feel like an incredibly risky thing to do.
We’re seeing a similar situation with mobile apps now. The seemingly simple act of installing an app requires you to first approve a scary list of permissions, and while some may approve them the same way they dismiss a EULA, others find them daunting. Add to that the spammy notifications and addiction-feeding of popular games plus the privacy violations of popular social apps, and it feels like I’m watching a rerun from eight years ago.
If this trend continues, the whole debate about mobile apps vs. web apps will be pointless: users will feel safer with web apps so that’s what they’ll choose, and developers will follow.
In what feels like a different life now, I used to be a fairly well-known indie developer. I spoke at events like SXSW, and my blog had a large audience of people who liked hearing about my work on HomeSite, TopStyle and FeedDemon.
I parted ways with that life several years ago, in part because it’s extremely difficult to be a one-man show and still have time to be a husband and father. I was also burned out from years of doing my own support. I had lovely customers, of course, but I spent so much time supporting them that I wasn’t able to spend as much time feeding my code addiction. Almost everything I do professionally is so I can enjoy the bliss of getting lost in writing software.
But I also gave up pursuing the indie life because I wanted to make the switch to mobile development, and I didn’t see much future for indie mobile developers. The economics of the various app stores coupled with the plethora of free software didn’t paint a rosy picture for one-person companies building consumer apps. In fact, I didn’t make the leap to mobile until I was offered a full-time job as an Android dev.
So it’s been interesting reading the latest round of blog posts about the state of indie mobile development. While there are success stories, there certainly aren’t many of them. Making a decent living as an indie developer writing mobile apps is ridiculously hard – and I don’t see it getting better anytime soon.
A lot of mobile developers have left the indie ship and done as I have and joined a larger company, many of which look at mobile apps as a free (or nearly free) complement to their other offerings.1 There’s plenty of opportunity here for mobile developers, and I think that opportunity will continue to grow for a while.
- As an aside, I’m not convinced the “mobile as a complement” strategy is the right one long term. Mobile is becoming the primary way people access their information, to the point that web and desktop software are turning into the complement.
A huge pet peeve of mine is mobile apps which make you to wait after you do something that requires a server API call. For example, you tap a “Like” button and are forced to look at a modal “Liking…” dialog that doesn’t go away until the app knows the like has been received by the backend.
Apps which do this are unnecessarily pessimistic about connectivity. Why make the user wait when the most likely outcome will be that the API call succeeds? I think it’s better for the app to show the new “Like” state immediately, and then deal with the rare failure in the background.
This optimistic approach is one that the folks at Instagram have touted, and I’ve followed it in all of my mobile apps (especially in my latest work at Automattic – more on that soon).
Sometimes, though, you really do want to make the user wait, at least a little bit. In these cases, it’s often better to resort to sleight of hand which distracts the user instead of blocks them the way a modal dialog does.
I’ve found animation to be the most effective form of this trickery.
Suppose it really is important to make the user wait a couple of seconds after clicking a “Like” button to give the API call a little time. In this situation, animate the “like” button for a second or two – have it bounce, or spin, or zoom in and out.
Users will wait for the animation to end before doing something else in the app, and by the time the animation is done there’s a good chance the API call has completed. The user still waited, but because they waited by choice it doesn’t feel the same as being so obviously blocked by an annoying modal dialog.
PS: I should add that I only recommend this approach when making very lightweight requests. For heavier requests (especially ones that upload large amounts of data), a background service is a far better choice.