Speeding up iOS Development for Agility
In conversations with product managers and engineers on iOS development, I’ve found myself saying the following over and over again - iOS development is inherently slow. Let’s face it, it’s not web – but there’s definitely ways to make sure your team is performing at a fast velocity. This has become very crucial for us at Frank & Oak, moving fast, running tests and shipping is very important for an e-commerce company.
As with every product, there are a lot of moving parts. The list can go on for a while, but here’s a few high level aspects I’ve found to be useful to pay attention to:
Design for mobile, not web
I’ve seen web designers come in and throw iOS designs together that are not only poorly optimized for development but also lack proper UX. With mobile having such small real-estate, you get to (have to) focus on doing a few things really well. You have to design with this same mindset. When you design for mobile, you have to make sure that there are only a handful of UI components you’re using within your app.
There should be only 1-2 ways you display buttons. 1-2 ways you display a menu. 1-2 ways you display a list. 1-2 ways you display an image. And so on.
Let’s take a look at Path here as a demonstration. Take a look at the colours they’re using for the table cells and the table header cells in these two different views:
They’re using the same aesthetics and not much has changed between the two views - other than the content of the cells, of course. These kinds of designs will encourage creating UI components that will be used within your app.
In fact, I’m a big fan of object oriented UI design, because you can create reusable and scalable UI component classes (within or outside Interface Builder) for your app.
This will also speed up development as you just have to “put views together” instead of building them from scratch.
APIs should be ready or ahead of iOS
APIs should be tested and production ready. If you’re already using them on a web product, that’s always a good indication that you’re closer to being ready than not.
I’ve had backend and iOS teams work alongside each other or the iOS team be further ahead of the backend team, but as long as the APIs are functioning properly and they’re well designed, the iOS team doesn’t need to interact with the backend team as much when developing the views. This is because the API is merely a supporting function to views in iOS.
This takes a lot of planning: include both teams when designing the API, talk about how it’ll be used, what APIs might be missing, and what the data-flow should be like.
What I like to do is think of APIs as a mapping of User Stories (very common, I know):
Think in detail about what the user flow is like and try to find a RESTful way of taking the user from each flow to the next. Including both teams in this process creates an understanding of what they’re going to be building which helps them solve for how to build it better.
“Ship” every week
Your team should be getting in the habit of shipping weekly - to beta testers or to the app store. If they’re in this mindset, they’ll start being able to include more and more stories/tasks in their cycles each week. If you can’t hit one week at first, try bi-weekly cycles until you can get to weekly. Engineers coming from web to mobile aren’t used to being very structured for pushing code, because you can push to production whenever you want on web.
Set a day in the week that you’ll be sending out builds to your beta testers and employees. Use tools like TestFlight or HockeyApp to make sending out builds easier for both the developers and the beta testers.
Depending on what kind of product you’re building, you can also push to the AppStore on a set schedule as well. You can do as fast as weekly to bi-weekly or monthly submissions – Apple’s review times are down to around 5 days which is a lot faster than it used to be.
Always be shipping.
Subscribe to my mailing list for more posts aroud mobile, experimentation and product management here.