I think you don't get my point: I expect a domain expert to be a domain expert, but I don't expect a trainee to know anything and I'll structure my interview accordingly. I'll ask the domain expert questions about his domain. But I don't expect a domain expert to know the programming language that we work with just because he's a domain expert. And seriously, I'll prefer the eager-to-learn math graduate with little coding experience over the bored cs graduate that knows the java reference doc by heart and now thinks he knows how to build stuff. In any case coding examples in your interview will show you little beyond the fact that somebody memorized the docs.
The actual pain point I read from the article is a different one: There's a mismatch between hiring process and expectations. If I need a lead programmer for the iOS project that I'm about to start next week then I can't hire anyone that doesn't know Objective C and then I absolutely need to structure my interview accordingly. But if I have a couple of weeks more I'll happily teach him. And if I'm hiring somewhat smart I try to avoid those "we need someone urgently" situations.
I think you vastly underestimate the time it takes to learn these sorts of things. Sure, you can teach someone to write a simple, passable iOS app that does a few basic things in a couple weeks. But they're still going to be a raw-novice iOS developer. Maybe the app you need them to build is super simple, but if not, you're doing yourself and your company a disservice by not hiring someone who's done iOS before.
I'm speaking from experience here: I learned iOS (even after having previous MacOS X desktop devel experience) on the job, when a friend asked me to write an iOS app for her startup. I learned quickly, but made a lot of mistakes in how I structured the app that came back to bite me months later. If I'd had the time to start over from scratch, I would have done things quite differently and the whole thing would have been a lot easier.
And I was slow. Every new framework I had to learn slowed me down and added days to implementing the part of the app that needed it. A seasoned iOS developer wouldn't have run into problems like that.
I think you vastly underestimate the value of "other knowledge" for any kind of complex undertaking. Unless you get a domain expert who happens to be a rock star programmer and a ninja architect and top-notch devops, you'll have to compromise somewhere. Take an iOS game: Depending on the game it can be vastly more value to have knowledge of game programming and game AI than having knowledge about iOS frameworks. If there's a team on the project I'd even go as far and say that I would pick the domain expert over the framework expert as team lead, given that all other capabilities were on par.
Sure, there are always compromises. I wasn't claiming otherwise. I was merely pointing out that ramping up on a particular platform is nowhere near as easy as the parent suggests.
Games are a bit of a special breed, though, and there are several game engines out there that hide the platform pretty well. I draw a bit of a distinction between "building and iOS app" and "building an OpenGL app that runs on iOS". The latter is much easier if you lack iOS experience but have the required OpenGL skills.
I also think that there might be a mismatch between hiring process and expectations. When you say "But if I have a couple of weeks more" then you obviously underestimate the time it takes to learn if we are actually talking about somebody without much programming experience. Try "if I have a couple of years more".
See, there's so much more that you need to learn when you start on a project in a company. There's the framework they use, their libraries, the requirements for the project, the problem domain, the people you work with, the process they use, ... just to list the few that come to the top my head. Especially learning the problem domain can be very hard and challenging to programmers with little or no knowledge of the field. It can easily take a couple of month, if not years to become reasonably proficient.
So yes, "a couple of weeks" is certainly not enough to transform a graduate into a project lead for bespoke iOS project, but it could easily be enough to transform a decent java programmer with solid project lead experience. Transforming a crack Objective C Programmer with no lead experience can take easily as much time, if not more.
My gist is that programming knowledge will only get you so far and depending on what position you're hiring for other experience combined with the ability and willingness to learn may be much more interesting. And whatever I do, I tend to hire for that trait since that allows people to pick up other abilities when required.
The actual pain point I read from the article is a different one: There's a mismatch between hiring process and expectations. If I need a lead programmer for the iOS project that I'm about to start next week then I can't hire anyone that doesn't know Objective C and then I absolutely need to structure my interview accordingly. But if I have a couple of weeks more I'll happily teach him. And if I'm hiring somewhat smart I try to avoid those "we need someone urgently" situations.