What Developers Can Learn from Apple’s iOS Woes

Apple’s decision this year to delay new features in iOS to address performance and quality issues, as we saw at WWDC, is a setback for the company, but it also holds valuable lessons for software developers and dev teams about the environment we work in today.

A recent report said Apple plans to pull back on several new iOS features until next year, including a refresh of its interface and improvements to core apps such as mail. It’s an uncharacteristic move for Apple, and follows a wave of criticism over a number of security and quality issues in recent months.

Apple’s missteps come against a backdrop in which companies are under more pressure than ever to get new features to market quickly. It reveals just how intense that pressure has become—and the problems that can result if companies get careless or try to move too fast. Dev teams must learn to navigate a delicate balance between speed and quality.

Here are four takeaways for dev teams from Apple’s decision to delay features in iOS.

The Pressure to Ship Fast Has Never Been Greater

The tech industry is going through a startling period of innovation, with smart assistants, augmented reality, biometrics, wireless charging and host of other technologies all entering the mainstream at the same time. The fact that a company like Apple felt sufficient pressure to push features out before they were ready is a sign of just how intense this pressure is. If Apple was famous for anything, it was quality; the company never released anything until it was rigorously tested and perfected. This has been changing for some time under Tim Cook, but Apple has never felt quite the pressure that it has lately. While not all dev teams are pushing multiple bleeding-edge technologies simultaneously the way Apple is, it’s a reminder of the pace of innovation that we all need to design our pipelines for today.

Prioritizing Speed Over Quality Will Hurt You

While dev teams need to move fast, they can’t afford to sacrifice quality for speed. Every company must make careful trade-offs between the need to move quickly for competitive reasons and the need to get it right. Moving too slowly can allow a competitor in the door, but moving too fast can diminish quality, drive users away and create the kind of backlash Apple is now seeing. Developers need to learn to make this difficult calculus balancing quality and speed. And quality isn’t just about bugs; it’s everything. Ease of use, design, build—these are all elements of quality, and they must all be factored into the decision of how fast you move.

User Experience is Everything

The industry continues to evolve toward better usability, with more energy being invested in creating easy-to-use, well-designed user experiences. In a world where your customers can easily switch their smartphone and the applications running on it, good design in technology is imperative for keeping users delighted and engaged. It’s gone from being a nice-to-have to an essential feature.

Developers Should ‘Shift Left’ for Higher-Quality Code

Traditionally, QA has gotten involved toward the end of the development life cycle. But when you move quickly, code can suffer and you end up shipping features that could do with a bit more work, as Apple apparently has. By “shifting left”—or testing earlier in the process—any issues are easier to fix. Why? Because slower feedback cycles create distance from the problem. Developers become forgetful and shift to other tasks, which means they lose context. Additionally, code can change, which complicates the process of fixing the problem. Testing earlier surfaces errors more quickly, tightening the feedback loop between QA and development.

We don’t have details about what happened inside Apple, but it appears the company is having to slow its release cycle to fix quality issues that weren’t identified the first time around. This is a danger for all companies that are trying to keep pace with the latest technology trends. Developers need to think about all aspects of software quality, ensure their pipeline can accommodate the pace at which they work, and avoid shipping bugs into production that will come back to bite them later on.

Fred is the CEO and co-founder of Rainforest QA. Fred spends all his time driving the company to build a better, faster way to do QA while remaining a place that people love to work at. Since Rainforest’s early days at Y-Combinator in 2012, Fred has led the company through rapid growth, building not only a QA platform that leverages both crowdsourcing and machine learning to accelerate testing, but also a team spread across 16 countries on 5 continents.