Designing in Xcode with Roomee

Substantial
Apr 19, 2019 · 4 min read
Image for post
Image for post

Over the last few weeks, a pocket-sized team of developers and I decided to tackle the constant problem of finding an empty conference room on the fly. Specifically, we wanted to get rid of the awkwardness that happens when you’re sitting in what you think is an open room, only to be bounced out because someone actually reserved it. For me, it was an opportunity to learn more about the details of Swift and Xcode while improving my ability to collaborate with our developers. There was also the challenge that we needed to experiment and work nimbly, because we were a compact team with a condensed timeframe.

Our solution was “Roomee,” a lightweight app to view and book conference rooms in 15 minute increments. It presents a list view of rooms that are open or available within the hour, allowing you to add and extend meeting times or see what’s coming up. Sure, you could use Google Calendar — but Roomee makes impromptu scheduling much easier. Instead of having to put in a ton of details, just a few taps can help you when a hallway discussion demands a room or when it turns out your conversation is running a little over time for what you had booked.

Building Roomee

We used Swift 3.0 and Xcode 8 storyboards for most interface layout and containing logic. On the backend we used Elixir, Phoenix, and GraphQL for server side application and runtimes.

Once the bulk of the backend was in place, I paired with a developer for some on-the-fly visual design. By on-the-fly, I literally mean we were designing at the same time as writing code — something not typical from the very start of a project. So, I decided to keep things simple — using the standard Xcode components — since we were building a few primary scenes with basic lists and actions, not an elaborate design system. I also stuck with one font weight and photos I shot with my iPhone. After a week of experimenting with our front end system, I learned some valuable takeaways from this strategy:

  • Reusable objects are not supported when designing in Xcode storyboards. If you’re planning to reuse similarly designed components throughout the layouts in your app, it’s best to write custom classes that can be imported universally. This was our experience in past projects, but learning more about storyboard and object limitations should help with future project estimations.
  • Constraints in Xcode are valuable for maintaining support for the variety of iPhone sizes and aspect ratios. It can be difficult to determine which type of constraints to use for any given problem. There are a variety of ways to solve the same problem, therefore it’s best to determine how and where you want each object to scale before you start assigning constraints. The complexity of your view’s constraints can ramp up quickly when you have lots of objects sharing dependencies, or with complex stack views. Practice and experimenting with various layout types was the quickest way for me to start feeling comfortable with the system.
  • The Simulated Metrics in Xcode were a helpful tool for getting some free design, but if you’re building a highly customized system and not iterating off existing iOS patterns, the level of effort and scope can dramatically increase. Customizing header styles, button and icon styles required some decent setup time. Make an assessment as early as possible on the cost of implementation for your design and with which objects and classes in Swift you have the most flexibility.
  • Vector files can be a pain to implement as iOS either wants a CoreGraphics version of your file, or PDFs that convert to raster images. We experimented with PaintCode, which has a Style-kit exporter to that we used to build icons using CG points, and to serve as a single file for colors and icon references.
Image for post
Image for post
Image for post
Image for post

Roomee has been published to TestFlight.

development design swift iOS prototype experiment xcode

Read more by Paul Norris

Find us at substantial.com or reach out directly at newbusiness@substantial.com.

Originally published at substantial.com on May 16, 2017.

Substantial

Written by

An innovation + build studio in Seattle, WA.

Substantial

Substantial is a digital product studio creating best-in-class software that lowers risk and creates faster outcomes through strategy, design, & development for web, mobile, and connected devices. Learn more about us at substantial.com.

Substantial

Written by

An innovation + build studio in Seattle, WA.

Substantial

Substantial is a digital product studio creating best-in-class software that lowers risk and creates faster outcomes through strategy, design, & development for web, mobile, and connected devices. Learn more about us at substantial.com.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store