Units, my first ever app, is underway. While I’m making decent progress, the initial steps haven’t been without drama, and predictably the first hurdle has been the data model.

My choice for this project is SwiftData. While I can hear the collective sighs of experienced developers bemoaning this choice over CoreData, I decided to keep it simple, work with the latest framework and follow along as it evolves. Don’t @ me.

Regardless of choice, there’s something about data that plagues my mind. As a designer, I’m a visual person who struggles to come to terms with concepts resolving in a black box. SwiftData, or any other data model for that matter, feel like the darkest of boxes where properties can be created, edited, and deleted without really knowing for sure whether it’s still lurking like a pesky bold space between two regularly formatted words in a text document. For all I know I might be creating properties all over the place that exist on users’ devices never to be used. Does it matter? Maybe not, but that shit keeps me up at night.

Let me give you an example with the following model:

Simple right? Well let’s say I’m populating a list of drinks with varying names and quantities. What happens if I want to change the property name from abv to percentage? Can I change the name directly without consequence? What happens to the 4.5% that was previously assigned to abv? Is it destroyed, or does it migrate to populate the new percentage property? I’ve searched for the answer but nothing has resolved my anxiety. 

This came back to bite me within the first few hours of development for Units after creating this Drink model:

As soon as code hit the canvas regret overwhelmed me. A computed property for units filled me with the same anxiety as the hidden bold space. It’s not the line itself, it’s this; I have no idea whether the right thing to do is use a computed property in a SwiftData model. This is likely lack of experience or poor research, or both. Either way, I want the model to work with clean data and computing a property while a model is saving felt wrong and prone to errors. Calculating the property using an @State property in the view felt much cleaner and made me want to change it immediately, swiftly leading to the next anxious moment, removing it from the data model.

After reviewing SwiftData By Example, I found this line:

“SwiftData will execute lightweight migration automatically for a range of small changes, including: ... Renaming one or more properties”

Nice. Just what I was looking for. Confirmation that deleting a simple property is handled by SwiftData. Confidently, I selected the line and hit delete only to see this error vomited multiple times on every build:

 error: the replacement path doesnt exist: "/var/folders/mk..."

What on earth happened? Not a single piece of UI had been created and I’m already getting hit in the face by when running Units on the simulator or on device. I know troubleshooting is part of development, but so early...give me a break.

I tried replacing the property with a non-computed version of the same name. That didn’t work.

I tried re-adding the exact same computed property. That didn’t work.

I tried rebuilding the project. That didn’t work.

I tried deleting the entire model. That didn’t work.

I tried deleting the project and starting a completely new one. That didn’t work.

I tried deleting Xcode and the project, reinstalling and starting from scratch. That didn’t work.

Errors will always happen but for some reason this one couldn’t be fixed. Every effort to start afresh was denied and all I could find was a Stack Overflow post declaring these errors as Xcode noise that could be ignored. I struggle when the resolution to a problem is “just ignore it.” As mentioned, I’m a visual person and the optics of these errors weigh heavily on my anxiety. If I’d have realised that Swift development was a psychological test, maybe I’d have thought twice.

Here we are weeks later constant reminder of poor decision-making has me casting doubt about the parts of my app hidden from view. Do these errors matter? Are there properties hiding in plain sight ready to pounce at some point in the future to trip me up further? Who knows? For now I’m going to ignore the errors and press on. 

Now the important part; the learnings.

Adjust my mental model

Errors in design can be apparent and obvious where the fixes are also apparent and (mostly) obvious. Development errors can be much more obscure with complex relationships that are hard to diagnose, and that’s part of the process.

Migrate migrate migrate

I have a bias for action and a trepidation when dealing with data. Data feels like a complex beast requiring expertise beyond my current level of competency, and while migrating SwiftData feels like concept I want to steer clear of, it’s a key part of development that’s a growth opportunity to embrace. 

Take time and keep it simple

This whole issue could have been avoided if I’d taken a bit more time to consider the data model beyond the model itself, and thought about how it interacts with the view. 

Embrace the chaos

Development can be messy, uncomfortable and disconcerting. I’m still making progress despite the errors and will continue to monitor them as I go. Perhaps an Xcode update will fix the errors as suggested on Stack Overflow, or a future data migration might do the trick. Either way, I want to resolve them before I ship the app, but I won’t let them paralyse my progress.

For any designer embarking on a similar journey, I hope you can take something from my experience. There are clear differences between design and development. Embrace discomfort, errors are natural, and don’t forget everyone was a beginner at something once. Oh, and migrate your SwiftData models.