I'm not saying Apple's alone in this (that was someone else), I'm just pointing out how Objective C can relate to lock-in.
Certainly using any OS's unique APIs can bind you tightly to that specific OS.
However, there are also lots of APIs that are the same, or so similar that dealing with them generally doesn't lock you to anything. The standard C library, for instance, contains lots of useful stuff, most of which works as designed on all major platforms (Windows, OSX, linux), and you can often leverage that without any significant lock-in with the exercise of a little care. Some things -- like fork() -- you need to know where and how the differences affect you, but mostly there's a uniform set of tools.
In my case, I've found it absolutely worth my while to avoid vendor specific APIs as much as possible, and write my own stuff. Not only because then I can move it around (which I do... I write for multiple OS's, often within the context of a single project), but because unlike an OS vendor, when I find a bug, I fix it instead of sitting on it for months or years. So I have lots of graphics stuff, list handing code, memory allocation code, threading code, etc. that I use.
For instance, one recent project was a library that contained a suite of live, non-destructive image processing code for DSLRs. It was designed to leverage multiple cores and give the user control over various aspects of that. I leveraged POSIX threads instead of the OSX API for threading; works great, and runs on multiple platforms, which it would not have if I had stuck with the OSX Objective C API.
Then there's QT, which provides a uniform (if somewhat busted) API that hides the OS underneath, and gives you a pretty good degree of platform independence in doing so. Sadly, QT is just as prone to leaving serious bugs in versions and blundering forward without fixing them (ever) as are the major OS vendors. So again, building your own code instead of using the provided APIs can save you.
It's a matter of time on the one hand, and of craftsmanship on the other.