How learning SwiftUI has made me a better designer

Understanding how the software I design is actually built is a must for me, and at work I'd been feeling the pain of not really understanding how native mobile apps are built. When I'm designing web apps I know all the internals and thus have a strong sense of what's actually possible in that medium, but native mobile felt like a dark forest for me. I constantly found myself in situations where I was designing things that I couldn't be sure were exactly right, or whether they could be built and with how much effort. These ranged from larger-scale navigation decisions to smaller interactions.

Then at WWDC 2023 I saw a presentation geared towards designers, about using SwiftUI as a design tool. As a designer who loves to program, and who also happens to work on an iOS app, this grabbed my attention. I started experimenting in Xcode and found that it was not as intimidating as I'd remembered. I followed Apple's official tutorials. I took a Stanford course (CS193p) about SwiftUI development. I read the Swift documentation. I tried building the things I was designing at work, data and all.

All this has led me to develop a greater understanding of and appreciation for native mobile app development, at least for iOS. I've found myself designing more confidently and relating more easily to engineers on our team, with whom a language barrier often makes communication inelegant. I want to mention a few specific ways that learning SwiftUI has helped me, in the hope that it will inspire other designers to do the same.

Understanding system defaults

In native app development it's important to know whether the things you're designing are supported out-of-the-box, or if some level of custom build is required. Understanding exactly where the line is helps you make more intentional decisions about when to align to or depart from native functionality. For example, if you design a bottom sheet component, it's helpful to know just how much customization can be done to the default iOS sheet component. Knowing this helps you weigh trade-offs like the amount of work it will take to go custom or the possible usability costs of diverging from common system patterns.

Easy responsive design

iOS is a dynamic platform with tons of variables and device settings that are almost impossible to simulate in a mostly-static design tool like Figma, at least without a lot of manual work. Before getting into Xcode, I was mostly designing everything at one device size (sometimes checking things on the iPhone SE size). Dynamic Type (user-controlled type scaling for accessibility) was an enigma. There are 12 separate type scales that a person can elect to use and I couldn't tell how larger or smaller scales would affect my layouts. Xcode makes toggling between all of these devices and accessibility settings trivial. I can instantly see how my design decisions play out in a variety of scenarios.

Easier handoff

Rather than fastidiously mocking up screens in Figma and hoping I get the measurements right (it's not always easy to tell what the correct values are), I can pass engineers the real SwiftUI modifiers and get the exact UI I want, with nothing lost in translation.

Designing with real data

I can take mock data from the actual API and structure my UI around that. Understanding how the data are structured is useful for any designer, and I think the best way to develop that understanding is in-context. In a recent project I worked on, using real data also helped me see what wasn't coming from the API and that fostered conversations about whether we could get the data, or structure it on the client side.

What's next?

I look forward to continuing to integrate SwiftUI into my design process. The problem I'm most interested in solving right now is figuring out a way to make my SwiftUI prototypes more shareable amongst a team of stakeholders, because that's the biggest weakness of the whole process. The possible solution that I'm most interested in leverages App Clips.