.png){kind=logo}
With 27 years of experience developing iOS, Mac, and embedded software, Jeff Gilbert is a veteran Mutual Mobile engineer. He spends most of his time focusing on software architecture, improving the collaboration between disciplines (engineering, design, and QA), and increasing the effectiveness of the development process.
Little-known fact: He’s also the (extremely humble, all-around great) mastermind behind VIPER development architecture.
A variety of companies–including Uber and Etsy–continue to actively build upon and adopt VIPER and its core values. So we’ve asked Jeff to give us a quick tour of VIPER–what it does, who uses it, and how it can benefit development environments (and business as a whole).
VIPER is an iOS architecture optimized for long-term maintenance, which allows features, added two years from now, to be as easy, and inexpensive to add as they are today.
Test-driven development (TDD) is a software development practice which can lead to a better structure of the code. In an effort to learn how to use TDD with iOS I needed to understand how to write testable iOS code. Clean Architecture, by Robert Martin, aka, “Uncle Bob”, is a great testable architecture. VIPER is my application of Clean Architecture principles to the constraints of the iOS platform.
I’ve always believed that the journey in creating something like this would make me better at what I do. VIPER is kind of similar to the Fosbury flop, or the Scandinavian flick—VIPER seems unconventional, looks very different, but actually can achieve more when you do it right.
Business requirements, interaction design requirements, visual design requirements – VIPER helps designate the code to each of these places. Separation of responsibilities and requirements are what it’s all about.
VIPER aids in planning and building for longterm app utility and development performance. It also offers the opportunity for people upstream to be more explicit in the separation of requirements—while exposing weaknesses within the development process that can then be addressed.
It potentially exposes weaknesses within the dev environment, and not everyone wants to have to take that on as a product of the process. It takes effort and big-picture commitment to a different approach to be successful–so some companies aren’t open to that kind of undertaking.
VIPER is based on a philosophy around deeper understanding of the dev process–not necessarily the particular project at hand. It’s more inclusive and flexible than it seems, in that it can be incrementally applied. It doesn’t drive teams toward waterfall process.
Another challenge I’ve seen in teams adopting VIPER is confusion over how to separate code. This tends to be a problem further upstream in the quality of the requirements presented to the developer. Often the requirements for business design, interaction design, and visual design are presented strictly in terms of the physical UI. If the requirements could make the distinction between those three primary forms of design, it would help the developer better organize their code.
I think some people see it as a fix more so than a toolbox to build their own solution, which is a short-sighted perspective. Sometimes people come in with this prescriptive mentality, but really VIPER is a set of core principles and concepts that can be customized into proprietary software development.
Uber is the most well-known VIPER application. Their proprietary “Riblets” dev architecture shares several core tenets with VIPER. It’s important to identify Uber as a great example of a business that has a long-term plan. They expect their app to be around for a very long time. VIPER allows for smoother transition and growth over the lifetime of the app, so it has worked well for them.
Etsy is another company who leverages VIPER to build out features like shop stats, multi-shop checkout, search functions, and seller dashboards. Their iOS team has even built their own custom utility to assist with VIPER called VIPERBuilder, to best suit Etsy’s evolving development design needs.
Additionally, there are other product builders and service providers who have benefitted from VIPER over the past few years. Some of these companies take elements to build upon, and some of them have even outlined their success stories and user journeys while fully adopting VIPER.
A counterexample of an app that would not benefit from VIPER would be an app for an event like the Olympics where lifetime maintenance isn’t important. People use the app for two weeks and then probably delete it. In four years, for the next Olympics, you’ll most likely start with a new codebase, rather than update a four year old project.
VIPER primarily focuses on the three designers common to most apps—business, interaction, and visual designers. As Steve Jobs said, “Design is how it works”. Anyone involved in deciding how an app should work is a designer. You might also have marketing design (analytics), security design (e.g. storing sensitive data, credentials), etc. VIPER certainly allows you to form those same separations for all designers. Hopefully, it will encourage the entire team to acknowledge/accommodate all forms of design.
These days I use the term VIPER as an umbrella term for the entire development process I’m exploring, rather than just the architecture. I’m continuing to refine/expand my process. With the nice separation of the visual design, I’m working on making it easier to help visual designers perform visual QA work.
Today I can write tests that represent all the different combinations of content shown on a screen and generate screenshots for multiple device sizes. I’d like to figure out a way to use a tool like FitNesse to allow the visual designers/QA to write the tests.
