We developed the new Parable iPad app in just 2 weeks and released it to the App Store recently to complement our iPhone app. Here’s how we did it:
Have a Tablet Design Strategy
Not all consumer products warrant a tablet presence and having one adds maintenance overhead. First, have crisp reasons for an iPad app - user engagement, acquisition or product distribution - that will help guide development decisions. Outline the functionality to expose to your tablet users - you don’t want to confuse your iPhone users by adding iPad specific functionality. Then, define all interaction flows and lay them out end to end. Iterate quickly with users. Design every screen to maximize the tablet pixels while leveraging as much code and visual asset reuse as possible - different asset sizes for same icons can spiral into a lot of design work. Finally, you want to delight your users with custom built tablet screens, so avoid building expanded versions of your iPhone app!
Assemble a Cohesive Team
A majority of the development time is consumed in iterating through design variants (color, font, layout etc.), interaction flow changes and visual asset creation. As a result, hundreds of decisions need to be made. Product, design, and development need to work closely in sync to reduce collaboration overhead. Be ready to answer questions and make fast decisions within minutes. If the team isn’t co-located, explore lightweight collaboration tools like Trello. Standard best practices of avoiding scope creep and prioritizing ruthlessly matter more in fast development.
Use latest iOS features
With the introduction of new device displays, Apple has made development for different form factors easier with recent iOS updates. Research and use these features whenever possible - auto-layout, constraints and size classes are friends who will save you time. Performance issues from iPhone get amplified on the iPad e.g. scrolling the same table cell could be more jarry on a big screen than on a phone. StackOverflow has the most insightful explanations and workarounds for all your technical problems.
Build an Extensible Backend
Backend architecture is critical for product extensibility. A well-designed backend not only reduces release time for new channels, it also trims code maintenance by reusing exposed server functionality. We wanted Parable to be available to users across mobile and desktop devices. The Parable backend was developed on a multi-client model from the outset. Our model used the Node+Mongo stack accessed via simple Rest APIs. Building a new iPad or even Android and web versions now involves developing just the client code and no server changes, dramatically reducing release time.
Thoughts, comments? I’m @amitpaka (cofounder at Parable - @GetParable)
