Recent searches
Search options
Administered by:
#coredata
It is 2025, and there are still people writing #SQL to combine with their #Swift code.
In 1993 NeXT introduced Enterprise Object Framework (EOF) and in 1995 - WebObjects. Since that time my team and I never wrote a single SQL query (exception - testing).
We are complaining about AI, but still write SQL! Folks, this is regression!
—
#CoreData is based on EOF. Very poor and miserable imitation of EOF indeed (also sign of the downfall of the empire).
Many thanks to @seanallen_dev & @bigmountainstudio for helping me update my TestFlight app using CoreData. 
I want to support iOS15 for some family iPhones I can’t inspire away. & I think for undo/redo support made #coredata worth it.
I find both your material really inspiring… But sometimes Sean’s video format is harder to use for quick reference. And while Mark's visual book format is great - I would have preferred small working apps to the big several example one.
I do like using Cursor for helping me make debugging scripts a lot. This one parses all the #CoreData sqlite query logs and makes a spreadsheet out of them with their execution time + the fault/action that triggered the query. https://gist.github.com/juanarzola/d1af93e8d677766c9cd57253b24352d8
Does someone know what benefits/effects changing the "Tools Version" of your CoreData-Model has?
If that fails, I’ll switch to #CoreData, as there are much more materials on how to deal with it, not to mention it’s a mature framework. Now it’s time to at last rest before the new week! 
#BuildInPublic #IndieDev #iOSDev
All that made me think, maybe #CoreData would be a better choice, but at this point I’m a bit afraid to change everything. On the other hand, it’d be better to do it now than after the official release, I guess.
#Swift #iOSApp #AppDevelopment
I haven't seen anything at WWDC regarding sharing #SwiftData with other users. Did I miss something?
When I looked into it last year I walked away with the impression that it's only possible with #CoreData. But now I'm thinking, since SwiftData is just a wrapper around Core Data, sharing has to be possible somehow.
Not finding anything on the topic. It doesn't help that I've never done it using Core Data. Looks like I should just try it so I understand the problem space.
The holidays have given me a little time to work on my oldest app Bakeshop. It's been in dire condition for a long time, but having a full time engineering job doesn't give me much time.
Version 6 of the app has undergone a significant code transformation in order to make it easier and quicker to release improvements, using all the latest technologies: #SwiftLang #SwiftUI #CoreData #CloudKit
It's in beta on TestFlight now. https://testflight.apple.com/join/I5GiHzLt
#swiftdata took a giant step backwards in #iOS18. And not a single beta / release note since #WWDC has addressed any issues. From threading issues, to #SwiftUI integration, to concurrency property wrapper issues, to all new runtime crashes, it is really, really bad. I don't usually criticize things, but it is just so frustrating, maybe this warning will help others.
For a hobby app I've reverted to #CoreData , which is great - I'm just tired of debugging… (~6 yo Photos.app CD model pictured)
I was thinking about running #CoreData + #SwiftData side by side while implementing a new feature that requires some new data types, but the reports of iOS 16 usage is making me rethink that decision.
I've now built a system that saves the states of whether a migration is needed and later completed. This is the signal for the widget regarding whether it is allowed to access the shared Core Data stack. I'm not sure if this is solving the problem or if there is a more straightforward solution (there should be, I hope), but this bug is hard to reliably reproduce, so this is the best guess I'm going with for now. 
Does somebody know how to handle Core Data crashes in the instance where I share a Core Data stack between my App and a Widget?
After I make a change to the Core Data model and it’s automatically migrated, it seems to crash sometimes (I can't reproduce it reliably). My best guess right now is that these two processes try to load and perform the migration at the same time and therefore crash.
Anyone can help? #coredata #swift
PS: Looks very similar to these issues: https://developer.apple.com/forums/thread/668649
If someone is interested how the same, old but sizeable, database looks in #SwiftLang using either #SwiftData, #CoreData or Lighter, I have setup the Northwind.swift project. It's a pre-filled database as a Swift package, useful for toying around with the respective frameworks (I would also welcome contributions of additional variants, say like GRDB!)
https://github.com/Northwind-swift
... also on that same note - why does #SwiftData mark code as ‘throw’ if it actually uses FatalError (which can't be caught) if anything goes wrong? #CoreData at least lets me catch the error and give a clean report to the user :|
You really don't appreciate the simple things until regressions in #SwiftData take them away.
This little GIF looks like nothing but it's a SwiftUI view pulling in live-updates made by a second Actor running in a background thread and all without any hacks or forced refreshes.
Clicking "+" inserts into the same database but using another Actor called from the main thread and both. just. work.
Running on #CoreData using the ManagedModels and CoreDataEvolution SwiftPM packages.
@helge thank you for pointing me at this - looks like a very promising alternative to using momd files 
My current setup now consists of:
- ManagedModels -- declarative CoreData @ Models in code
- CoreDataEvolution -- @ ModelActor support for CoreData
- PredicateKit -- Swift # Predicate for CoreData queries
What could possibly go wrong with so much plumbing :D
@helge @groue @fatbobman both async functions are isolated to the same actor (queue?) but it doesn’t mean they will be running on the same thread right? Passing non-Sendable type is ok but I thought the issue with #CoreData NSManagedObject and #SwiftData Model was that they can’t be passed between threads. Which seems to be the case with two async functions in a ModelActor.
What do you think @mattiem?
Thanks!