Wednesday, April 1, 2009

Apple's Xcode Team is Hiring

Via Michael Jurewitz, the Xcode team at Apple is hiring.
Join Apple and help lead the development for the next generation of iPhone OS development tools!

Here's the job posting at Apple Jobs.


Vargo said...

Oh my god, whoever they hire, let's pray that they know what a working Watch window is.

Vargo said...

... and frankly, let's pray they have lots of experience with Visual Studio .NET development in general. There is so much room for improvement in XCode.

Jeff LaMarche said...

If there are specific features of Visual Studio you'd like to see added, and haven't used the Bug Reporter to file an enhancement request, then you should go do so. Vague bitching about Xcode not being as good as Visual Studio in the comments of one blog isn't going to change anything.

Personally, I like Xcode. I find Visual Studio to be over-engineered and busy. I've used VS, Eclipse, and Xcode regularly, and I find Xcode suits my way of working better. It doesn't mean Eclipse or VS are bad, just that they take a different approach that doesn't work as well for me.

For the record, Xcode's debugger window works fine for me, at least as well as VS' Watch Window.

Many people who have used VS for a long time feel like you when thy first come to Xcode. I'll be curious to see how you feel in a year if you're still using it.

teqman said...

Be careful: Apple's jobs site is very poorly designed. A while back, I wanted to apply to both the team and the Xcode team. I applied for the position first, and tailored my cover letter as appropriate. I then went to apply for the Xcode position, but the system would not let me specify a separate cover letter for this application. I checked the site today, and my application for the position had actually been removed, so I was stuck with an application for the Xcode team using a cover letter that talked about the position.

It's a moot point for me now, but I still think it's a significant flaw.

Jeff LaMarche said...


Thanks for the info. Having actually worked on corporate recruitment software, I could write a book on the problems with these solutions, and the one Apple uses is not particularly horrible in the scheme of things.

Finding and hiring good people for large corporations is a non-trivial problem.

Honestly, the best way to get hired in any position is to get to know people. It sounds horrible, but unless you have just a phenomenal resume, it's going to be hard to rise above the crowd of resumes they're going to get.

If it makes you feel any better, I plugged my resume into their automated system that's supposed to suggest jobs you are qualified for.

It told me I was 50% qualified to be an entry-level IT tech, and 25% qualified to be an Intern.

I'd like to think I'm at LEAST 50% qualified to be an intern.

Vargo said...

Jeff, yes, I have made excellent use of the bug reporting tool. Some issues are probably a result of my ignorance or personal preferences. A couple examples:

1. Why, when I click on a build error/warning, does it open up a separate window with the problematic code, on top of the existing window? Why not just bring me to that file? I can easily get back to the previous file. It's an odd workflow to have an almost functionally equivalent window branded simply for debugging, when I could just use the original one for that.

2. Regarding the Watch window, I realize there is this thing called the expression viewer, and it does just fine displaying simple objects, but why do I have to cast some of them? Maybe that's a technical limitation I'm ignorant of. But more severely, why aren't completely intuitive expressions like someObject.someProperty, or [someObject someProperty], or even [someObject someMethod] supported? I have called on the assistance of web forums, IRC, and mailing lists and the answer I always get is to use NSLog statements. Seriously? NSLog statements? What is this, the early 90's?

3. The first thing every XCode development tutorial author always does is minimize that useless, redundant file list window at the top of the screen. If nobody likes it, why is it there by default? Who uses that? I've got a file list on the left... I don't need one on top, too. Needless redundancy seems to be a theme in XCode.

Of course, it's free, and I can't forget that. But I also can't forget how much money Apple is making on iPhone developers.

Like a typical Microsoft product, Visual Studio is packed with features to the point of having many I never use, but most of these are hidden in menus. Having tabs for each open file is a luxury I didn't realize *was* a luxury. It has a Watch window that works, supports Intellisense aka code completion, and performs much better. If any layout issue bothers you, this can be addressed by their extremely flexible, customizable GUI. In fact I challenge anyone to switch to coding in C# with the latest version of VS for a while, and then come back to XCode/Objective-C for anything other than necessity.

And to answer the inevitable question, I'm coding for the iPhone because I love the platform from a user experience perspective.

Jeff LaMarche said...


Have you tried Xcode's All-in-One mode?

The default mode in Xcode simulates the old Project Builder multi-window paradigm. That paradigm is a little dated, but it's what a lot of Cocoa programmers are comfortable with, and it does lend itself to multiple-monitor setups fairly well. There are some things about that view that annoy me also, which is why I use the All-in-One mode most of the time.

The detail view can be very useful if you've got deeply nested file hierarchies or subprojects, and hitting command-shift-e hides and shows the detail pane, so it's hardly something I consider a huge deal. My only complaint with it is that there are some actions that open the detail view unnecessarily (like double-clicking on a target). In single-window mode, that space is shared with other context-sensitive views and will probably bother you less.

