Build an App Like Lego — An Intro for Designers
Build your prototype and design library as real native components, to not just convey intent, but to be the intent.
Your Mission
As a visual designer, your goal is to convey the intention of your designs to the developer, in a way they can use to build the app. You have to include elements like motion, colours, layout, icons and font. Importantly, but usually overlooked, you should also describe which areas will stretch, shrink or move on different sized screens. You should describe what should happen when the keyboard appears, which keyboard should show for different inputs, in which order they appear and much more.
Currently, you might mock it up in Sketch, Figma, Axure, proto.io, Framer X or create sketches or a PDF with redlines. But, is that the best approach?
The Problem We Need to Solve
As the designer, you are building something to convey intent, but the developer will have to re-build it all using their native tools. You might make some amazing prototype of an app, but then the developer has to recreate everything you just built, using a completely different toolset. The more “amazing” the prototype you create, the more work it’s going to take the developer to invent additional components on top of their existing native toolset. You’re both going to spend many weeks tweaking the developer’s version to try to match the designer’s version. Every time you want to make a change, the cycle of duplication, waste and misalignment continues.
This isn’t a new revelation. Designers have seen this disconnect for some time:
“Design tools are running out of track” — Colm Tuite:
As long as designers continue to use a woefully inadequate medium to communicate their work, that work will always be open to misinterpretation…
…Ultimately, all mockups are disposable, yet designers spend months tweaking them to perfection. That time would be much better spent tweaking the actual product.
“Only one deliverable matters” — Josh Clarke:
Our industry builds generations of carefully crafted, disposable facsimiles before even writing a line of code. It’s a waste of time, effort, and resources.
No matter how much prototyping tools promise “just like a native app” or “feel real”, the result is by definition not the real thing. The prototype will have subtle and major differences to the native app. Even Sketch has rendering differences that mean that the final app will not match your designs.
“Why Your App Looks Better in Sketch” — Nathan Gitter:
As you can see, some aspects of the original design can be lost during the conversion from the design file to real code…
…If you’re a mobile app designer or developer, you know how important small details are to the end user experience. High-quality software can only come from people who care deeply about their craft.
You have no guarantee that the developer will create a match when they rebuild your design. When you test your prototype with users, you can’t have confidence that their experience and feedback reflects that of the native app.
Automated Code Production?
One commonly discussed strategy is to use an automated tool that generates code from the design assets. It sounds like a good idea: design with a visual tool, press a button and generate code. Problem solved, right? No.
The hitch with automated code generation is that it’s a one way street. Once you generate the code, you can’t look at the code to see the design. When the developer tweaks that code output, it is immediately out of sync with the design input. There is no single source of truth and the design inputs have to be discarded.
There are some niches where automated code generation does make sense. The test is whether the developer will need to modify the generated code.
For example, PaintCode does a terrific job of generating visual design assets, including icons, infographics, reusable “symbol” graphics, and a hierarchical color palette. You can export all of that into a “style kit” code file that can be used by the app developer, as-is without needing to modify the code.
You might be tempted (as I was), to take PaintCode further to design a whole scene in an app or even just a cell containing two text labels and an icon. But that crosses the line to where the developer will need to rebuild your design, so it would be wasted effort.
So, the question remains, how can we create a design library and prototype for our app, in such a way that it can be used directly by our developer, further designed and engineered, without waste?
The Solution
What if, as a designer, you could build the components to be used in the final production app? These components will not just convey intent, they will be the intent. The developer can use them immediately, without disassembling your creation and recreating it from scratch. They can enhance your components and share them with you, so you’re all working from the same design library.
These components will not just convey intent, they will be the intent.
But, of course, you’re a visual or UX designer, not a developer. You want to be able to create these components visually. You might not want to write a pile of code, especially when you’re just brainstorming a prototype. You want each picture to paint the thousand words.
For iOS, the native developer tool is Apple’s “Xcode” software. Using Xcode out of the box (or fresh from the Mac App Store) isn’t going to get you far with designing apps. It is fundamentally a developer’s tool. Most Xcode tutorials will introduce you to the “Swift” programming language with perhaps some visual tools along the way. That’s not an efficient method to create visual designs.
In this tutorial series, we will take a different approach. We will focus on Xcode’s visual tools to build components and whole app flows. As we go, you’ll probably recognise that a lot of the emerging prototyping tools like Adobe XD and Framer Studio are actually starting to look like Xcode’s GUI tools.
We will drag in components like tab bars, images and text labels from a component library, and set attributes such as colors from popup menus. We will create our own visual components and build it all using solid engineering practices. We will build it like Lego, one block at a time.
Our objectives on this journey include:
- Build a prototype of an app using the real tools that developers use.
- Build components that can be used in the production app.
- Build components that can be shared with the developer, who can enhance them and share back with us.
- Eliminate wasted prototypes that developers can’t use directly.
- Learn how to use the components that are available for building native apps.
- Quickly and confidently validate UX and layout by running an authentic native app experience.
The Goal
In this tutorial series, we will build a simple iPhone app that looks something like this:
We will build this as a fully native app. It will run on an iPhone. You can give it to your developer to tweak. It won’t be a wasted prototype that they have to rebuild or an experience that claims to “feel real” but is actually a fraud.
Get Started
Jump right into Tutorial 1 of the series “Build an App Like Lego, using SwiftUI”. We will start with the basics of creating an app from a template.
