SwiftData is a framework for data modelling and management.
It's built on top of CoreData's  persistence layer, but with an API completely redesigned and reimagined for Swift.
SwiftData provides also support for undo and redo automatically. 
And if your app have shared container enabled, SwiftData automatically makes data directly accessible by widgets using the same APIs.
Now, let's see how it works.
## Models
First we need to create the models that we want to persist.
To create a model you need to mark the `class` with the Macro `@Model`.
SwiftData includes all non-computed properties of a class as long as they use compatible types. So far, SwiftData supports types such as `Bool`, `Int` and `String`, as well as `structures`, `enumerations`, and other value types that conform to the `Codable` protocol.
So, let's create the `Folder` and  `Note` models.

```swift
@Model
final class Folder {
 
  @Attribute(.unique)
  var id: String = UUID().uuidString
  var name: String
  var creationDate: Date
  var notes: [Note] = []
 
  init(name: String) {
	self.name = name
	self.creationDate = .now
  }
}
 
@Model
final class Note: Decodable {
 
  @Attribute(.unique)
  var id: String = UUID().uuidString
  var text: String
 
  init(text: String) {
	self.text = name
  }
```
1. Create a model class that contains all the properties you wish to persist
2. Mark the classes with the Macro `@Model`
3. Optionally, add Macros (`@Attribute`, `@Relationship`, `@Transient`) to the property that need them

Creating models is as simple as that.

