Haha! I like it. I know the feeling - I often wonder how the rest of the world gets by. Heck, I wonder how I got by in years past :)

Hi Scott,

What a life we (Cocoa folks) lead, hm? Every time I find myself digging in deep to really understand what some object in the Cocoa framework is doing, I giggle. Fifteen years ago I was programming and it seemed like I'd never be able to accomplish much of anything without years of toil and confusion. These days I feel like a kid playing with lego blocks. Between OOP and the Cocoa framework, I'm a very happy 35 year old kid.

Best.
Anton

bastards... leave me alone, I'm trying to make a buck here ;-)

Very cool. I just wish I knew how!

Hi Scott, I've read (and used) your guides on Core Data. What an excellent document(s) you've put together. And I truely am impressed at what Apple has developed for us, and at the end of the day for consumers to experience great .apps. But I've a 100% background in Windows development, and I guess this makes me a skeptic when looking at something like Core Data (I'm just not used to seeing something like it), not a negative skeptic, but skeptic that Apple have offered something so easy that it doesn't have flaws.

Perhaps I should explain myself further, why the skeptic? I guess there's a couple of things on my mind, and I hope you don't mind the time to read, and perhaps respond to my questions with your ideas/corrections/opinions.

1. To good to be true?
While the design of entities looks great, and the MOC takes care of presenting the data between the View and ones Model, to my amazement Apple have futher taken care of persistance for us! But at what cost? Surely we've had to give up some of the control that we once had, it's no longer our glue-code. It must now be taken care of Apples black-box. Right?

