A taste of CoreData – A graph framework
yageek.github.io
yageek.github.io
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_...
[2] https://www.youtube.com/watch?v=kHG_zw75SjE&feature=youtu.be
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?
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'.
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.
https://developer.apple.com/library/content/documentation/Co...
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.
"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.