CoreFoundation vs Foundation

In a technical sense, yes, it is faster, for exactly that reason.

In a practical sense, no, it's not faster. For one thing, the speed difference is tiny. We're talking milliseconds saved over the life of the entire process.

The savings might be bigger on the iPhone, but it's still pretty much the tiniest speed gain you can get. Your time is much better spent profiling your app in Instruments and going where it tells you and ironing out the hot spots in your own code.

And that's where Foundation becomes faster: Your time.

Code that uses Foundation's autorelease feature whenever feasible saves you a lot of time and headaches by avoiding easily-avoidable memory leaks (namely, forgetting to write or failing to reach release messages). CF does not have autorelease, so you have to remember to explicitly CFRelease everything you create or copy with it—and when you forget or fail to reach that code (and I do mean when—I speak from experience), you will spend much more time hunting down the memory leak. The static analyzer helps, but it will never be able to catch everything.

(You technically can autorelease CF objects, but the code to do so is terribly ugly and you're only watering down your already-minuscule speed gain.)

So, stick to Foundation as much as possible. Don't go overboard with the autorelease; even in pure Cocoa, there are still times when explicitly releasing objects is warranted (mostly tight loops), and this goes double for Cocoa Touch (since iOS will kill your app if you allocate too much memory, so you'll want to release big objects like images as soon as possible). But usually, autorelease saves you far more time than CF will ever save your users.

The non-time-related reason is that Objective-C code, with argument names (from the message selector) mixed in with values, is far easier to read than C function-based code. This may not make your work go any faster, but it certainly makes it more fun.

Writing code in CF functions might indeed bring a performance boost to your app, however if you really want the ultimate performance boost, you could be simply writing code directly in machine code, it can't get any faster than that. Though this would be an extreme approach.

High-level language constructs are preferable to the low-level ones for at least the reasons Peter Hosey mentioned. To this we can add the premature optimization which can easily lead to the failure of the project, as the developer is more concerned with the non-functional aspects of the application instead of the functional ones.

If, after you have a fully functional app, you feel that some parts of the code have performance bottlenecks, you can try to optimize those, by rewriting them to low-level language constructs. You'll at least have a comparison point with the current code, to make sure the low-level code behaves as expected (either manual or unit tests will do the trick here).

What I'm trying to say is that while we should not ignore performace, we should not make this our first goal. Functional aspects are as well as important (of not even more). If you don't have an app that delivers it's functional specifications, then it might be the fastest on the planet, and people will still not be using it.