Since about 20003, I have made a bit of a career of removing CoreData and its predecessor EOF from applications.<p>Every time it has been a huge success in terms of simplicity, performance and reliability.<p>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.<p>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.<p>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.<p>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]<p>[1] <a href="https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_11" rel="nofollow">https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...</a><p>[2] <a href="https://www.youtube.com/watch?v=kHG_zw75SjE&feature=youtu.be" rel="nofollow">https://www.youtube.com/watch?v=kHG_zw75SjE&feature=youtu.be</a>