I'm having this exact issue and am stumped. Hoping someone else chimes in.

After waiting even longer: Message from debugger: Terminated due to memory issue

Receiving this message after waiting a while: warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not find the on-disk shared cache for this device. This will likely reduce debugging performance.

Leaving this for anyone else that might be searching: After tinkering with Core Data for a while and trying to get it set up, I ended up scrapping Core Data and using the FileManager system. I'm sure there's drawbacks to going this route versus going the Core Data route, but I'm only trying to store two relatively small arrays (less than 50 items for sure, probably less than 10 items in most cases) and a lot of the sorting is done in the app itself. So, it seemed like the easiest solution for now, as I was able to implement it in a few hours using my existing structs. I used this as my guide, and tweaked slightly for my use case: https://developer.apple.com/tutorials/app-dev-training/persisting-data While this looked intimidating at first, I found it to be infinitely easier than figuring out Core Data. Just my experience, but wanted to share my experience for anybody who finds this in the future.

"You'll have to recreate your Task struct as an NSManagedObject, and it won't behave quite the same, so you'll have a bit of work to do." I think this was the reassurance I was looking for. This is what I believed to be true after playing around with the Core Data Model a little bit last night and this morning, but before I delved into changing it all around to use the NSManagedObject created through the Core Data Model codegen instead of my already created "Task" struct, wanted to make sure I was going down the right path or if there was an easier way. I'm sure I'll run into some issues when you say it won't behave quite the same, but that's a problem for another day! Thank you both for your replies!!

If you haven't gone through this tutorial yourself and can't answer this question, that's perfectly fine, but I have one main question as I tried to work through that tutorial (note: I don't know the website and thus didn't feel comfortable downloading the sample project in Xcode): Is the ultimate solution to replace their TodoItem struct (pre-created) with the Todo class generated by the Core Data Model (codegen when creating the entity/attributes)?

init(data: Data) {         id = UUID()         title = data.title         attendees = data.attendees         lengthInMinutes = Int(data.lengthInMinutes)         theme = data.theme     } Add this to your DailyScrum model within the "extension DailyScrum". Basically you're trying to use an initializer that doesn't exist within DailyScrum, and I only picked up on this by looking at the next section's completed project. As soon as I added this, everything worked fine.

I should've waited to post and looked a little more. I downloaded the completed project for the next section - Persisting Data - and it had the initializer for DailyScrum using Data only. This is what I suspected I needed to do, but since it hadn't been mentioned up to that point in the tutorial, I was second guessing myself. Maybe something for Apple to look at adding in the next update of the tutorial, as it was super confusing.

Had the same issue and DDP's solution worked for me. Leaving this comment to bump this thread and this solution. Hopefully, Apple will see this and update the Scrumdinger guide to include this little bit, because, for anyone that's just learning, this would be extremely hard to figure out on their own.