We've all seen the tutorials. A developer on YouTube builds a beautiful
weather app in ten minutes. It all looks easy. Drag a few views around,
drop in some \@State and it works. You decide to try it when your boss
asks for three new features. A few minutes of working on it or hours
later, it keeps crashing.
Building a prototype is easy. Building a SwiftUI app that survives a
year of growth and changing deadlines is not. Here is a guide on writing
a SwiftUI code that lasts.
Why Codes Don't Survive
Before we get to how to write code that lasts, let's get into what a lot
of us get wrong. A common mistake is the 500-line file that tries to do
everything. Buttons, text, logic and styling in one property. It will
work well at first until you need to change the login logic and you are
digging through 400 lines of UI code to find one function.
Karan Pal, an iOS
Architect, frames it better:
"You end up building UserListItem,
ProductListItem and other 10 nearly identical components that differ
only by data type. There is a better way!"
The first trick is to think of UI like Lego bricks. Each piece should do
one thing. If you have a profile header, let it be in a separate view.
Small views are easier to read, test and more importantly, easier to
replace.
Therefore, should the design team decide headers are better in blue than
green, you have to edit one small file. You don't need to risk breaking
the whole screen for minor edits.
Get on Top of The Data
Data is where SwiftUI apps get to crash. In a small demo, using \@State
everywhere is okay. In a real app with 20 screens, it becomes
challenging. You are forced to pass variables down ten layers of views.
The key to your code surviving is finding one source of truth for your
data. Let one manager handle the data. It should get the data, display
it and send action back to keep your logic out and your code stable.
This makes it possible and more efficient to swap an entire UI for a new
design without touching the app's logic. It becomes possible to meet
deadlines even when requirements change at the last minute.
Avoid Different Views
What do you do when data exists in two places at once and they don't
match? Imagine a shopping app. The user adds an item to their cart. The
button says "Added," yet the cart icon at the top still displays "0".
What next?
This clash happens when you have two different views trying to manage
the same piece of information. In a professional app, you need to be
strict.
Views should not decide how to calculate discounts or if a user is
logged in. It should ask a ViewModel, "What do I show now?" Move logic
out of the SwiftUI view into a plain Swift class to verify your logic
without running the app to save hours.
A Swift Author & Consultant, Donny Wals, emphasizes this. In his
article
he says:
"When you notice you can express an impossible state in your
app due to a growth in variables that are intended to interact
together, use enums to represent the states your app can be in."
Do Not Hard Code Values
Truth is, designers keep changing their minds. It is part of their job.
Your job is to find a way to add their changes when requested without
destroying the code. Therefore, do not hard-code values until the design
team approves.
A good example is a designer who says the gap between elements is 16
pixels. Do not take their word for it and type in "16". If they later
change it to 20 pixels next week, you will be forced to find every 16 in
your project and adjust it.
Create a theme file. Define your spacing, colors and fonts in one place.
If the brand changes from purple to orange, you change only one line of
code in 30 seconds or less.
Why This Matters for Navigation
In a small demo, navigation is easy. In a real app, it is a mess. There
are deep links in notifications and "Success" screens that need to pop
back to the start. If you hard-code your navigation inside views, you
are trapped.
Sunny
Gulati,
a senior iOS Engineer, advises using a Coordinator. "The professional
solution is to use the Coordinator pattern with NavigationStack. It
separates concerns- views focus on UI while coordinators handle the
navigation state. The app remains scalable.
Professional SwiftUI code uses a central place to handle where the user
goes. The view says, "The user tapped on Settings," and a separate
router decided where that goes. Your app becomes flexible. Should the
Settings open a web view instead of a native screen, you only change one
line. You don't tamper with 15 different views.
Write for the Future
We say we write code for the team. Truth is, you are writing it for
yourself six months from now. You won't remember why you wrote that
weird statement, especially if you are working with a tight deadline.
How often do you handle the things you promised yourself to fix later?
Later never comes. Always write code that is readable.
I once wrote a complex, one-line function that looked like a math
equation thinking it was smart. Months later, a junior developer reached
out about it because they couldn't understand it.
Use long, descriptive names for your variables in place of short,
cryptic names. Yes, it is tiring and involves more typing, but it will
prevent bugs.
Do not Use Hacks
Let's be honest. At some point, we've used hacks to meet deadlines. The
problem is, hacks become debts that we need to pay back. Say you write a
hack to get a feature out on Friday and schedule time on Monday to fix
it. If you don't, it will build up until it gets to a point where you
cannot add new features.
A SwiftUI code that lasts should remain understandable when it gets
bigger. If your own code is hard to read with every month that passes,
it will eventually crumble.
As you test to catch bugs, gather the confidence to change your code. If
you want your code to survive growth, you need to be in a position to
refactor it. You cannot refactor safely if you are terrified that
changing a logic function will break something or everything else.
Avoid Third-Party Libraries
It is tempting to grab a library for everything. Need a chart, a custom
slider or a way to handle network requests? Download a library. There is
a library for almost everything and at the moment, it seems like a
lifesaver.
Every library you add is a dependency you don't control. Apps die
because they relied on a library that the original creator stopped
updating. Then, Apple released a new version of iOS, the library breaks
and your app is stuck in the past.
Take Away
SwiftUI is a great tool. It gives you the materials. This doesn't mean
it builds the app for you. Writing code that survives needs you to be
picky and think long-term.
Get on top of the data, write for the future, avoid hacks and say no to
libraries that seem too good or too convenient. If you do this, you will
meet your deadlines and build a code that lasts. In the process, you'll
start enjoying building.
Top comments (0)