Things to Know When Coding in SwiftUI
The things I discovered in my SwiftUI project that I’ll definitely use in the future
SwiftUI has got me pretty pumped.
Mostly because I had already been messing with other reactive frameworks for a while and I get the concept, but also because I already see the benefits over storyboards/IB and the viewControllers behind them.
And, as much as I’ve mastered Auto Layouts and constraints, I’d be more than willing to hang up that badge if SwiftUI can truly take the wheel.
While messing around, I took note of some things that I realized were quite useful to know for the future (or would’ve been nice to know ahead of time).
Some are regarding Xcode and the editor, others about SwiftUI and how it works. Not everything here will necessarily be new to Xcode users and may seem elementary.
Still, if it’s here then it means I found it worth noting in regards to SwiftUI, especially because I believe some folks may break into coding using the new framework.
Let’s get to it then…
The + in the Top Right
The ‘+’ is not necessarily a new thing for Xcode and by now you may not even use it at all.
But, if you are unsure which views and controls are available in SwiftUI out-of-box, or have ever used the controls menu when using Interface Builder or storyboards, then consider it your guide.
All of the included SwiftUI views are listed here, along with their respective descriptions. And, on the next tab, there’s a list of modifiers for those views as well.
This is also the menu where you can checkout code snippets, image references, and colors.
CMD+click on a SwiftUI View
CMD+clicking things is nothing new. However, when you’re working with a new framework that makes up your UI, it’s probably worth revisiting. And in this case, it truly is.
The menu that pops-up really gives you everything you want to dive into on a specific view. I do like the standard ‘definition” and “callers” options, but some of the other options can open up opportunities for your code that you may not have been aware of or blanked out on.
I’ll dig deeper on some of the options further down the list but this is a must-use when editing in Xcode.
Effectively Testing Navigation in Previews
Preview is awesome. And it’s probably one of the main reasons you’re psyched about using SwiftUI (or not, it’s your call). To me, it’s part of the core of SwiftUI development, and that’s why it’s not on this list.
But, one of the coolest parts about previews is setting up test data and conditions so preview has something to work with.
While working with navigation, specifically detail pages, a good tip for testing your page within a navigation flow is to wrap it in a navigation view.
This may seem weird because you’re setting where you’re navigating from, or any other details, from a previous page, but that’s ok. You define that here. We just want to know how our page looks within that flow, the rest is up to us to mess with and observe.
Test Data Doesn’t Have to Stay in Preview
While we’re on the topic of testing and previews, this is more of a reality check than a feature.
You’ve probably already watched all the videos in the WWDC 2019 SwiftUI Collection and have seen them talk about providing test data in the preview method and how awesome it is a gazillion times. And it is.
But don’t get carried away. It’s not the end-all, be-all. It can still be worth testing your app, compiling and running it the traditional route, in which case you may want that test data to exist beyond the confines of previews.
Or, if this is just a demo or POC app, really consider the situation and ask yourself: “Do I really need to keep this in previews at all?”
Just cause it’s available doesn’t mean it’s the only way or the best way. Don’t feel limited to new features or patterns. It’s merely a tool and an option.
Body View Doesn’t Get Any Properties
After I built one of my experimental apps in SwiftUI, one of the first things I wanted to try was spruce up my actual UI.
And why not start by changing the background color of your app? Right? So, I went to edit the background property on the outermost view, the one the body is set to.
And that’s when I got an “Expected declaration” error.
View, here, is a protocol looking to be filled, not to be an editable view itself. It passes along the views and controls we put inside it to the
ContentView to be displayed.
State Lives Within Content
A huge feature of SwiftUI is how data is now synced with your UI.
In particular, I found the new
@State tag to be particularly simple and effective to use. (You can check out how I used it in my article Shoehorning SwiftUI and Create ML — Part 2).
What I learned about
@State variables, is that they need to live within the content that you plan to use them in, they are not global.
When you declare it outside of whichever content you plan on using it in, you get compiler errors. This is actually fine because
@State is meant to be defined for a contained UI, not for an entire app.
This also means that methods outside of your contents’ scope cannot set your state. You will need to have that method give a return that can then be recognized back inside the content, so a proper state can be determined and set.
If the method is exclusive to the content, you can place the method within the contents’ scope, and easily reference and set
@State from within.
Inspect: The Lazy Styler
When I was working with storyboards, I usually kept the right-side panel open to modify my UI views and controls.
For SwiftUI, this menu is still quite useful as it reflects the modifiers available for the view you’re currently focused on. Plus, as you make modifications, it automatically adds it to your code.
However, especially if you’re working with the preview window, Xcode can become quite cramped.
If this is the case, CMD+click offers ‘Inspect’, which pop-ups our modification menu right in our editor and works just like the side-panel. I prefer this method because I’m also focused on that specific view and my screen does not feel too busy or chaotic.
This is a great guide for when you’re struggling with where to place properties.
The thing about how SwiftUI properties work is that they can affect the hierarchy of views. If you ever get confused, using the inspector can at least help play with properties and see how they immediately affect your UI in the preview.
Learn to Make Custom Views by Extracting Them
Extracting sub-methods is almost a standard for refactoring. We do it to keep our code clean, sometimes to protect code, and sometimes even for reuse.
In SwiftUI, the benefits carry over and really serve to make your UI code readable and less clunky.
That’s why I would say that extracting views is a must-develop discipline in SwiftUI.
In the short term, getting into the habit will keep your view hierarchies from becoming unwieldy. But, in the long run, it also allows you to take those subviews and use them elsewhere as custom views, either by referencing them directly or using them as a starting point by copy-pasting them elsewhere.
To make my point, this was not always simple in storyboards/IB.
Let’s say you wanted to copy a cell over for a
TableView. It almost always felt like a gamble — it would be smooth or wreak havoc on your constraints and outlets.
Whereas, using an extracted cell in SwiftUI is as simple as referencing it directly, or copy-pasting, editing, and using it as an ordinary method.
Refactoring Is Better Now Than Later
The refactoring features (specifically in the CMD+click menu) are pretty nice… but may not be immediately obvious.
I hate to say it, but it’s a weakness in the editor. The reason for that is because you can’t actually refactor multiple lines of views, only the view you clicked on.
Let me explain why this can be frustrating but can also be avoided.
Let’s say you have a collection of views you want to extract to a subview for cleanliness and reuse.
The key here is that they need to be wrapped in a view (can be a view, stack,
NavigationButton, etc.) because you are making a
SubView. It feels like it’s one of the reasons why you can’t CMD+click a group of views.
But then, wouldn’t it be nice to use the embed in an
<Embeddable View> feature and then extract?
Well, again, you can only focus on the view you click on, so if you take that route, you’ll still need to move the other views into your new embed. It’s this kind of drawback that takes the sheen off what is otherwise a nice refactoring toolset.
These are just some of the things I found messing around with the Beta, I’m sure there are other nuggets and gems to be found.
I’m also certain that some of these could very well change by the time Xcode 11 goes golden.
The biggest advantage to having these tips in the back of your mind is that it can help you get into the new mindset that SwiftUI is calling developers to have.
Apple is essentially declaring that they have accepted that reactive UI development is the new standard.
If you come from the world of Angular, React, or Flutter, you’ve already been exposed to that mindset in a sense. But I do like Apple’s take on it and its refinement.
And for my final tip: Go get the Beta and try it yourself!