What we can learn from the iOS update that bricked iPhones
Lapses in quality assurance can turn ground-breaking innovation into deal-breaking embarrassments. Too many of these lapses will knock an innovator off its spot at the top. An example comes from Apple, a global technology leader known for attention to detail and quality for every aspect of its software and hardware development.
Apple product launches are often anticipated as “The Next Big Thing,” but high expectations have a downside: when the Cupertino giant doesn’t deliver something disruptive or unexpected, the technology press and stock market don’t hold back in their criticism.
When Apple rolled out a flawed iOS 8.0.1 software update, the Twitter world received the otherwise-promising iOS update as “The Next Brick Thing,” and rightly so.
Apple pulled iOS 8.0.1 within an hour of its release. The update caused the company’s smartphones to lose the ability to call or access data services – pretty much everything expected from a modern mobile device. The crash rate of iOS 8 was found to be 60 percent higher than the iOS 7 and a surprising number of software defects appear to have slipped through Apple’s QA.
Issues with HealthKit had already delayed the launch of iOS 8. 8.0.1 was designed to fix existing issues with the software. iOS 8 was also the more powerful and open compared to its predecessors, allowing developers more flexibility to utilize third-party services in extending the interface and functionality of Apple devices. However, this extensibility led to issues with iOS 8 that emerged only after its launch and widespread usage in the real world.
iOS 8.0.1 update was released within a week of the iOS 8 launch, perhaps too soon to fix iOS software defects that required more rigorous investigation and fixes.
A few years later, and the quality assurance problems have continued: from the recent issues with the iPad Pro to criticism of the frequent iterations OS X & iOS. Apple’s software release cycle are designed with a business perspective as much as a technology perspective. This means the software rollout undergoes some tradeoff between product quality and business viability. Sometimes it’s financially justified to push updates with a few software defects that can be addressed later on, instead of delaying the release. Further complicating the situation, a limited set of employees get to manually test the update on unreleased hardware to avoid leaks about future products.
Regardless of any company’s market share and reputation, software quality strategies must evolve and undergo improvement on a continual basis. Modern software development methodologies like DevOps bring development, operations, and testing together under a single umbrella to address these concerns. Developers and QA personnel need to embed continuous, automated, and collaborative testing into development from the ground-up to shorten release cycles and improve quality. Sprinkling QA on software as an afterthought doesn’t suffice.