XCode Sucks And Here's Why(devcodehack.com)
devcodehack.com
XCode Sucks And Here's Why
http://devcodehack.com/xcode-sucks-and-heres-why/
24 comments
You're right about IOS4/5, that was an oversight on my part. I guess I lumped them together because when I am battling the IOS4/5 incompatibilities, I am doing it in XCode. But you are absolutely right the two are separate.
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 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.
Please upgrade to Xcode 4.3.2 - Apple released an update to fix the bugs 4.3 and 4.3.1 had. It is much more stable than before.
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.
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.
Interestingly I have encountered ALL of the bugs from that article. However I don't mind Xcode that much, when I start to get frustrated with it I remember that It could be worse, it's not like Androids tools are much better, last time I used Android the emulator was unbearably slow.
The new 2.3.3 x86 images for the emulator are actually really good. Definitely give them a try if you have to do any Android dev.
Xcode sucks in some ways but I think you're missing a few things.
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.
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.
When I started working with Xcode last November I was planning to jot down every one of my frustrations and make a blog post just like the OP did. However, I decided against it... must be old age sneaking up on me.
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.
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.
For C++ and Objective-C XCode absolutely smokes Emacs with regards to code completion.
True AST based code completion aware of all of your constructs without hacks and kludges like ctags and the like...
True AST based code completion aware of all of your constructs without hacks and kludges like ctags and the like...
Your experience mirrors my own exactly. In fact the only point I agreed with the author was on the project file.
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.
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.
My butt... Xcode 4.3.2 is NOT stable. It repeatedly crashes when a 5.1 device is connected, especially if you try to open the organizer window. 4.3.1 does not eventhough it does not have the 5.1 SDKs. I've seen this on 3 different (and current) Macs in the past few days, so it isn't a unique situation.
Agreed, I also love the fact that XCode is project-based and Eclipse makes it difficult to switch between working on different projects - I've always felt like there must be some trick to that which I just can't figure out.
It sounds like what you want are Eclipse's workspaces. Try this help page: http://help.eclipse.org/helios/topic/org.eclipse.platform.do...
That doesn't help. Switching workspaces is cumbersome, you can't 'launch' a workspace like you can just open an xcode project, and you can't have more than one open at a time in different windows.
Thanks for the tip to ctrl+drag the control to my header. That is great. I owe you many minutes of my life.
In my experience XCode 4.x has consistently failed miserably, even a fresh install of the latest 4.3.2.
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.
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.
Hmmm, I haven't had a lot of issues with 4.x. Some crashes for sure, but this usually entails when I switch git branches and XCode tries to reload the project.
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.
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.
No mention of the fact that the debugger's inspection abilities are awful (when they do anything at all)?
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.
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.
Yup, I forgot to mention that but the debugger stinks and the stack traces provided out of the box are completely worthless. You have to add some exception handling in your app delegate to get even a remotely decent stack trace, and it's still not that great.
I've never had problem with the inspector but I have to agree the stack trace is HORRIBLE. Almost unusable.
Microsofts IDE (the .net one from six years ago) had awesome debugging tools.
Microsofts IDE (the .net one from six years ago) had awesome debugging tools.
Definitely agree. Even VS 6 had much better debugging. As you said, the stack trace is useless in XCode 4.x
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.
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.
In the breakpoints section in the left sidebar click the little plus button at the bottom then place a breakpoint on all exceptions. Works for me every time but ymmv.
[deleted]
Now I see I'm not alone. I feel a little better because of that.
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.
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.
XCode 4 is really a terrible, terrible IDE. The $99 I spent on an AppCode license was the best $99 I've spent in a long time. Now when Interface Builder crashes, as it still often does even in 4.3.2, I just smile. When I occasionally go back to do a quick edit in XCode I'm amazed that I put up with such a limited and frustrating tool for so long.
Beyond bugs and crashes, it seems to me that Xcode sucks because it's primarily built for a rather archaic language (Obj-C), thus the value added by the IDE is "scrappy" rather than uniform and natural.
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.
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.
Microsoft hasn't had any problems with their development tools that support rather archaic languages.
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...
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...
I used VS up to VS2008 and didn't find it for C++ particularly good either. The IntelliSense didn't work half the time and, apart from the debugger, about the only thing I used was Go-To-Definition/Declaration. The C# context was enormously more helpful and reliable.
>Beyond bugs and crashes, it seems to me that Xcode sucks because it's primarily built for a rather archaic language (Obj-C), thus the value added by the IDE is "scrappy" rather than uniform and natural.
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.
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.
I don't disagree about those dynamic languages. I wouldn't even try to use an IDE for them. BTW, Go has nothing to do with the JVM.
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?
Re: Go, yes, meant to write: Groovy!
>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.
>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.
Well, LLVM+clang first needed to be built up to be suitable for such an integration (on and off Apple's dime).
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 :)
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 :)
My biggest issue is merging the project.pbxproj file every time someone on my team commits. Merging never works and we have to manually edit the XML.
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!
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!
I had this same problem too. With my team, whenever someone needs to edit the project file, we shout it out. 'Changing project file!'. They make their changes and push. Everyone then pulls the new file and go on their merry way. It's a bit of a pain, but it works and we rarely have conflicts now.
Regarding the "control drag to set an IBOutlet" stuff, I'll admit that it took me a while to understand what that was even doing. I'd be interested if anyone has any alternative ideas on how to do this - how do you specify the object on which the outlet should be created (e.g. the file's owner, the view controller, any other object in the nib, etc)?
> 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.
> 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.
> how do you specify the object on which the outlet should be created?
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).
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).
$ git mergetool
Opens FileMerge.
Then just keep tapping the down/left/right keys to choose changes.
Opens FileMerge.
Then just keep tapping the down/left/right keys to choose changes.
This works in theory. Once you start getting into complex projects, it quickly breaks down. Merge tools don't properly understand that, even though the closing tag (e.g. "};" in a project file or an XML node in a storyboard file) is the same, it doesn't mean that the contents are the same. You quickly end up with a corrupted file because it leaves off the closing tag on one of the two.
Give p4merge a try. We have a huge codebase, and I've found that p4merge, though not perfect, tends to do better than the default.
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.
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.
At the very best, adding a UI element should somehow automatically build out the declaration in the interface, synthesize it and do whatever the hell that blue line connector does.
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 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.
The impression I get is that Apple doesn't really care about developers (and I say this as someone who's been doing Cocoa/Obj-C development for ~10 years). Really, there's no excuse for a company that awash in cash to ship shoddy tools.
> Really, there's no excuse for a company that awash in cash to ship shoddy tools.
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 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 have done development on Apple systems since the old OS7 and in my experience it has always been a pain. Back then they did not have an IDE nor did they provide a compiler if you wanted to develop for Mac you had to pick up Code Warrior. It was a mess to say the least.
Can't speak for 2,3 and 4, as I'm doing OS X dev and it's been some time since I've done iOS. I agree with 1,2 and 6 wholeheartedly.
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'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. :(
> Connecting UI elements to their IBOutlet is the most annoying thing I have ever done in an IDE. <
I would have chosen this on the top of the list!
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.
I spend 8 hours a day in Xcode and absolutely love it. It has its rough edges - which you eventually learn how to circumvent - but most of these complaints seem to be misunderstanding more than issues with the IDE.
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.
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.
#6 is moot, viewController does that for you.
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!
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!
I never have to force-quit XCode, no matter how shitty my code is. If my code hangs, a Command-'.' kills it and I can continue working, even if I'm debugging multithreaded code that hangs somewhere outside the event loop while the main thread is waiting for it to post a semaphore.
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.
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.
And still no IB plugins in Xcode4 after everyone became reliant on them in Xcode3 (i.e. anyone using BWToolkit which it seems is everyone building a Mac app).
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.
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.
That's why I just use VI. Ever since Nibs became XML there's no reason to ever use XCode anymore.
Seriously though.. XCode does suck. It's a miracle anyone has been able to write an iOS app, let alone over 500,000.. /sarcasm
Seriously though.. XCode does suck. It's a miracle anyone has been able to write an iOS app, let alone over 500,000.. /sarcasm
#6:
1. Add UI element to your view.
2. Ctrl-drag from element in view to the @interface section of your view controller .h file. This will add @property and will also add @synthesize in .m
I never run into #'s 3,4. With 6, why god why are you doing it the long way? Control+clikc+drag to your header file. It will generate the property, and synthesize it for you automatically.
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).
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).
15 years or more behind other similar products in terms of features, XCode 4.3 is the throwback IDE from yesteryear.
XCode 4.3.1 crash on my mac every day, that will drive me crazy. At that time ,I always remember the Xcode 3 era with nostalgia.
5) IOS4 vs IOS5. Come on Apple, I am begging you to not
turn IOS into the next Internet Explorer.
> They've guaranteed this by refusing to support iOS 5 on older devices like iPhone 3 and iPod Touch 3.
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.
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.
The experience of iOS 5 on iPhone 4 is pretty shitty so say the least until I figured out the culprit is iCloud. Some symptoms with iCloud enabled, include but not limited to, random screen freezes, random login freezes, and application switching freezes. Just lots of freezes thanks to iCloud
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...