When I used your Core Data tut, immediately I was impressed (I think I've made that clear ;) but also I felt that I might have lost control here of my app. And I find it hard to believe that Apple Core Data and Controlling interfaces would be able to handle all my needs. To be sure there will be something that I want for my .app that CD/MOC will not be able to handle?

You've used Core Data more than I, do you find a lack of control over your data or UI? Do you fear that there will be a component of this drag-and-drop system missing and not allow you to do what you want? Are you able to override the Managed Controllers for UI validation, or more?

2. Locked into an Apple OS?
Core Data appears to be new to Tiger, right? I guess this immediately locks you into 10.4 if you where to release an .app. I guess this is a individual, or enterprise decision more than anything.

But don't you have doubts that, if a component or implementation of Core Data were missing and was corrected/added in 10.5. A feature your project required and you implemented. Wouldn't you find that perhaps your .app is constantly locked into the latest version of OS X? In the ideal world everyone would upgrade, but we all know this not to be the case. What's your thoughts here?

3. Model Versioning.
Are you worried that as your .app evolves (during dev. or after release) and as features creep into your system, this (apparently) hard coded Model becomes difficult to maintain?

From what I've read, if you change your Model you can no longer open your existing XML/Bin/SQL model files/dbs. This to me sounds immediately scarey. Further reading Apple suggests that you update existing (lets assume XML) files before you .app connected to the data source. But also I've read that Apple does NOT recommend opening the XML by hand, Core Data might change the way is reads/uses the XML and you may inadvertantly break your .app.

My question, does Core Data in-fact have a Model versioning system built in? So you can easily offer a version 1.0 to 2.0 path?

4. Production strength.
In your opinion with Core Data and the MOC, is this production strength design and .app building? I often see Core Data code floating around Apples developer website, and this makes me wonder if indeed the CoreData/MOC is not flexible enough, and you do often resort to code. (Does this reflect back into my questions in Q1? Or is CD indeed strong enough to build your .app from the Model Designer and the Control-Drag the little blue lines around Interface Builder?

Again, I do hope that you read this post, and that you've time to respond. I enjoy your blog, keep it going (and if you've more Core Data tuts for Cocoa Central I will lap them up!)

Surely we've had to give up some of the control that we once had, it's no longer our glue-code. It must now be taken care of Apples black-box. Right?

To address this in broad terms, using a generalized framework always means you're giving up some level control, but control also means responsibility. If you know for sure that you can write a better persistence engine, then don't use Core Data. If you trust Apple's extensive experience with this sort of thing, then you can ride the wave.

Of course, there's a middle ground. It's not as if you stuff data in one end and something mysteriously comes out the other side. There are many opportunties for customizing, tweaking and subclassing along the way. For example, you can use Core Data for change tracking and do your own persistence layer.

And I find it hard to believe that Apple Core Data and Controlling interfaces would be able to handle all my needs. To be sure there will be something that I want for my .app that CD/MOC will not be able to handle?

Only the most simple apps can get away without writing custom code. Anything serious will simply use Core Data as a more evolved base starting point, and build up from there.

Core Data appears to be new to Tiger, right? I guess this immediately locks you into 10.4 if you where to release an .app. I guess this is a individual, or enterprise decision more than anything.

Yes. The reason Apple invested time in Core Data is to encourage developers to create Mac-first and Mac-only apps, increasing the Mac OS X's attractiveness. The developer reaps the rewards of simplified development in return.

Wouldn't you find that perhaps your .app is constantly locked into the latest version of OS X? In the ideal world everyone would upgrade, but we all know this not to be the case. What's your thoughts here?

There's no complex equation here. The frameworks get better with each release, and you support the best version you can. It's also not just a matter of how many users are on a particular version of Mac OS X. Sometimes a new framework or a newer version of an existing framework makes a particular app practical for the first time. In that case, it makes sense to require the newer OS (even if, say, only 10% of your users have it) because otherwise the app doesn't exist at all.

Are you worried that as your .app evolves (during dev. or after release) and as features creep into your system, this (apparently) hard coded Model becomes difficult to maintain?

The model is actually not hardcoded. It can be manipulated with the NSManagedObjectModel API. Model versioning is more difficult than any of us would like, but it is possible and Apple does provide sample code.

From what I've read, if you change your Model you can no longer open your existing XML/Bin/SQL model files/dbs.

That's a vast oversimplification. You have to be aware of the issues, but it doesn't make older files unreadable.

In your opinion with Core Data and the MOC, is this production strength design and .app building? I often see Core Data code floating around Apples developer website, and this makes me wonder if indeed the CoreData/MOC is not flexible enough, and you do often resort to code.

I don't think the Core Data design is as rigid and restricting as you think. I think my earlier answers address most of this, but let me know if you have further questions. The short version is that "real" Core Data applications are not codeless. The point is that you can get basic prototype functionality before writing code, and you don't bog down the project with redudant classes.

For what it's worth, Aperture uses Core Data, and it's obvious not a trivial app.

<blockquote>There are many opportunties for customizing, tweaking and subclassing along the way. For example, you can use Core Data for change tracking and do your own persistence layer.</blockquote>

My experience with Core Data are your articles on CocoaDevCentral.com and with some of the basic stuff from Apple is very simple. These guides don't get down into the nitty-gritty that you only find after 4-months of dev or a version 1.01.

Like I mentioned, coming from a Windows dev. world, it's hard to believe that the OS would offer stuff like Core Data.

I understand your "Ivory Tower" post the more I think about it. I spend all my working day trying to convert an old DAO application to ADO and it's draining hours and hours and hours. This is just the fundamental stuff connecting the Windows App to the Backend. It's insanity, we've had to have a sit down with the CEO and break the bad news that the previous developer worked off an anti-pattern called "Big Ball of Mud" (look it up in wiki, it's there, that's a real term) and the dev. time is looking longer than expected. He's devastated to say the least...

Excuse me while I rant a little more, and flog MS for the worthless beast that it's become. Windows XP introduced themes "Luna" as it's known by, at the same time they release the 2002 .net development environment/runtime. This is a dual release between OS and IDE. You would assume that the new theming of the OS would be built into the IDE, you know like that tickbox in XCode to use Brushed Metal? Nope, it's not there.

Time passes and Visual Studio .net 2003 is released, is theme support in there out-of-the-box? Nope.

More time passes, and it's taken to Visual Studio 2005 to have theme support built in (BTW there's no tick-box for Visturd theme support in there either.)

