In this article, I will show you what naming conventions I am using for Core Data entities and attributes and how SwiftData changed my approach. I am not saying that this convention is the best one and the one you should use. But I want to tell you why you may consider adopting it in your apps.

Renaming variables and constants in your code is mostly not problematic at all. But when it comes to creating your data model, it is good to plan ahead. While of course, you can rename your entities, classes and attributes later and migrate your data model, it's just easier if you use good names from the start.

Core Data entities and attributes

Let's start with an example of an app that helps you manage your trips when you travel. In most tutorials for Core Data and SwiftData, you will see the following convention:

• Trip - for a Core Data entity or SwiftData class

• attribute - an attribute of the Trip entity

• trips - a collection of objects of type Trip

• trip - a single object from the "trips" collection

That's quite simple for a single word. Titlecase singular form for entity/class, lowercase plural name for an attribute and collection and lowercase singular form for a single object.

Now let's say that in your app you have another entity/class for booked hotels. For names made of few words you would use this:

• BookedHotel - entity/class

• otherAttribute - an attribute of the BookedHotel entity

• bookedHotels - a collection of objects

• bookedHotel - one object

Same as before, but with a camel case for multiple words.

Knowing the conventions, I started to use them in my apps. And it mostly worked. Mostly 😅 But I ran into a problem very quickly with my first ever data model in my app Numi, a finance app for tracking expenses.

For one of the entities I created in Numi, I used the name Transaction. My code wasn't working as expected and I spent many hours on debugging. At the time, I learned that there were already some Structs with the same name. Two examples are:

• in Swiftui - https://developer.apple.com/documentation/swiftui/transaction

• in StoreKit - https://developer.apple.com/documentation/storekit/transaction

When I was creating a transaction object, Xcode was sometimes mistakenly assigning it to the wrong Transaction type. Most likely it was clashing with the SwiftUI's Transaction struct.

let transaction = Transaction(context: viewContext)
// Or...
init(transaction: Transaction) {

As Xcode didn't tell me what was happening, it took me some time to find what was the cause of the problem.

I tried a few solutions to fix this issue. And honestly, I forgot about some of them as they didn't work. What fixed my problem was very trivial. I simply added a prefix to my Core Data entities.

CDE prefix

Since the problem with Transaction, I started using the CDE prefix for all my Core Data entities. For example, I renamed the Transaction entity to CDETransaction and boom! Suddenly my code works without any issues.

You can use another prefix, of course. One example would be MyAppTransaction with a MyApp prefix. But it is not as clear as with the CDE prefix that MyAppTransaction is a Core Data Entity. And also, what if at some point you will need to change the name of your app?

You can see that Apple recommends a similar naming convention to my CDE prefix in this article:
https://developer.apple.com/documentation/coredata/adopting_swiftdata_for_a_core_data_app

For example, when they give us an example of Core Data and SwiftData co-existing in the same app, they are using the class Trip for SwiftData:

@Model final class Trip {

But for the Core Data entity, they are using CDTrip (with CD prefix), like this:

class CDTrip: NSManagedObject {

And later, for adding a new Trip:

let newTrip = CDTrip(context: viewContext)

How SwiftData changed my approach

During WWDC2023, Apple introduced SwiftData as a replacement for Core Data. After watching Apple's WWDC videos and reading some SwiftData tutorials, it looks like SwiftData is in most cases simpler to use than Core Data. But there are 2 problems:

1. SwiftData is not mature enough in 2023. Which means there is still some functionality missing. And also there are fewer tutorials and documentation than for Core Data.

2. SwiftData works only with iOS 17 and up. With most people still currently using iOS 16, choosing SwiftData over Core Data would significantly limit my potential user base.

What's great is that migrating from Core Data to SwiftData looks fairly simple, so I can use Core Data for now and migrate to SwiftData in the future when I decide to drop support for iOS 16.

But what about my naming convention with the CDE prefix? It looks like CDE wasn't the best idea, because after the SwiftData migration, the CDE prefix will not be very on point with SwiftData.

I want to avoid potential problems like I had with my Transaction entity, so I would prefer to use a prefix. Just not the CDE.

I decided to name Core Data entities in my new apps using the DM prefix instead. DM as in the Data Model, to make it less likely to introduce problems of having no prefix at all. And also to more clearly differentiate my Core Data entities from other Structs and Classes.

During future migration to SwiftData, I won't need to change the names of my entities and the DM prefix will be a better fit for SwiftData than the CDE prefix.

New naming convention

So to summarize, that's how I am planning to name my Core Data entities, SwiftData classes and attributes:

• DMTrip - entity/class in my Data Model

• attribute - an attribute of DMTrip in my Data Model

• trips - a collection of DMTrip objects

• trip - a single DMTrip object

And for multiple words:

• DMBookedHotel - entity/class in my Data Model

• otherAttribute - an attribute of DMBookedHotel in my Data Model

• bookedHotels - a collection of DMBookedHotel objects

• bookedHotel - a single DMBookedHotel object

I'm not claiming that this is the best naming convention, but based on my experience, it's something that works for me. It helps me avoid potential problems and clearly marks my classes as part of my Data Model.

Thank you for reading!

If you want to support my work, please like, comment, share the article and most importantly...

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532