I can't speak for Apple (I'll leave that to
Ben), but there are a few things to keep in mind
here:
1) Core Data is still a relatively new
technology. Sure, it came out with Tiger, but
since using it keeps your app from running on
earlier versions of OS X, a lot of software
projects never adopted its use. When using
traditional objective-C persistence (e.g.
NSCoder) a lot of these issues don't exist
This isn't true. AppKit and Cocoa Bindings
aren't thread safe. They're built around
NSRunloop, and that's why
-performSelectorOnMainThread: works much much
better.
Having background threads feed into the main
thread's run loop isn't that bad. Not to my
personal aesthetic, but really, not that hard.
The binary store that David is using is based on
NSKeyedArchiver, so getting rid of Core Data
won't markedly improve things if he tries to save
on a background thread.
Once David has tried the SQLite store, I believe
things will go vastly better. I'd wager roughly
100x better.
It's true that Core Data requires newly inserted
objects to be saved before other threads can
access them.
First, this is a limitation that people should
file bugs upon, if they care. I stand corrected,
in 4 years only 1 developer has cared enough
(sorry, Adam)
Secondly, on 10.5, you can insert roughly 500
objects *per user event* on intel hardware.
That's 5 objects per millisecond. For many
developers, this has proven, while inconvenient,
also adequate.
Just my 2ยข... Like you, I'd still like to see
Core Data become fully thread-safe, but you
can't always have what you want when you want it.
