Wow. Marco Arment published an interesting blog post yesterday. He's gone on to say he regrets doing so. Though his blog post has been sensationalised by a lot of the media, it has also sparked some very interesting debate.
It also made me think about a topic that's been burning for us for quite some time. We don't write apps for ourselves (well, maybe one), but we're not indy developers who rely on App Store sales for our income. Instead, we're a development services company. Our income comes from selling our skills, and we focus solely on mobile app development.
But the rate of updates has been having an affect over the last couple of years. It's affecting our customers, and here's why:
For most companies, a yearly release is simply too fast.
We work with banks, telecom companies, and major brands. By their nature, they like to work in a considered fashion. Much of the decision making process requires multiple opinions and sign-off procedures. Project timelines of more than six months are not uncommon.
So how does a yearly release cycle fit in with a six month project?
Not great, to be honest.
Consider a typical project six month project. Pick it to start any time in the year. iOS goes beta every June.
Q1 start? Your project is ready for release pretty much during the iOS beta cycle. Remember, our customers like the comfort of us using production, non-beta toolchains.
Q2 start? We've just released, but end-users are already migrating to the new operating system version, so we'll have to bring out a new version quickly to keep up.
How about a Q3 start? Okay, maybe. We'll be starting with the latest and greatest version of a production operating system, but our customers will still worry about those users who are still on the older version (if the market share of iOS n is less than 90%, they will be concerned about the 10%).
Q4 start? Maybe, but we'll be launching just as the beta cycle is beginning.
New versions are a boon to indy developers. A new version gives them a chance to utilise new features and might give them a chance to sell more copies of their software. For enterprise (where Apple are starting to look towards), yearly is simply too quick.
The changes in the last couple of years have been pretty drastic. iOS 7? We need to change the complete styling (and we spoke about this before). iOS 8? Major changes to auto-layout and rotation.
We've seen some concern from clients too. They find it hard to understand why something written six months ago now doesn't lay out correctly on newer operating system versions, or indeed why they should pay for the fix.
This isn't limited to iOS. Android is maintaining the same pace of releases. So we encounter the same problems there too. Ironically, they're doing this to each other. Both the iOS and Android camps are now scrambling for "me too" features. The fear of being outdone by one another is fuelling all of this.
I wonder if we went to 18 month release cycles, would it get better?
Image Credit: Microsiervos on Flickr
Thanks for reading the Tapadoo blog. We've been building iOS and Android Apps since 2009. If your business needs an App, or you want advice on anything mobile, please get in touch