The S-Cycle for Software

Have Apple software updates seemed a bit… rushed lately?  With both iOS and Mac OS X on yearly release cycles, we seem to be getting more quirks and bugs than I’d like.  When this topic is brought up, the solution always seems to be to just do big software releases every two years, or do small pieces throughout the year, instead of having a monolithic update every 12 months.  However, I suggest that Apple’s software team do what their hardware team does: use the s-cycle.

What is the s-cycle?  The s-cycle is the way Apple releases their iPhones.  For example, the iPhone 4 (2010), then the iPhone 4s (2011), then the iPhone 5 (2012), then the iPhone 5s (2013), and so on.  People say, “Well the software team needs to get it together, because the hardware team releases a new iPhone every year with no problems.”  But they really don’t.  They really only release a totally new iPhone every two years, and then release a small update the years in between.  This is the s-cycle.

And it seems to work great.  People still get excited about the -s models, and it’s less demanding on the hardware team, which allows them to make something truly great every two years.  I think that this is what Apple should do with iOS and OS X.

Let’s focus on iOS here.  Suppose that only every other version of iOS had big changes.  The other years would just include some minor updates, and maybe one new headline feature.  But instead of making the -s year the same for the iPhone and iOS (because those years would be a little boring), maybe they could alternate.  That would mean that this fall, we’d get the iPhone 6s (a minor update), and iOS 9 (a big update).  Then next year, we’d get the iPhone 7 (a big update) and iOS 9s (a minor update).  iOS 9s could just include the new features required by the new iPhone hardware, things like Touch ID and Apple Pay, but not much else.  This would allow the software team to slow down a bit, pay more attention to quality control, and make the features they do add really count.

The main problem I see with this alternation is that it’d be sort of confusing.  Because of this, maybe it’s better to just keep calling it iOS 9, 10, 11, etc., but then apply the principle of the s-cycle.  (Another thing: say “iOS 9s” out loud.  Exactly.)  The last thing you want to do to your customers is confuse them – confusion kills excitement.

And that excitement is why Apple should continue to do something every year, instead of every two years.  Why?  Simple psychology.  When something happens every year, people remember it.  Around September, people know that there will be a new iPhone and a new iOS update.  Releasing iOS every two years makes things more complicated.  Come September, people will have to try to remember whether there was an update last year, and whether they should be excited for an update this year.  This sounds trivial, I know, but you want people to be excited about your brand, not hesitantly excited.  You also don’t want to let down the people who thought this was an update year but it wasn’t.  This same psychology also applies to, oh I don’t know, say, weekly blogs and the like.

As you can see, adding an s-cycle to Apple’s software production could slow down the sometimes-breakneck train we call iOS.  Don’t get me wrong, I love new features as much as the next guy, but the last two iOS updates in particular (7 and 8) have been enormous.  I don’t think there’s anything wrong with dialing back iOS updates just a little bit, especially if they can do it in such a way that still appears to be a yearly update.  Hey, it’s worked for the iPhone.  ••

Advertisement

2 thoughts on “The S-Cycle for Software

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s