The types of expressions you're referring to can be used in both the debug console or the expressions window. I can't honestly respond to your complaint, because I don't know why it's not working for you. I add expressions using both [someObject someMethod] and someObject.someProperty frequently to the expression window (in fact, I just tested it to make sure it works in a project I had open and both forms did), though personally I am more likely to use the debugger console to type GDB commands or a breakpoint action to accomplish the same thing.

And I can tell you my experience with C# is completely the opposite. I find it rubs me the wrong way and I feel very out-of-place in VS.

Not saying I'm necessarily "right" in any kind of sense, just saying that what you're used to very much colors what you expect out of software. Xcode and VS came from different design philosophies were created to meet the needs of programmers using very different languages. You might have success requesting specific features from VS, but I can almost guarantee you that Apple will never make Xcode feel like VS.

For me, having spent more time in Xcode and Project Builder (Xcode's predecessor), there are things that .Net programmers love about VS that I despise. It's likely because I don't think like a .Net programmer. I know the languages and libraries and can make things work, but I'm constantly thinking to myself "this wants me to write ugly code" while I'm working in it. Yep, it's a biased opinion, that's for sure, but I come by it honestly.

Vargo said...

Yeah, it definitely seems like a lot of it comes down to personal preference / familiarity. I will have to try the All-In-One mode; I never even knew it existed. As for the someObject.someProperty issue with the expression view, the problem is that no matter where I enter those types of expressions, I'm told that the variable is "out of scope". I'm not sure what my issue is.

I do agree (as do most experienced Windows Forms developers that I know), that Visual Studio's GUI designers make it very easy to write bad code. They're practically asking devs to write business logic in their UI code. This problem is largely addressed by WPF (Windows Presentation Foundation), which is their incredibly powerful/flexible new UI system, but the learning curve is so steep that it alienates a lot of novice/intermediate developers.

Thank you very much for the All-In-One mode suggestion; I will try that out.

jrock said...

from someone who's currently working in both vs and xcode, i find xcode to be simpler and more intuitive. i too like the debugger in xcode - more streamlined and easier to track data.

i won't even discuss the efforts of installing vs. asldkfjakldlf!!!

jeff, your entries about going to wwdc are making me jealous. i can't really justify going at this point, but i'm going to shoot for next year if i can achieve a modicum of success in this development area.

Vargo said...

Well, considering that VS is something I've used for over a decade, it's hard for me not to find it much more intuitive than XCode, which I've been using for only a few months (and I'm still learning shortcut keys).

I can't even fathom how XCode debugging is easier, given that you have to typecast many object in the expression viewer, or manually "print" variables in a console window (seriously?? we're still doing that?), or else rely on NSLog statements to view the values of more complex data types. I need to post screenshots of XCode failing to display simple properties, and get your responses/solutions.

Also, I find Intellisense to be incredibly powerful and polished compared to XCode's code completion feature, but a lot of this might just be familiarity/preference. I also can't help but be biased toward C# versus Objective-C, but that's a somewhat unfair comparison since C# is so much newer.

Jeff LaMarche said...


I'd have to say the comparison between C# and Objective-C IS unfair, but it's unfair to C# :) At least from my point of view. I think Objective-C's slow growth has been a boon, not a bad thing - languages that grow too fast end up like Java or C++. It's the kitchen-sink approach to language growth. Everything anybody wants gets thrown in and the language becomes a mediocre general purpose language rather than a great language for certain tasks.

C# derives it's object model from Simula, so it's strongly typed with lots of compiler checks. That leads to the need for things like generics and dedicated classes for introspection. When you're working around the nature of the language this hard it means perhaps the nature of the language isn't well suited to the task at hand.

Strongly typed languages are ideal for things like designing device drivers and operating systems. However, when designing event dispatching and view hierarchies for a GUI application framework, these compiler checks and lack of true introspection become obstacles to be worked around rather than a help to the developer.

Worse than that, C# compiles to CLR bytecodes rather than to machine code, so you lose one whole avenue of optimization because you are insulated from the hardware by the runtime. That's an odd thing for a language designed for a siingle operating system that almost exclusively runs on a single processor architecture.

Just my 2¢, but just because something is old, doesn't mean it's bad. Objective-C has been around for twenty years and its growth has been constrained and geared in one direction: building GUI desktop applications. You might want to spend a little more time with it before condemning it as creaky and old.

Vargo said...

I can say I dislike Objective-C less the more I learn, but not by too much. But granted, some of these issues exist with C/C++ as well. For example, why do we even need header files? There's no use aside from a side effect of how certain compilers happen to work. All they do is introduce frustrations.

