
A taste of CoreData – A graph framework - yageek
https://yageek.github.io/blog/2018/02/19/a-taste-of-core-data-0-a-graph-framework/
======
mpweiher
Since about 20003, I have made a bit of a career of removing CoreData and its
predecessor EOF from applications.

Every time it has been a huge success in terms of simplicity, performance and
reliability.

Replacing EOF happened in a feed-processing application[1]. We just processed
everything in memory and persisted the incoming feed, which we wanted to do
anyway for auditing. In that instance it wasn't so much a planned removal, but
rather that we never came around to implementing the DB component.

Next up was a desktop application, Livescribe Desktop. It was using an atomic
store, so there wasn't really any point to CoreData. Chucking it meant
removing a lot of code and crash-sites.

For Wunderlist 3, we rewrote the storage layer to simply use a bunch of JSON
files (our CTO used to shock people at conferences with that little nugget),
and the "In-Process REST" ideas from [1]. So our persistence solution was
essential [NSJSONSerialization dataWith...]. The day after we launched, I was
shocked at the number of crash reports, but my colleagues informed me that
they had 10x the amount the last time. With millions of users, you get into a
lot of edge cases. Oh, ours was also the fastest of the clients.

Oh, I also gave a talk at UIKonf '17 about making a public transport data
(sample) application 1000x faster by moving from CoreData/sqlite to a custom
data representation.[2]

[1]
[https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...](https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_11)

[2]
[https://www.youtube.com/watch?v=kHG_zw75SjE&feature=youtu.be](https://www.youtube.com/watch?v=kHG_zw75SjE&feature=youtu.be)

~~~
yageek
The purpose of the post is just to provide some general information about the
different concepts provided by CoreData. The framework first lacks of a clear
documentation I would say. Regarding reliability, if the rules are respected,
I would consider CoreData as a reliable framework.

Regarding speed, I would say that CoreData is far lower than other low level
approach. It is up to the developer to estimate the needs in term of
speed/performance.

The biggest advantage of CoreData, according to me, would be the integration
with the UI libraries, but this is only my opinion :)

I guess you gave the same talk at appbuilders last year right?

------
_sdegutis
Kudos to OP for braving through CoreData. I’ve been using it on and off since
it was released, and it’s an awfully cumbersome and error-prone framework. And
as Apple adds more complexity to iOS, CoreData gets exponentially worse. I’m
200% convinced today that it’s far better to just store your users data in a
more traditional cloud database instead. _Especially_ with syncing, which
Apple made ridiculously, unnecessarily hard to get right.

~~~
oligopoly
>I’m 200% convinced today that it’s far better to just store your users data
in a more traditional cloud database instead

What would you recommend? Firebase, Realm or something else for small project
that might or might not get off the ground?

Personally I've found the hardest thing tapping in iOS development there
doesnt seem to be culture of writing out tutorials / problems people had and
how they fixed them. Doing webdev you find countless similar issues people had
and how they fixed them with simple google search. Lot of docs are in
objective-c as well which kinda pushes you to study two languages instead of
one.

I tried React Native for a while but it's ridicules how fast stuff get
deprecated and the feel is far from 'Native'.

~~~
kitsunesoba
What specifically are you having trouble finding tutorials for? I’ve had
little issue finding ios tutorials for most things.

This particular bit is far better than it used to be, back when Apple platform
development meant Mac apps written in Obj-C and AppKit. Back then, your best
hope were a handful of blog posts and mailing list threads. If your issue
wasn’t there, you had to figure it out on your own.

Today there are tutorials for Swift and UIKit springing up all over the place.
It’s quite a change.

------
RantyDave
NSPredicate. Back in the day I fought through the CoreData only kinda SQL
thing and eventually got a result but... These days I'd just shove it on
SQLite and get 10x the performance for 10x less effort. God DAMN that was hard
work.

[https://developer.apple.com/library/content/documentation/Co...](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Predicates/AdditionalChapters/Introduction.html#//apple_ref/doc/uid/TP40001789)

~~~
danieleggert
Well, that’s a common misconception, but far from the truth. If you actually
care about performance, you’ll soon find out that performance wrt. database
work is all about high-level optimizations: You want to reduce the times you
hit the database (both reads and particularly writes).

And once you’re getting into that busyness, Core Data will allow you to create
way faster coder in less time. Core Data will get you 10x the performance for
10x less effort.

~~~
mpweiher
Hmm...parent is actually correct. What you write is true with very _slow_
databases, particularly when talking to enterprise databases over a network.

"Fortunately", CoreData is so slow that as long as you stay within that
universe, your view will never be invalidated.

Outside, however, computers are blazingly fast in general and I/O throughput
is also incredibly fast. My _laptop_ can read/write 2 GB/s. That's a lot. Moby
Dick is around 1.25 MB. This means that you can write this whale of a book, in
its entirety, 800 times per second. That's a lot. But I repeat
myself...because it's worth repeating.

CoreData helps you optimize/minimize the size of transactions. Except for a
very few cases, that's the wrong thing to optimize, as all our storage has
amazing throughput and not-so good per-transaction and seek costs. Getting 1
byte from disk is almost as expensive as getting 1 megabyte, and having a
bunch of smaller transactions is almost always a loss compared to one large
transaction.

------
Unknoob
I've been using CoreData in a big project but the multithreading has been
crashing my app a lot. Can anyone recommend me some alternatives for a simple,
lightweight, 100% local data storage for iOS?

~~~
vlozko
I've always felt that mastering CoreData's multi-threaded APIs are a trial by
fire. Tutorials and recommendations only got me so far and I had to stumble my
way through to truly master it. At the end of it all, I got a bigger feeling
of appreciation for the complexities involved in multi-threaded synching of
data and its persistence.

