XCode Sucks And Here's Why
devcodehack.com
devcodehack.com
If you don't like conditionally coding around deprecated methods, just support new iOS versions. If you want to support older version, you have to live with it. That's not an iOS issue: Android is in the same boat. So, in fact, are most operating systems. New versions bring you new features. It's up to you to decide whether the trade-off of being visible only to users running the latest version is worth it.
I could get behind a lot of the points being made, but that one just came off as a bit of a whine. It reads as if the author hasn't really looked at other platforms: the grass really isn't much greener. XCode as an IDE can be very frustrating. I agree it's very buggy. But complaining about the speed of the iOS simulator? Has the author even used the Android Emulator? If he reckons the iOS simulator has 'tremendous lag' then I have no idea what words could be used to describe the Android emulator...
I have used the Android emulator and done work on Android. It is quite fragmented as well. But I am working right next to another mobile developer for the last 2 months, he is on Android and I am on IOS and he hasn't felt as much pain with the emulator or supporting different Android versions. Then again, maybe he's just smarter than me.
I have had some problems when the debugger was connecting to the Simulator, but most of the times it was because of other things which were installed in my system.
I know that Xcode4 used to be shitty and slow and used to crash. But Apple has come a long way from what they started.
Even though Xcode4 is a little painful to use on a small screen, still it is far better than Xcode 3.
Android, on the hand has different screen resolutions, different specifications and that alone is a pain. I have not even started with the OS fragmentation yet.
Many others have already answered the problems you were having with iOS4 and iOS5 backward compatibility. I think, you should spend a little more time with Xcode before making a judgement call.
Version 4.3.0 was the biggest piece of crap and crashed all the time. The current version, 4.3.2, is stable. I've not had a single crash since it hit. And I use it 10+ hours a day.
The project file stuff isn't so bad -- don't edit the file yourself and drag stuff in. Need to move something in the project but want to keep the layout the same as on disk? Remove it from the project, move it on disk, then add it to the project again. Does it suck for version control? Hell yes it does. It's terrible in that regard.
No simulator related issues here but I've seen it fail to launch on the device b/c of some stuck process. A reboot usually fixes this but it's very rare on 4.3.2. Major pain when it happens, though.
Storyboards are an iOS 4 only feature. ARC works on iOS 4. And iOS adoption rate is very good relative to other mobile OSes. Not sure what your beef is. Backward compatibility is pretty much always ugly. Especially if you use static libs and want to go back to iOS 4.0. But you really should weigh the cost of supporting OS versions that old against your development costs and your user base. You may not need to, based on your situation.
You're making IBOutlets way too hard on yourself. Use the two up view with IB on the left and your header on the right. Ctrl + drag from your control to your header and let go. Give the outlet a name and Xcode declares the property, synthesizes it, and sets it to nil in viewDidUnload. You can do the same thing for events (right click the control and drag from the event in the context menu to your header).
Eclipse is fine but it's hardly the best IDE. Its refactoring features are nothing short of amazing but it's dog slow on modern hardware. All of its preference/settings dialogs are convoluted at best. Finding things you want to change is usually a matter of digging through trees. No fun.
As you stated the latest build has been rock solid and I've honestly never had an issue with the simulator (at least in terms of connecting/running, it not noticing new resource files is another story).
The point about iOS 4/5 is very puzzling to me, pick a minimum version and program for it.
I do have one additional point: Xcode's code completion abilities are underwhelming. Emacs does a better job with hippie-expand IMHO.
For code completion I do not know how Xcode compares to the much hailed Visual Studio (I have no experience with it) but compared to Emacs + Slime + Common Lisp it is awful.
True AST based code completion aware of all of your constructs without hacks and kludges like ctags and the like...
In my fairly large project, I've had:
- Indexing taking hours, then not finding anything
- XCode using up 300% CPU for no apparent reason
- Build process randomly decides not to copy new files over to the device or simulator
- Simulator and device connections randomly decide to break
- Build process fails, reason why not stated in build results
- Project sometimes opens with no toolbar, multiple windows
- Fatal crashes
If Apple got around to fixing these issues it'd be a pretty good IDE.
Some things the OP says that I don't really get:
* Crashes: not many, except like I said, sometimes when I switch git branches. But for the most part, it works for me. I use XCode on 2 different machines (home and work) and it pretty much works without issue. Maybe I'm lucky..?
* Managing the project files. Yah, I had to learn this one on my own. For the past few years I've started out with creating the XCode project first. Then I go into finder and start creating my own directory structure for things like resources/assets, libraries, etc. Then I drag these folders into the project so I can maintain the disk structure. When creating new controllers with xibs, I have to manually move the xibs out of the Classes dir (this is lame, for sure), into my resources dir, and then re-add to the project. This definitely is not ideal, but I know how this stuff works now and it's not hard for me to maintain.
* Simulator lag and weirdness: I don't really see this either. There's been a few times where I've had to restart xcode, but overall, I don't really see many simulator problems. Again, lucky maybe?
* iOS 4 vs. 5: yah, this is a little suck. My current project decided to use a baseline of 4.3, so no Stories, but we did get ARC. There's been a few minor things like presenting modal views which were different in 5, but I just created a category on UIViewController that gave me a simple isIOS5 selector and that made things fairly easy and clean.
* IBOutlet: After doing things the 'hard way' (coding up ui in the 3.x days), I switched over to IB for everything. I don't mind IBOutlet or IBAction at all. I think they're great. It would be nice to have everything automagically connected up when you drop the control like the OP says, but I don't see this as a big waste of time.
I'm not trying to defend XCode per say, but I guess I've been spared a lot of the horrors that others have experienced. This is good for me because I have zero tolerance for that kind of stuff and if it did happen to me, I'd prob write a blog post just like the OP did.
I do think Apple has a lot of work to do, particularly in speed and the annoying bug that loses code coloring and code completion. If the latter happens to you, here's how you can 'fix' it (this I do have to do multiple times during the day): * Open up organizer * Click the projects tab * Select your project * Where it says Derived Data, click the delete data button
This will clear out all the index and give you back your coloring and code completion.
XCode is awful. XCode 3 rarely crashed on me, but the latest version crash a few times an hour on me.
Of course, all of my experiences with Apple software leave me unimpressed anyway.
Microsofts IDE (the .net one from six years ago) had awesome debugging tools.
The Leaks inspector is also way off sometimes. I spent a couple of hours hunting for a leak that was nowhere near what it was pointing to.
I could rant and rave just as much as the OP. I'll save everyone from that with one exception. I find myself dreading Xcode upgrades because of some new thing Apple will break.
For example, I remember working somewhat contentedly in whatever version supported iOS 4 only. Then iOS 5 came out with Xcode 4.1 (?) and then Xcode stopped printing the stack trace on a crash!
I find it appalling that they even shipped a version with that issue. They MUST have known about it. I don't even know if it's fixed; I found a workaround and stuck with it.
Environments that are rich with implicit metadata have synergy with IDEs. Environments full of repetition, gnarly API headers, #ifdefs and #defines don't.
---
In other words, Xcode is technologically fighting an uphill battle. Fortunately people are still skilled enough to produce great OS X and iOS apps with it.
The problem is solvable; it's just that making a decent developer product is not a priority at Apple. Provisioning is another example of terrible UI. And then there's their crappy command line/scripting support (for integration into a CI server), and their horrible developer portal web interface. The entire developer UI and usability experience is downright embarrassing. And to cap it off you have the typical Apple unhelpful or misleading error messages, including the most common and my personal favorite "An unknown error has occurred".
Ugh... my blood is boiling already, and I still have another 10 hours today with this shitty tool to look forward to...
Newer dynamic languages have actually WORST IDE support than Obj-C. IDEs for dynamic languages for example (Ruby, Python, Lua, ...) suck, and are left in various stages of incompleteness. Even IDEs for JVM based languages (Scala, Groovy, etc) are not that good (mostly some basic IDE capabilities built on top of Eclipse core engine).
>Environments that are rich with implicit metadata have synergy with IDEs. Environments full of repetition, gnarly API headers, #ifdefs and #defines don't.
Objective-C by it's design keeps a lot of metadata, especially since XCode 4+ has the full LLVM and AST of the whole project at it's disposal to check for types, inheritance, messages, variables, autocompletion et al.
>In other words, Xcode is technologically fighting an uphill battle.
In other words, no.
Why don't you consider the need for LLVM+clang and the subsequent huge amount of work indicative of an uphill battle to retrofit the IDE?
>Why don't you consider the need for LLVM+clang and the subsequent huge amount of work indicative of an uphill battle to retrofit the IDE?
Well, I'm not sure about the "huge amount of work". We just saw some release from Apple and that was it, we had XCode 4. Shouldn't have taken that much, more like 2 years or something for everything, considering that was around the time Apple started using LLVM.
They did retrofit it, but only because they had a more basic IDE before. Not because something in the language particularly prevented it.
It took the Eclipse project a few years to build their first version of the IDE too.
I contrast the general situation with something like C# which is on record as being designed from scratch to have synergy with Visual Studio, not the other way round. This general quality shines through while developing with it.
For example, the wonderful LINQ language feature: Statically typed declarative operations on any data. You write these 'reversed' compared to SQL and in return that means each stage can be fully auto-completed.
Back in Obj-C land AKA Jurassic Park, code's full of things like 'IBAction' and 'IBOutlet' which are C macros #defined to void or whatever, just to help the tools out.
But, like I said, Apple ecosystem developers still manage to produce good results. All things considered, OS X / iOS are the best platforms from a user perspective, IMO :)
It's an awful feeling to always be afraid to change anything in the project outside of the source code. Did you both add a new file? Too bad; conflict!
> 2. It manages the project files and their hierarchy using a […] flat file (pbxproj). […]
The disparity of what the Finder sees vs what is set up in Xcode is the least of the problems with this setup. Have you ever tried to merge an Xcode project file? I've gotten to the point where I can open it in TextMate and do the merge manually pretty quickly. It's just stupid that I have to resort to that.
Opens FileMerge.
Then just keep tapping the down/left/right keys to choose changes.
Another thing we've done to keep the insanity down is break our monolithic project into a few library projects to keep the project file merge damage to a minimum.
The trick is to set your workspace to assistant mode (the split screen that usually has the interface on the right and the implementation on the left -- the button with the tux). Then select your .xib file in the project navigator.
The "Counterparts" navigation menu at the top of the right pane should have header files for all of the custom objects instantiated in the nib. Just choose the one you want to add an outlet/action to, and right-drag from the object you want to connect as an outlet (or have trigger an action) over to the interface file.
It will prompt you whether to add an outlet or action (if applicable) and for a name of the outlet or action. It will add the property, synthesize it, add it to dealloc (if you're not using ARC) and free it viewDidUnload (if it's a view controller subclass).
I remember in MS Visual J++ you could double click on a UI element and it would create the event signature in the code behind class. I always likes that feature because I felt it was the best way to represent the link between the action and the code. Another good one was in the days of VRML. SGI had a development environment called CosmoWorlds and VRML had the concept of routes, in the hierarchy of the scene you could click on an object and add a scripted behavior, in which certain function signatures became the API, these function signatures would form little inward and outward triangles in the UI which would could then route via the UI from one behavior to the next. Anyway my point was, I agree with the whole linking of the UI in xCode it is not intuitive, there are far better metaphors out there.
I am also in agreement with the file system issues, adding files in the wrong way can be a mess to clean up, especially if the project is under source control. xCode in a lot of ways feels like it is constrained by the age of the IDE dating back to the NeXT era.
I think money isn't really the issue here. Just as throwing people at a late project won't make it finish in time throwing money at a crappy product doesn't make it better either.
('crappy' would also be a bit too harsh, XCode 4.3.2 is much more stable compared to a few iterations before).
I'm working with AppKit. I would give a limb to have it be half as nice as the first release of UIKit.
Appkit with XCode 4 is the worst software development toolset I've ever had the pain of working with. I'd rather be using VB or Gtk. :(
I would have chosen this on the top of the list!
5) IOS4 vs IOS5. Come on Apple, I am begging you to not
turn IOS into the next Internet Explorer.
I really can't fault Apple for this approach.
BTW, we rely on Flurry data to judge what the economic cost of choosing a new iOS target.
Reminds me of when I had to use Visual Studio for an extended period of time. I started off hating it, then eventually figured out how it wanted to play, and ended up liking it.
I wonder if authors of these types of articles come back to them a year later and think, "Gee, I sound foolish." Because that's how they sound to me now.
A lot of the other complaints could be specific to just how bad the actual code of the project actually is. I use XCode everyday and I only have to force quit it every few times a week, but that's because of shitty code, not the actual tool itself.
Also, nowhere in the article do you say what version of XCode you're running. As with any software, some versions are better than others, and they even fix some bugs too!
This article is nothing but useless XCode-hating. I can make a list of 20 things I don't like about XCode that would actually be valid issues with the tool, and none of the issues in this article would be on it. The things I don't like about XCode are how they dropped a lot of useful features between XCode 3 and 4, UI/usability issues introduced when everything had to be docked into a single Window, pretty lousy basic editing functions (where the f*k is 'find and replace in selection' and why do I have to use the stupid mouse so much when editing).
There's lots of things XCode can improve on. That said, if you look at how much the tool does do, and how well it does those things, my net conclusion is that it is still a great IDE, one of the better IDE's around, even despite all its flaws. Let's not all pretend Eclipse or Netbeans are so great and have absolutely no downsides, because IMO they are not even close to XCode in many ways. Visual Studio used to be very nice, it's been a while ago since I used it, but I can remember it was top quality.
I can understand that they left it out of the initial developer previews and even the first release. But come on, it's been years now.
Seriously though.. XCode does suck. It's a miracle anyone has been able to write an iOS app, let alone over 500,000.. /sarcasm
As an aside, I've never found an IDE that was great. I've found great editors (Submlime2, TextMate, VIM) but never a great IDE.
Microsofts .NET IDE wasn't bad (it's been six years since I've touched a Microsoft technology) so I may not remember the rage like I should (like child birth).
5) IOS4 vs IOS5. Come on Apple, I am begging you to not
turn IOS into the next Internet Explorer.
I used iOS 4.2 on a 3G for a long time; it was an awful experience. iOS 5 isn't supported on that hardware for a reason.