And strongly-typed languages are a great thing, in my opinion; the alternative invites countless errors. From a workflow perspective, I haven't run into any hurdles that this strong-typedness introduces, especially with the "var" keyword which essentially lets you have your cake and eat it too. I have, on the other hand, run into countless situations in which the nature of dynamic languages makes me unable to discover a bug until run-time that would have been easily discovered at compile-time in a strongly-typed language. That's not to say a dynamic language doesn't have its merits.

And for virtually all of my situations, the fact that it's compiled to intermediate language is a benefit, not a drawback. The compiler is going to optimize my code much better than I could in most cases, and I virtually never notice any slowdown. And it's not designed for a single OS in theory; for example, you could run Mono on Linux to run .NET applications (can't say I've tried it, though).

I also loathe convoluted APIs prefixed with tags like "NS" or "CF", etc. There's no need for that when you have namespaces. And why do properties have to be defined and also synthesized? I actually know why, but it's still a clunky user experience that feels like redundant work. And why does it matter what order I define methods (assuming they're not declared in the header)? This is a relic that shouldn't be an issue anymore. Is it so hard for compilers to look ahead in a class definition file? It must be, otherwise I'd think they would have done it by now.

Oh, and encapsulation is one of the foundations of OOP, so why is it such a burden to create access modifiers in Objective-C? Really, I have to use "Categories" to enable private methods? Unbelievable.

And I won't even go into garbage collection, since I realize why the iPhone OS doesn't support it, so it would be unfair to complain about.

And code should be declarative. You should be able to read it and get a good idea what it's doing. I give Objective-C credit (though this took a while to warm up to) for requiring that you type method parameter names as well as their values, for clarity, despite the bizarre syntax. But compare the code required to find a string within a string, for example:

if ([myString rangeOfString:@"mySubstring"].location == NSNotFound)) {
NSLog(@"mySubstring not found in myString: %@", myString);

What does that code do? Is that in any way intuitive? Now look at the C# version:

if (!myString.Contains(“mySubstring”))
Console.WriteLine(“mySubstring not found in myString: “ + myString);

I can find countless examples like this. I dunno, maybe I'm just a lazy programmer. Maybe I don't use my brain as much as I should and I'm contributing to the dumbing-down of the profession as a whole.

Fabien Penso said...


I agree to most of what you're saying about XCode, but I really like obj-c. I think it's the way c++ should have been down at the beginning. But I like dynamic languages, Ruby, etc.

I just wished xcode was better, and Apple a bit more friendly with opensource developers.

At the end I just really like the iPhone as a user experience, and wanted to contribute on that.

Fabien Penso said...

One more. I don't think it's fair to compare obj-c and c#, those are not from the same century, and don't have the same purpose. Better comparing obj-c with c or c++.

(And I really like c# too, so much more than Java on a technical point of view)

Vargo said...

Fabien, I agree that it's not fair to compare Obj-C to C#. I mentioned that in one of my comments but I think Jeff disagreed. :)

But yeah, I sound like a Microsoft fanboy, but I'm always accused of being an Apple fanboy at work. :) The iPhone is the best phone I've ever owned, hands down.

Vargo said...

Okay, here is the common -- no, *constant* issue I have with the XCode expression viewer that I was talking about. If you can tell me how to accomplish this intuitive task, I will gladly eat my words:

(Specifically, note the very intuitive expressions in the expression viewer that evaluate to "out of scope" despite most definitely being in scope.)

Jay Wright said...

Vargo, whats the scoop on the 'out of scope' bug? I'm having the same issue. Two NSDate pointers, declared identically, assigned side by side in method A, but in method B, one is out of scope, the other retains it's value. Is this a known issue?

Dalton Hamilton said...

Out of Scope
I'm having the same problem. I have multiple NSNumbers, all declared the same, @property the same, @synthesize the same and yet the last one is out of scope. I can't figure out why. I can't find a release anywhere and the code is small.
Has anyone figured this out? Please email me at below email if you have figured this out.
dalton (at) me (dot) com

Vargo said...

So hopefully this will help a bit for those familiar with Visual Studio. Unfortunately the XCode Expression Viewer is not anywhere near as powerful as the Visual Studio Watch window.

If you have someObject.someProperty, the intuitive expression you'd expect to add in the Expression Viewer is, well, "someObject.someProperty". Sadly the Apple development experience is that antithesis of the Apple user experience. Instead, you need to write the method call equivalent, i.e. [someObject someProperty] and on top of these you usually need to *cast* it to the type you want, e.g.:

(UIImage*)[someObject someProperty]

It should then, if the stars are aligned, be visible in the Expression Viewer. I really hope this helps.

Edwin said...

scrub m65 kamagra attorney lawyer body scrub field jacket lovegra marijuana attorney injury lawyer