!WARNING As for now, if you declare an array of objects is likely you will get an error like `Ambiguous use of 'getValue(for:)'`. This is a bug in Xcode 15.0 beta that I think will be fixed on final version of Xcode. For now, just remove the `@Model` from the `Note` class and add `@Transient()` to `notes` property.
## Model attributes
Properties in the `@Model` can have [Macros](/articles/swift-macros) attached to them that will defined their behaviour.
Currently there are 3 types of macros: [`@Attribute`](https://developer.apple.com/documentation/swiftdata/attribute%28_:renamingidentifier:hashmodifier:%29), [`@Relationship`](https://developer.apple.com/documentation/swiftdata/relationship%28_:_:renamingidentifier:inverse:hashmodifier:%29), [`@Transient`](https://developer.apple.com/documentation/swiftdata/transient).
### @Attribute
This Macro alters how SwiftData handles the persistence of a particular model property.
This is commonly used to mark a property as primary key, as we did for `Folder.id`.
```swift
@Attribute(.unique) 
var id: String
```
But there are many other options:
* `encrypt`:  Stores the property’s value in an encrypted form.
* `externalStorage`: Stores the property’s value as binary data adjacent to the model storage.
* `preserveValueOnDeletion`: Preserves the property’s value in the persistent history when the context deletes the model.
* `spotlight`: Indexes the property’s value so it can appear in Spotlight search results.
* `transformable`: Transforms the property’s value between an in-memory form and a persisted form.
* `transient`: Enables to the context to disregard the property when saving the model.
* `unique`: Ensures the property’s value is unique across all models of the same type.
### @Relationship
By default if you declare a property whose type is also a model, SwiftData manages the relationship between these models automatically.
But if you want to customise its behaviour, you can use the `@Relationship` Macro.
```swift
@Relationship(.cascade) 
var notes: [Note] = []
```
This way if the `Folder` is deleted, all of its notes are deleted too.
This Macro defines the behaviour that in CoreData was named **Delete Rule**.
!NOTE Both `@Attribute` and `@Relationship` support the renaming of the  argument in case you want to preserve the original name of the property.
### @Transient
By default SwiftData persist all non-computed properties inside the model, but if you don't need to persist a specific property, you can add the `@Transient` Macro to that property.
```swift
@Transient 
var someTempProperty: String
```
## The model container
Before using these models, we need to tell SwiftData which models to persist.
To do this there is the `.modelContainer` modifier. To use it you simply pass all the models you want to persist.
```swift
@main
struct NoteBookApp: App {
 
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .modelContainer(for: [Folder.self]) // <-
    }
}
```
Here we pass only the `Folder` class because SwiftData knows that it has to persist also `Note` since there is a relationship between the two classes.
The `.modelContainer` modifer allows you to specify some options.
* `inMemory`: Whether the container should store data only in memory.
* `isAutosaveEnabled`: If enabled you don't need to save changes.
* `isUndoEnabled`: Allows you to undo or redo changes to the context.
* `onSetup`: A callback that will be invoked when the creation of the container has succeeded or failed.
!NOTE If you model contains a relationship to another model, you can omit the destination model.
## Saving models
Now, we are ready to use SwiftData.
Let's see how to save models.
First we need to get the context, to do this we use the `@Environment(\.modelContext)` wrapper.
```swift
@Environment(\.modelContext) private var context
```
Next, once we have the context, we create the object we want to save and we insert it into the context.
```swift
let folder = Folder(name: "Trips")
context.insert(folder)
```
If we have enabled the autosaving while creating the container we don't have to do anything else.
Otherwise we need to save the context.
```swift
do {
   if context.hasChanges {
      context.save()
   }
} catch {
   print(error)
}
```
## Fetching models
To fetch existing models, SwiftData provides the `@Query` wrapper.
This wrapper allows you to sort, filter and order the result of the query.
```swift
@Query(filter: #Predicate { $0.name != "" },
       sort: \.name,
       order: .forward) 
var folders: [Folder]
```
Here we query by:
* Filter folders that have non-empty name
* Sort them by the `name` property
* Order them ascending
 
Or, we can use a `FetchDescriptor`.
```swift
extension FetchDescriptor {

  static var byName: FetchDescriptor<Folder> {
    var descriptor = FetchDescriptor<Folder>(
	    predicate: #Predicate { $0.id != "" },
		sortBy: [SortDescriptor(\.name)]
	)
    descriptor.fetchLimit = 50
    descriptor.includePendingChanges = true
    return descriptor
  }
}
 
@Query(.byName) 
var items: [Folder]
```
This way we can reuse the `FetchDescriptor` for as many queries as we need.
## Updating models
To update a model we just need to change the value of the property we want and if autosave is enabled that's all.
```swift
folder.name = "New name"
```
Otherwise we need to save the context.
## Deleting models
To delete a model is just as simple as to create one.
We get the instance of the object to delete and we pass it to the context.
```swift
context.delete(model)
```
## Conclusion
SwiftData really simplifies the usage of CoreData, making it less prone to errors.
Of course this is still in Beta so there will be changes and improvements, but so far I really enjoyed playing with it.
Hope this will help developers speed up their workflow to persist data and reduce crashes.

Discover the SwiftData framework built on top of CoreData. Save and fetch data locally. Available for Xcode 15, Swift and SwiftUI.

SwiftData the Successor of CoreData Explained with SwiftUI

So, your application retrieves data from a REST API and you need to decode it into custom objects and save them to CoreData, but you aren't sure how to do it.
I was recently in this position while building a bookmarks and rss feed manager.
While researching how to handle this, I came across multiple options, like creating a model that maps the JSON response and a separate one that is the actual CoreData entity to save and use throughout the app. But this seemed too much work to me, but it can suits other scenarios.
Then I saw this method that is exactly was I was looking for, quick and easy, with no model duplicates.
## Steps
1. Run a `request` to the endpoint you want to fetch the data from
2. Decode the `Data` you received and save the `context`
Done!
 
As you can see these are not a lot of steps. In this article I will explain only the second one.
So, with no further ado let's begin.
## Setup
First, we are going to create a couple of helpers that will make our life easier.
The first one is a custom error that we will throw in case the `context` is not present.
```swift
enum DecoderConfigurationError: Error {
  case missingManagedObjectContext
}
```
The second one is a `CodingUserInfoKey` that we will use to assign and retrieve the `context`.
```swift
extension CodingUserInfoKey {
  static let managedObjectContext = CodingUserInfoKey(rawValue: "managedObjectContext")!
}
```
## Decoding
Once we have those out of the way, we can start decoding our data.
We will use the default `JSONDecoder` and we will use the `userInfo` property to assign our `NSManagedObjectContext` to the `CodingUserInfoKey.managedObjectContext` key.
This way we are passing the `context` that we will use to create the `NSManagedObject` to the `init(from:) `.
```swift
do {
  let decoder = JSONDecoder()
  decoder.userInfo[.managedObjectContext] = PersistenceController.shared.context
 
  let decodedObject = try decoder.decode(Object.self, from: data)
} catch {
  // [Handle error...]
}
```
!NOTE The `PersistenceController` class is the implementation of the CoreData stack. You can find an example [here](/articles/persistence-controller).
## Conforming to Decodable
Now we can make our `NSManagedObject` conform to `decodable`.
```swift
class Object: NSManagedObject, Decodable {
  // [...]
}
```
Once we have done that we implement the `init(from:)` initialiser.
```swift
class Object: NSManagedObject, Decodable {
 
  private enum CodingKeys: String, CodingKey {
      case objectProperty
      // [...]
  }
 
  required convenience init(from decoder: Decoder) throws {
 
    // 1. Retrieve the context
    guard let context = decoder.userInfo[CodingUserInfoKey.managedObjectContext] as? NSManagedObjectContext else {
 
      // 2. Throw an error in case the context is not present
      throw DecoderConfigurationError.missingManagedObjectContext
    }
 
    // 3. Instantiate the CoreData entity
    self.init(context: context)
 
    // 4. Decode the object properties
    let container = try decoder.container(keyedBy: CodingKeys.self)
    self.objectProperty = try container.decode(String.self, forKey: . objectProperty)
    // [Continue decoding properties...]
  }
}
```
In the code above we set up the decoding method:
1. We retrieve the `NSManagedObjectContext` that we passed earlier using the `userInfo` property.
2. We throw an error in case the context is not present
3. We instantiate the CoreData entity using the `context` we retrieved
4. And we decode each property from the data we received from the API
## Save the context
Finally we save the `context` to persist our decoded objects.
```swift
context.save()
```
## Conclusion
In this way we can decode and persist our data in one single step. With no need to create a separate model that handles the decoding process.
I found this method really effective in my experience, I hope it will be useful to you as well.
If you have any doubt or question leave a comment and I'll be glad to reply.

See how to convert fetched data from a REST API to entities and persist them to CoreData, the built-in local database of Apple.

From REST API to CoreData in One Step

Recently I had to build an app using **SwiftUI** and **CoreData**.
I thought CoreData was used almost as you would use it with UIKit, but apparently there are some differences.
This guide is intended as a summary of my experience using CoreData combined with SwiftUI. If I will find other aspects, I will add them to this guide.
So, without further ado, let's begin.
## Set-up
This is a pretty straightforward part.
* If you start a new project you can check the '**Use Core Data**' option and '**Host in CloudKit**' if you want to save your users data to the cloud. In this case XCode will take care of setting up the project for you. (For the CloudKit part will need to do some extra steps).
* If you have already a project you'll need to create a **Persistence.swift** file and a swift file where you initialise the CoreData stack. (You can even create a new project following the previous step, and copy the **Persistence.swift** file generated by XCode to your project.
![CoreData setup](/coredata/setup.png)
## Setup the @main app
Now that you have your project, to be able to use CoreData within your `View`s, you need to pass the `managedObjectContext` down you view hierarchy.
Usually this is done in your **(AppName)App.swift** file.
```swift
@main
struct ExampleApp: App {
 
  let persistenceController = PersistenceController.shared
 
  var body: some Scene {
    WindowGroup {
      ContentView()
        .environmentObject(persistenceController)
        .environment(\\.managedObjectContext, persistenceController.container.viewContext)
    }
  }
}
```
Personally I pass, as an `.environmentObject`, the **PersistenceController** itself. Because I like to keep all the CRUD logic inside that struct, but that's up to you. If you want to do so you need to make your **PersistenceController** struct conform to
**ObservableObject**.
Great, now you're able to create, read, update and delete `NSManagedObjects` in your `View`s.
!TIP **PersistenceController** ([here is an exemple](/articles/persistence-controller)) is the struct that XCode generates  automatically for you when you start a new project with the '**Use Core Data**' option checked.
## Operating with CoreData
To operate with CoreData in your `View` you need to access the `NSManagedObjectContext`. To do so, you have two options:
* Using the **@Environment** wrapper in your `View`s
```swift
@Environment(\\.managedObjectContext) private var viewContext
```
* Using the **@EnvironmentObject** wrapper to get your controller, and from it you can access the `viewContext` or CRUD methods
```swift
@EnvironmentObject private var persistenceController: PersistenceController
```
## Saving the context
You can save the context using the `.save()` method of `NSManagedObjectContext`. Before saving the context you can check whether  there are some changes, and save it only if they are present.
```swift
do {
  if container.viewContext.hasChanges {
    try container.viewContext.save()
  }
} catch {
  print(error)
}
```
## Saving objects
To save a `NSManagedObject` you first need to instanciate it and than configure its properties. And then save the context.
```swift
let note = Note(context: container.viewContext)
note.id = id
note.text = text
note.folder = folder
note.creationDate = Date()
saveContext()
```
!TIP You can animate this insertion wrapping this code inside the `withAnimation` function of SwiftUI.
## Fetching objects
Now the fetching part, this is where I found the most difficulties. Let's start right away.
To fetch objects in SwiftUI the most convenient way of doing it is using the **@FetchRequest** or **@SectionedFetchRequest**  wrappers, in every single `View` you need to read from CoreData.
!WARNING Passing fetched objects between `View`s will break the automatic updates in case you add, edit or delete objects. (If you know a way to pass fetch objects without breaking the updates let me know and I will update this guide)
So you need to add a **@FetchRequest** in every `View` you need CoreData objects and automatic updates. I know it is a bit annoying but it will be worth it.
So, with that said the code is the following:
```swift
@FetchRequest(entity: Object.entity(),
              sortDescriptors: [NSSortDescriptor],
              predicate: NSPredicate,
              animation: .default)
var objects: FetchedResults<Object>
```
Or, if you want your objects grouped by a property:
```swift
@SectionedFetchRequest(entity: Object.entity(),
                       sectionIdentifier: \\Object.property,
                       sortDescriptors: [NSSortDescriptor],
                       predicate: NSPredicate,
                       animation: .default)
var sections: SectionedFetchResults<YourSectionType, Object>
```
To use these sections you just pass them to a `List` or `ForEach`, and then to another `ForEach`.
```swift
List(sections) { section in
  Section(section.id) {
    ForEach(section) { object in
      // Configure your view with the object
    }
  }
}
```
!TIP If you use **@SectionedFetchRequest** with sorting you may need to specify two sort descriptor. The first will sort the sections and the second one will take care of the objects inside each section. This feature is really useful and requires very little effort.
Using **@FetchRequest** or **@SectionedFetchRequest** wherever you add, update or delete an object, the views are automatically updated.
Now, if you need to use a **@FetchRequest** with a `NSPredicate` that has a parameter passed from the parent `View`, I found that the next option works wonderfully.
```swift
@FetchRequest
var objects: FetchedResults<Object>
 
init(id: ID) {
  _objects = FetchRequest<Object>(predicate: NSPredicate(format: "id == %@", id))
}
```
This way you can pass your parameter in the `init` and use it to filter your results while keeping the automatic updates. The same goes for **@SectionedFetchRequest**.
## Updating objects
To update a `NSManagedObject` you will need to have the `NSManagedObject` to update, fetched as described before and update its properties. And then save the context.
```swift
note.text = newText
note.folder = newFolder
saveContext()
```
## Deleting objects
To delete a `NSManagedObject` you will need to have the `NSManagedObject` to update, fetched as described before and delete it.
```swift
viewContext.delete(object)
```
------
I didn't explained every single CRUD method of CoreData like batch insertion and deletion since this guide is focused on the interaction between CoreData and SwiftUI. Every `NSManagedObjectContext` method, background context, performAndAwait, … behaves exactly like it does with UIKit.
------
## Conclusion
That's all I have discovered so far about **CoreData** used with **SwiftUI**. This guide will be constantly updated.
If you want to suggest a better way of doing something, **leave a comment** and I will update this guide with the best option.
I hope I helped you with you journey with SwiftUI and iOS development.

See how to use CoreData database with SwiftUI. Syncing changes from CoreData to every View of your app.

CoreData

SwiftData the Successor of CoreData Explained with SwiftUI

From REST API to CoreData in One Step

Combine CoreData and SwiftUI