You're spending a lot of time and effort on hiding the fact that you're using Core Data and I get that... to a certain point. But you're also incurring a lot of run-time inefficiencies in the process.

This example uses a ToDoLIst and I also understand that there (probably) won't be thousands of the things. But if I apply the same technique to something that could have thousands (or tens of thousands) then the map on your fetch request forces ALL of them to be faulted into menory and mapped to your struct.

This also looks good with a simple data structure but the instant you introduce object relationships you're going to have to think long and hard about how much time and effort you're going to spend abstracting those. Are you going to put all of them behind an async function "just in case" your data shifts to a web-based API and fetching those can now take a measurable amount of time?

You're also mapping core data items to structs that have immutable value semantics and sending them out into the wild. How do I mark a ToDo as completed? Build a brand new struct?

Also, given that we should note that since copies of the struct are wandering around it's entirely possible for someone to try to update an item that's been deleted or created with some other UUID. And your getEntityById functions assumes that element 0 of the array always exists.

An assumption that could crash the app. (fetch(request).first would fix that code, but then the explicit unwraps in update and delete would fail...

I guess the question I'm asking is whether or not this is a case of premature optimization? We're attempting to "protect" the app from a situation that might never occur. Which means that we're writing more code and, unfortunately, introducing more bugs into the process while doing so.