I recently started coding Obj-C in XCode and was very surprised that it's far less polished than what you expect from an Apple experience. That is mostly because an Apple experience is consumer-facing and much more time goes into making that a better experience.<p>XCode feels like a GUI for GCC, which it is. It's a whole pile of flags that you can set, tweak, etc. If you don't have some GCC experience, this is a bit of a hurdle. Project settings sometimes break (especially around code-signing), so keep your text editor handy. When things break the error messages can be cryptic and there's usually no 'double-click to get to the error in the IDE'. Obj-C is obviously C, but it's also obviously not and also not syntactically similar to, say, C# or Java (or Ruby, JavaScript, Python, etc). I found the step to Obj-C to be fairly trivial, but I thank time spent with C, GCC and Makefiles for that.<p>After this it's mostly the same as anything else - which is diving into massive amounts of APIs and best-practices.<p>iphoneos-simulator is brilliant. Much, much better to work with than Android simulators (mostly because of the insanely faster startup time and the ability to change hardware on the fly). Another brilliant piece to find was Instruments, which is an Apple GUI for DTrace. Profiling and tracing execution on simulators and devices is a breeze.<p>I think memory management is a bit of a non-issue and I'm surprised that's even being brought up. That many programmers only know one language / IDE and judge everything else as inferior/bad/etc is a reasonable observation (if not a totally obvious one), but that's not going to change anytime soon.<p>TL;DR<p><pre><code> - XCode has warts
- Obj-C is different than Java/C#
- Errors can be a pain
- iphoneos-simulator is brilliant
- Instruments is fantastic
- Easy to pick up if you're familiar with GCC</code></pre>
I'm largely in agreement with Gruber insofar as development environments are largely a matter of taste.<p>On the other hand, I'm rather surprised that Gruber is looking to defend reference counting, especially in light of how well it went for legacy programming languages like VB Classic.<p>John Siracusa is by far the more well-reasoned Apple advocate in terms of programming language design and his Copland 2010 articles are definitely worth checking out if you want to read a cogent argument as to why Cocoa is NOT the way of the future. <a href="http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars" rel="nofollow">http://arstechnica.com/apple/news/2010/06/copland-2010-revis...</a>
Java might've had a lot of FOSS love put into, but the Android toolset...<p>Well, let's just say that I would be a very, very happy man if the Android emulator could run even 50% as fast as the iOS Simulator.
I can't agree here.<p>Yes, there are a lot of people who turn their nose up at the OS X/iOS development toolchain simply because it is unfamiliar. They see the square brackets and write it off immediately.<p>But the argument that the toolchain is not polished is dead on. If you look at the work Apple are doing under the hood with LLVM etc., then yes, they are doing some very smart things. But everything on top of that is pretty damn dismal. Xcode is incredibly buggy. iTunes Connect is hell. There is functionality that is just plain wrong. There are features that are inexplicably missing. Version control integration is so poor everybody I know uses external tools instead. Code-signing is held together with bits of string. Functional regressions from earlier versions mystify me. Xcode build configuration is so much of a hassle that it's easier to avoid it altogether by putting everything into xcconfigs. The code quality in the templates is awful.<p>If this kind of quality were foisted on end-users, there would be uproar. It's the opposite of Apple's "just works" philosophy. It seems the application-level dev tools team is where they stick all the students and new hires who don't know what they are doing.<p>I think the fundamental design of Objective C is a little old in places but has held up remarkably well over the years. Cocoa has a fantastic design. But christ, the development tools at the application level are a fucking embarrassment.
It's all about the unfamiliar. I've spend countless hours in Xcode, and firing up Eclipse is a nightmare. Same with switching from Xcode 3 to Xcode 4... the unfamiliar seems "wrong"<p>Until you get beyond the unfamiliarity, you're not qualified to judge if it's wrong or right.<p>(That said, the 2 hours I've spent in Visual Studio was remarkably pleasant, considering)
Focusing just on Xcode for a second, the spirit of the rant is not totally off the mark. The latest version 4, has been, <i>on the whole</i>, a step back. If you were used to Xcode 3, suddenly a lot of functionality is no longer there, or moved, or replaced, or hidden away in a deep recess. To make things worse, a lot of documentation is now hilariously out of date. For example, just about any Core Data guide/sample code/tutorial is not applicable to the brave new world of Xcode 4 (or iOS 4 or OS X 10.7). And there's no indication that any of them will be updated anytime soon -- I speak mostly of Apple's own docs.<p>In other words, there's a lot of pain, currently, surrounding the de facto tool for iOS development, even for seasoned Cocoa programmers. It's too bad the original story (the one Gruber's responding to) got so off track talking about other nonsense (reference counting?! Does that objectively really matter?) when there are so many real problems that actually exist with iOS development.<p>Thankfully, these problems aren't necessarily permanent -- just as long as Xcode 4 continues to get refined/fixed, and documentation is brought up-to-date (i.e. no more Core Data how-to videos that use Xcode 3 on OS X 10.4!).
I like the Cocoa API and can cope with a C-based language, but I'd have to agree that Visual Studio and Eclipse offer more IDE features for their respective environments.<p>Having said that, they all have pretty crappy editors.
> [...] when you fire up Apple’s Xcode and start building CocoaTouch applications in Objective-C you’re going to come face-to-face with a toolset that has not had the sort of love put into it that the open source community has put into the Java toolset and associate platforms, or that Microsoft has put into VS and .NET over the past 10 years<p>I think I'd have to agree with this statement. As someone who's recently started developing in Objective C and coming from a Java / Eclipse background, the toolset provided in Xcode seems to fall short of what Eclipse has to offer (I can't speak for Visual studio).<p>For instance I don't think Xcode does proper static analysis. I.e. it doesn't allow me to produce a proper class hierarchy for a class I'm using, nor can I run a command to see a call hierarchy on a method. And refactoring isn't 100% accurate either, and also very limited, i.e. I can't extract methods from a code fragment, and also once extracted, move that method into another class without issue (typical workflow for extracting helper methods).<p>It's not to say I can't do good work in Xcode. I just have to be aware of it's limitations and keep accurate documentation as I code, instead of relying on the IDE for a lot of the heavy lifting.
I agree with Gruber here, which may times I do not.
In this case the original article is way off base and he did a good job at pointing it out. In any case though, I don't look up to Gruber as some great technical expert as an engineer though.
GC is inevitable, but so is no GC. In the 80s people wanted to write software on platforms where GC was not practical. Having a GC when you have 640 K of ram is silly. So people used languages that didn't have GC. But then the platforms grew exponentionally, and people started wanting to do more complex things, and they say "all this manual memory management is crazy... lets use GC", just like the previous generation of computer scientists did before them.<p>Then the iPhone came out...<p>ARC isn't a revolution, it's just a stage in a cycle....<p>In 10 years your 20 core smartphone will have a GC running in it.
What is interesting to me is that I could replace "Objective-C" with "liberal" and "Java" with "conservative"; or "Eclipse" with "Democrat" and "Xcode" with "Republican" - and this article and all articles like it will fly just fine on CNN, Fox News, etc.<p>It is amazing how predictable humans are, and how far people will go to exploit that predictability:<p>1. Draw line in sand.
2. Throw rocks at both sides.
3. Profit.
> The enormousness of the developer base for Windows and Java is such that many developers feel that those environments are “normal”, and anything different is by nature inferior simply because it’s unfamiliar. They’re offended by Xcode/Cocoa/Objective-C, in some way, because they feel entitled to their familiar languages and tools.<p>Gah - I was with you through the article, maybe not agreeing with <i>everything</i> he said, but did he have to come off like such a jerk in the last sentence? You're painting with pretty broad strokes to call people who aren't very enamored w/ XCode "offended" and "entitled."