This is the story of how I got to have an iPhone app work on iPad with a fairly different layout in just 5 hours of work. I’m sharing a few insights, but note this is not a secret recipe and it’s not be applicable to all projects.
This summer, I helped my friend Luc and worked with him on a new version of his company’s flagship app, Screens. Screens is a VNC client, an app that connects to a computer remotely and allows to control it. Early on, Luc had decided the app would be iOS 7 only, and that we’d start the project from scratch.
While at WWDC, as iOS 7 was unfolding before us, we exchanged about how the app could look like, and how we could take into account what we were learning that week: full-width images on iPhone, motion effects, blurs, tint color and so on.
Because the app already existed both on iPhone and iPad, we also knew from the start it would be a universal app. So as we debated on the app’s design, we considered both iPhone and iPad at the same time. Luc drew a few sketches and Thomas, the designer, quickly got back to us with pretty good mockups. The app’s design hasn’t changed much since these mockup.
They look different, yet they are the same
The app is composed of 3 main views:
- saved screens: the remote computers you connect to often
- discovered computers: the computers on the local network the and remote computers
- the remote view that is displayed when you are connected to a computer
The last one is exactly the same on iPhone and iPad, it shows a full screen live view of the screen of the computer you’re connected to. We’ll focus on the first two views.
On iPhone, the saved screens is the main view, and the discovered computers view pans over. On iPad, they are laid out side by side.
Same view controllers, different storyboards
There is only one view controller for each view, then there’s a storyboard the iPhone layout and different storyboard for iPad. Some of the differences between iPhone and iPad are handled in the code, but most of the design and layout is done in these separate storyboards.
This is especially interesting in the case of the saved screens, where it’s a list on iPhone and a grid on iPad. You can now guess we went with a collection view. It’s even the same collection view cell object for both iPhone and iPad.
As we were thinking about the app’s design, we kept considering how we’d have to handle the development too.
Make sure all works on iPhone before moving to iPad
So this is how we approached the app’s development. We made sure we had all the functionality work on iPhone before even starting on iPad. Since we already knew how the app would look like on iPad, we knew beforehand we’d use a collection view instead of a table view on iPhone.
It took a couple of weeks to have something working pretty well on iPhone. At some point, though the app was still far from being perfect, we knew all the core functionality and logic was there for us to add the iPad layout.
Then it was breathe: set the project as a universal app, add the iPad storyboard and set the collection view’s layout properties, and handle some differences in the code when necessary.
In no more than 5 hours, the iPad version of Screens was working as well as on iPhone, with a different design. I didn’t expect it’d be so easy to be honest.
Plan ahead, design with development in mind
Imagine if we had used a table view on iPhone and a collection view on iPad. How would have we handled that? We’d probably have ended up with more files, a lot more code, and more pain to maintain that code.
I think the reason it went so fast is because of the way we planned the design and the development together. It doesn’t work that well for all projects, but whenever you can, try to think about development effort as you design your app.
This post is based on a presentation I made at CocoaHeads Paris on December 12th, 2013. You can view the slides here.