Swiftdata Pro

interface:
  display_name: "SwiftData Pro"
  short_description: "Reviews SwiftData code for modern best practices."
  icon_small: "./assets/swiftdata-pro-icon.svg"
  icon_large: "./assets/swiftdata-pro-icon.png"
  brand_color: "#5A7585"
  default_prompt: "Use $swiftdata-pro to review my project."

policy:
  allow_implicit_invocation: true

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="227.72" height="227.72" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" viewBox="0 0 227.72 227.72">
  <defs>
    <style>
      .st0 {
        fill: none;
        stroke: url(#linear-gradient1);
        stroke-miterlimit: 10;
        stroke-width: 6px;
      }

      .st1 {
        fill: url(#linear-gradient);
        fill-rule: evenodd;
      }
    </style>
    <linearGradient id="linear-gradient" x1="58.405" y1="-63.045" x2="178.785" y2="-183.425" gradientTransform="translate(0 -10) scale(1 -1)" gradientUnits="userSpaceOnUse">
      <stop offset="0" stop-color="#99abb6"/>
      <stop offset="1" stop-color="#567182"/>
    </linearGradient>
    <linearGradient id="linear-gradient1" x1="33.349" y1="-51.349" x2="194.371" y2="-212.371" gradientTransform="translate(0 -18) scale(1 -1)" gradientUnits="userSpaceOnUse">
      <stop offset="0" stop-color="#00eeaf"/>
      <stop offset="0" stop-color="#99abb6"/>
      <stop offset="1" stop-color="#567182"/>
    </linearGradient>
  </defs>
  <path class="st1" d="M165.43,131.08c3.87-8.17,16.03-46.62-38.6-85.38,7.61,7.03,40.19,39.2,26.05,75.5-34.2-25.27-87.91-66.75-87.91-66.75,0,0,63.69,60.57,83.58,79.15,19.9,18.59,26.97,27.71,26.47,43.59,0,.01,14.58-23.23-9.59-46.11ZM130.89,145.79c-39.35,18.56-78.42-20.82-78.42-20.82,0,0,21.12,26.7,45.19,35.06,33.72,11.71,54.61-9.64,54.61-9.64L52.42,59.03s56.43,62.62,78.47,86.76h0Z"/>
  <circle class="st0" cx="113.86" cy="113.86" r="110.86"/>
</svg>

# Class inheritance

When supporting iOS 26 and other coordinated releases (macOS 26, etc), SwiftData supports class inheritance for models.

**Important:** This is not a common feature; only add model subclassing if it actually has a benefit. Alternatives such as protocols are often simpler and better.

This works the same as regular class inheritance in Swift, however, child classes must be explicitly marked `@available` for a 26 release or later, e.g. iOS 26. This is required even if iOS 26 is set as the minimum deployment target.

For example:

```swift
@Model class Article {
    var type: String

    init(type: String) {
        self.type = type
    }
}

@available(iOS 26, *)
@Model class Tutorial: Article {
    var difficulty: Int

    init(difficulty: Int) {
        self.difficulty = difficulty
        super.init(type: "Tutorial")
    }
}

@available(iOS 26, *)
@Model class News: Article {
    var topic: String

    init(topic: String) {
        self.topic = topic
        super.init(type: "News")
    }
}
```

Notice how both the parent and child classes must use the `@Model` macro.

**Important:** When using a 26 release or later as minimum deployment target, we must still mark subclassed models with `@available`. However, we do *not* need to do the same with code using that model, because Xcode can match the deployment target and the model availability.

When providing the schemas as part of model container creation, make sure to list both the parent class and its child classes – SwiftData is *not* able to infer the connection by itself.

If you create a relationship to a model that has subclasses, the relationship might contain the parent class or any of its subclasses.

For example, the `articles` array here might contain `Article`, `Tutorial`, or `News` instances:

```swift
@Model class Magazine {
    @Relationship(deleteRule: .cascade) var articles: [Article]

    init(articles: [Article]) {
        self.articles = articles
    }
}
```

If only one subclass is supported, it should be written specifically. If several subclasses but not all should be in the relationship,