A Designer’s Take on SwiftUI
This year Apple gave us SwiftUI—a new, intuitive, framework for building native user-interfaces. Will this usher in a whole new era of code-writing front-end designers who craft native experiences — the same way CSS3 did for web designers in the early 2000s? Let’s explore this idea.
A little background
About a bajillion years ago, when I first started designing for screens — it was for the web — and it was when the web was viewed, almost entirely, on large desktop monitors. When starting up a new web design project, a typical workflow might go something like this: talk to the client, sketch out some hierarchy and messaging, then open Photoshop and painstakingly draw a pixel-perfect website.
Except, it wasn’t a website. It was really just a picture of a website. Problem is, you can’t ship a picture of a website. You would need to turn it into something that a web server could serve up to all the web browsers that called upon it. And in these early days, since websites often consisted of awkward table layouts and hard-to-manage inline styles, a lot of designers, including me, didn’t want to get in to all that racket. So, perfect-picture-of-website in hand, I’d send it over to a “chop-shop” where they would magically slice and dice my Photoshop file and turn it into a real web page. Back then, this seemed like a pretty good way for a designer to make websites. But, the web is always changing.
A new way to design
So, let’s move along to when the web really started growing up — when CSS3 and HTML5 were becoming a thing. All the gradients, shadows and rounded corners your designer-heart could want were now created with just a few lines of text. It’s like Photoshop, but using words to describe your design. It was amazing!
All of a sudden, I found myself, along with a lot of other web designers, ditching Photoshop and starting to “design in the browser”. A text editor on the left, a browser on the right and a quick save and refresh to reveal your design right in the browser! You could see this thing starting to come alive — and it was a real website!! You could even send a link to your client and they could view it in their own browser (probably in IE6 🤦🏻♂️)!
The great thing about this new workflow is that while you are “designing” a website you are also simultaneously creating something shippable. You could see your design rendered right there in the actual medium. You could test your design on various operating systems, in different browsers and with multiple screen sizes. Accessibility considerations were no longer an afterthought. They were right there front and center.
Designing in the browser opened up a whole new side of design-thinking for me. It taught me about architecting design systems and practicing atomic design. Soon, I learned some PHP and Javascript which allowed me to begin wrapping a layer of logic into my design — enabling reusability, changes in state and dynamic content. Ultimately, it got me thinking more like a programer and I loved it.
Going native
Fast forward to 2017 when I transitioned away from designing websites and over to designing native mobile apps (iOS and Android). All the tools and workflows I had spent time practicing and perfecting on the web no longer existed in this new environment.
By now, there was a whole new wave of really incredible design tools on the market like Sketch, Figma, Flinto and Framer (and so many more). They were built specifically for interface designers. They were great and I loved this new medium but I found myself begrudgingly going back to just “drawing pictures” that needed to be handed off to developers to turn into something shippable.
Don’t get me wrong, I still love using tools like Sketch and Figma. They allow us to create remarkably realistic prototypes including realistic movements and transitions. But all too often we have to go to great lengths in order to do so. We duplicate multiple screens just to give the appearance of a single dropdown and selection state. These prototypes also tend to be very linear. To create a realistically dynamic choose-your-own-adventure experience, you’ll quickly discover the n+1 problem. Sketch, Figma and their plugin ecosystems continue to introduce bits of logic and other improvements that streamline these efforts. But, should that be the role of these design tools? Should we be spending so much time creating something that isn’t “real” — something that isn’t shippable?
Well, given the learning curve necessary to implement interfaces for native mobile apps, these design tools have been part of a necessary workflow. We’ve needed these tools to map out complete experiences because it is so much faster than creating a similar experience natively. There has yet been an equivalent to “designing in the browser” for native mobile apps. I believe that is about to change.
SwiftUI
This past June, Apple revealed SwiftUI — a new declarative framework for building native interfaces for their platforms. So what? Well, for me, it means designing interfaces for Apple products is going to be a lot more like it was designing interfaces for the web. When I first saw Apple demo their new SwiftUI it felt like it was directed right at me: code editor on the left, simulator on the right — a quick save and refresh to reveal your design right there in the simulator! How awesome?!
No more time-consuming build and run compilations. No more non-human-readable storyboards and XIBs. Just a nice, clean, easy-to-read, declarative language for creating interfaces.
Now what?
So what happens, then, to the amazing design tools we are currently using? Do they go away? No, absolutely not. What I hope happens, though, is that we use them a bit differently. Early in projects, I’d like to see designers focus more on exploration and iteration of creative design solutions and innovative user interfaces — not painstakingly creating the appearance of a real, full-blown app.
Yes—use symbols and components; use layout constraints; use everything that tools like Sketch and Figma provide to make good decisions about how a design should flex and adapt. Just don’t duplicate all the same efforts that will be necessary anyway in code. Let design tools help us focus on aesthetics and the conceptual nature of the user experience. Let code handle the precision, nuance and implementation of component libraries and design systems.
I expect in the near future, crafting entire interfaces and flows to be as quick or perhaps even quicker natively in code. Ship these real native experiences via TestFlight and Beta, not through websites and mirroring apps. Let clients and users test on their own devices and with their own settings so designers can make better decisions around native accessibility options like font size, increased contrast and reduced motion.
I believe the quicker designers can implement and test real interfaces on real devices, the more successful our work will be. I already see many designers straddling both the conceptual and the logical sides of user experience design for the web. With SwiftUI, I think it is now time for native designers to do so too.
What do you think?
Well, that’s my point-of-view. What am I missing? What challenges will native mobile designers face in this new era of SwiftUI? I’d appreciate your perspective.
