I think I know the answer to this, unfortunately, but…
I got this crash via TestFlight feedback. Despite being able to identify the line that crashed, there's no way to recover the actual error right?
SwiftData migration crashes are such a bummer. This is probably an expected problem caused by an intermediate schema, but it might be signifiant. #SwiftData #Swift
SwiftData will infer relationships automatically - but only when it's safe to do so (specifically when the relationship is optional). Pro tip: specify the @𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑠ℎ𝑖𝑝 inverse on only one side to avoid circular reference errors.
🔗: https://www.hackingwithswift.com/quick-start/swiftdata/inferred-vs-explicit-relationships by Paul Hudson (@twostraws)
"I survived my first SwiftData migration, and all I got was this lousy–"
Lost connection with debugger. #SwiftData
Transformables in SwiftData Are Simpler Than You Think
https://azamsharp.teachable.com/courses/azamsharp-pro-for-all-content/lectures/65304892
I've got the schema upgrade basically working, but I think I'd better move all the blobs out of it and into the file system.
Still, this is a good stable point to pause. I don't need to post a build of this. #SwiftData
I've also been working on a Python script to pin/reset data. I'll post it in a few days, but here's a few things I've learned so far:
To show the top level of your repo:
git rev-parse --show-toplevel
To get the bundle ID of your project from there:
xcodebuild -showBuildSettings
(Search for PRODUCT_BUNDLE_IDENTIFIER =)
To get the simulator's container:
xcrun simctl get_app_container booted BUNDLE_ID data
From that directory, look in Library/Application Support. #SwiftData #Xcode
Thinking about how to update my SwiftData models so I don't need to change code everywhere. (This is in addition to my typealiases earlier.)
The rest of my code can just use notes. notesV1 can't be private because the migration needs to know about it, but it's new.
This seems safe, and if so very little code updating will be required.
Note: I am NOT changing the schema just to make these fields non-optional, but since I'm changing the schema anyway it seems a reasonable step. #SwiftData
So this should work, right?
enum SchemaV1 { /* includes Table */}
typealias CurrentSchema = SchemaV1
typealias Table = CurrentSchema.Table
…I had weird compiler errors with it last night, but I musta screwed it up because it's working great (so far) today.
The point is being able to update CurrentSchema to SchemaV2, etc. in the future and save fixing Table = SchemaV1.Table for all tables. #Swift #SwiftData
apparently it's a known issue and under investigation. For now, I'm going to namespace the model and move on.
Renaming a SwiftData property? Without @𝐴𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒(𝑜𝑟𝑖𝑔𝑖𝑛𝑎𝑙𝑁𝑎𝑚𝑒:), lightweight migration treats old and new names as separate schema elements — silently losing your data. A critical tip for anyone relying on auto-migration.
🔗: https://www.hackingwithswift.com/quick-start/swiftdata/how-to-rename-properties-without-losing-data by Paul Hudson (@twostraws)
🇨🇦 Steve
Snapp iOS Weekly
Mohammad Azam
Andrew Edwards