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.
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.