This is the shi... crap that as a Windows developer I have to put up with. An OS that doesn't even support it's developers to make it even look half-good. Without extra API calls etc. And to be honest, I am not even aware of MS using their .net development tools for any of their system(s) (apart from the CRM extention module for Outlook). What's that MS have an IDE that massive and costly? And I am not even aware of software that they develop that uses the .net runtimes. That's because the .net runtimes are poop (if you ask me that is)

Now, I think you see why I can't believe that Apple not only give you their Dev. environment for FREE, they have a whole, working, framework that they use too (as you prove with Apature)! Sorry for my rant, I got a little out of control didn't I? I am typing this with a smile, part in jest and part in frustration.

<blockquote>The point is that you can get basic prototype functionality before writing code...</blockquote>

Interesting, I like the idea. And indeed it's amazing. I wrote a little app in 1.5 hours using Core Data and using your tutorial as a reference (only when I couldn't remember a step) and had a basic working app, that also persisted the data. I like where it's going. it's fast, it's beautiful and I am not dealing with the silly bits of glue/refresh code.

<blockquote>Model versioning is more difficult than any of us would like, but it is possible and Apple does provide sample code.</blockquote>

That's the jist that I got too. I will look into versioning further, and remove all my doubts


When taking my original line of questioning and blockquoting it, I felt that perhaps I sounded to negative to what Apple has created and how I felt towards Core Data. I didn't want that, but that's the skeptic in me creeping in.

Scott, for me this has started to remove the doubts of not-knowing Apples system. I just needed a lauching-pad, and I will now endevour to spend more time with [Obj-C] and XCode and I think I WILL begin to prototype my little .app in Core Data and see where it takes me. I am extemely enthusiastic with Apple and their OS and their Developer Tools, I only wish I could make it to a WWDC. The problems of distance, *sigh*.

Could you recommend any books or material to further my journey? Especially interested in XCode and Core Data.

Kind Regards,

Sorry about the blockquotes, I though they might work. Should have used <i> eh? I am so embarrassed.

Isn't there also man sqlite3 (as a small scriptable alternative)? (Anyway, perhaps go and find some direction in "The A to Z of Programmers Predilections", www.hacknot.info/hacknot/action/archive ... :)

My experience with Core Data are your articles on CocoaDevCentral.com and with some of the basic stuff from Apple is very simple. These guides don't get down into the nitty-gritty that you only find after 4-months of dev or a version 1.01.

I think part of this is that it's much harder to write about the hard stuff. :) It will be done, but writing the kind of articles that I think people want takes a lot of time. I like writing about Core Data, though, so expect to see more of that.

It's true that the basic stuff is very simple, but customizing the basic stuff really isn't that hard either. The class hierarchy that makes up the Core Data framework is incredibly straightforward for what it does. There are only a handful of classes that you need to know about.

In my opinion, the hardest parts (those that require the most care) of writing a sophisticated Core Data app are the hardest parts of writing any sophisticated Cocoa app. That is, you have to get the threading right, optimize speed and come up with a data model that works.

Now, I think you see why I can't believe that Apple not only give you their Dev. environment for FREE, they have a whole, working, framework that they use too

In my opinion, Microsoft doesn't have to try as hard as Apple because they have millions of customers locked in. Apple is motivated to offer great frameworks because they want people to write tons of great apps. As far as I can tell, it's working.

it's fast, it's beautiful and I am not dealing with the silly bits of glue/refresh code

The view is nice up here. :)

Could you recommend any books or material to further my journey? Especially interested in XCode and Core Data.

Jonathan Rentzch recommends Step into Xcode, so I'll just recommend that by proxy.

Ben writes: "Now, I think you see why I can't believe that Apple not only give you their Dev. environment for FREE, they have a whole, working, framework that they use too (as you prove with Apature)! "

Now think about how it was 12 years ago, when the NeXT frameworks and tools were about 75%-80% as good as Apple's are now. Now think about what Microsoft's dev tools and operating systems were like 12 years ago, how primitive they were. No .NET.