What I Learned Last Week: How to Translate a UI Design into iOS UIKit Elements — Part 1 of 2
One of the most daunting aspects of iOS app development is trying to understand which UIKit elements to use when implementing a design concept. In this article, I describe the process I use to make implementation decisions based on a concept design from a recent project.
The choices made by the designer usually have a direct impact on the complexity of the Swift code for your iOS app. You certainly don’t want to create even more complex code by choosing less optimal UIKit elements to implement the intended design. One of the best skills you can develop as an iOS developer is learning how to see a concept design as an arrangement of UIKit elements. This approach is very similar to how artists learn to sketch. They learn to create basic geometric shapes such as straight lines, curved lines, circles, cylinders, etc. and then they learn how to combine those basic geometric shapes to create the beautiful sketches we all admire. The key is being able to look at a scene and dissect it into those basic shapes, so they have a starting point. As iOS developers, we can apply the same approach.
One of the best skills you can develop as an iOS developer is learning how to see a concept design as an arrangement of UIKit elements.
In Part 1, I’m going to focus on the significant constructs of breaking a design down and matching its elements to UIKit elements. Next week, in Part 2, I’m going to focus on the UICollectionViewCell and UITableViewCell elements since they are relatively complex in this example design. In this article, I treat them as whole elements and not break them down into their UIKit elements. You’ll have to read Part 2 to get those details.
In the meantime, let’s get started.
Overall App Flow and Structure
The concept design suggests two approaches for presenting content and interacting with the user.
The first navigation type is mode-specific, which calls for a UITabBarController. The various views/modes are Home, Favorites, Home Location, Shopping Cart, and Account views. Each of these tabs would have a separate view controller to present specific content to the user and respond to user interactions based on the mode. For example, for the Account mode, it would most likely have details like username, email address, password change, etc., but the specifics are beyond the scope of this particular design concept.
The design concept also points to the use of a UINavigationController. How did I know that? There is a “back” button in the righthand screen, which is a dead giveaway for this type of control. It allows a user to progress through a predefined set of screens in a logical process (e.g., discover shoes and add them to the cart → show the cart → confirm/submit order → display order information).
Now that we have a basic idea of the “flow” for the app, we can begin to define further the UIKit elements contained within the design by looking for significant elements like tables and collections.
Content Views
When you observe sets of the same type of information repeated, it is a clue a content view will best fit the bill. For example, in the right screenshot, a table displays the shoes already added to the shopping cart. Each cell contains the same information (shoe name/title, price, and quantity) for each pair of shoes in the cart. In the left screenshot, we see several examples of repeated information types such as Brands/Manufacturers, Products (shoes), and More shoes at the bottom of the screen.
How do you know if you need a UITableView or a UICollectionView to represent repeated type content? I use this simple rule to decide:
- If the content should be presented with vertical scrolling only, then use a UITableView (example: cart contents in the righthand screenshot where scrolling is vertical-only)
- If the content should be presented with vertically and horizontally scrolling or horizontal scrolling only, then use a UICollectionView (example: shoes in the lefthand screenshot where scrolling is horizontal-only).
Once you know the specific content view to use, then you can focus on the elements that should make up the cell for the repeated content. Each cell likely contains labels, images, buttons, etc. so I have not highlighted them in my design image in this article. I will focus exclusively on table view cells and collection view cells next week in Part 2, where I will detail the same “seeing approach” for UIKit elements for the cells.
Buttons
After understanding the general flow of the app and the content views, I next look for buttons the user would tap to interact with the app. These buttons also help me gain insight into the programmatic and logical aspects of the app.
User actions such as taps are often captured and enacted via these buttons. The UIKit class is rightly named UIButton. These buttons execute custom code to carry out the action the user expects upon tap (usually touchup inside the bounds of the button).
Labels
So what’s left? Elements that present data to a user without any intent for user interaction. These elements may change as a result of a different user action, such as increasing the quantity of a cart item so the total amount updates accordingly. UILabel elements present this type of information to the user.
Stack Views
After I’ve dissected the design’s structure and have some general ideas of the individual UIKit elements I can use to implement the said design, I start looking at how those elements are fit together in the visual layout. I look for rows and columns (outside already identified content views like table views), which are relatively familiar in most iOS apps.
An essential UIKit element you should consider for this layout type is a Stack View, which is a streamlined interface for laying out a collection of views in either a column or a row. The UIKit element is known as a UIStackView. It enables a developer to align and distribute elements more easily. Additionally, these views resize to handle the different screen aspects (e.g., Compact Horizontal and Compact Vertical, which is landscape orientation for an iPhone). These are compelling elements, so invest some time learning their nuisances so you can get the most out of them.
That’s it for Part 1. Stay tuned for Part 2 in the coming week.
Stay safe, and keep learning!
