Wether you want it or not, Xcode 4 is around to stay when it comes to iOS development. I’ve been happily comfortable with Xcode 3 for quite a while, and my first impressions of Xcode 4 left me completely cold. However, support for Xcode 3 will soon go away, so I need to get ready for the inevitable transition. Maybe I was just having a bad day when I looked at Xcode 4 for the first day. Or maybe my nightmares finally came true and I’ll be forced to look for an alternative IDE. Which one is it? Read on to find out.To put all the whining and complaining that’s about to come in perspective, I want to build some character references first. I’ve been programming for 27 years, 13 of those professionally in the games industry, although the non-professional years I probably did just as much coding. I have used everything from emacs + make files to the gamut in IDEs: Turbo C++, Visual Studio, KDevelop, and Xcode 3 among others.
Contrary to popular belief, I’m not that picky when it comes to a development environment. Or at least, it doesn’t feel that way to me. I want the basics, that’s all. Doesn’t everybody want this?
- Have 2-3 source code windows opened side by side.
- Build and see the output.
- Do everything with keyboard shortcuts.
There are lots of other things I want (project configuration, debugging, run tests), but those are the ones I’m doing 99% of the time. I never had a problem doing any of those things with past development environments.
The hit list
Having more tools and options is great. I love having the option to do advanced operations on my code, but I want to decide when to use those tools, not being bombarded by them. That, in a single sentence, is why Xcode 4, out of the box, is completely unusable for me.
Attempting to do something as simple as type code and build it is extremely frustrating. Xcode will react to me doing that by flashing all sorts of stuff on screen, bring up sidebars with messages, change which source files are displayed, draw squiggles all over my code, and flash alerts overlays. All of that, while not showing me the build output.
Working on Xcode is an extremely noisy (visually) and distracting experience. I understand it’s trying help me, but it’s failing miserably at it. I’m trying to concentrate on what the code does, and I feel I have a parrot yelling stuff from my shoulder and flapping in front of the screen in some misguided attempt to help me code better.
That might work for some people, but not for me. I’m the guy who turns off “spell check as I type” everywhere because I don’t want to be taken out of flow while I’m typing (I’ll do a spell checking pass later on, thank you). I don’t have notifications on my mail or Twitter; I check them explicitly when I want to. Now take that kind of annoyances and multiply it times 10 and you start getting an idea of what working on Xcode 4 is like. Xcode 4 feels like it’s squarely designed for the texting/ADD generation.
Fortunately, most of it can be remedied and turned into a half-way sane environment.
Here’s how to tame the noise in Xcode 4:
- Autocomplete is one of the worst offenders. Turn it off! Good autocomplete is awesome, but I’d rather ask for it (with a keystroke) than have it bombard me constantly. Not just that, but it’s so badly implemented that it will a) put shadows on top of the text I’m typing b) replace the text I’m typing on the fly so I can’t even see what I typed (see screenshot below). Off with it!
-
Having the whole screen flash with squiggles on and off while I’m typing isn’t helping in any way. Xcode is trying to “highlight instances of selected symbol”, which is a really useful tool, but not while I’m typing/thinking! Not just that, but half the time it will add extra squiggles to the screen to make sure I can’t even read the symbols themselves. So off with that one too.
Here’s one very frustrating thing: When I turn off the option to automatically highlight instances of the selected symbol from the settings, I lose the ability to do that at all. Yes, you heard that right: I can’t (as far as I can tell) press a key and have the IDE highlight all the instances on demand. No sir, that’s not the way it was intended.
- Continuing with the theme of noise and distractions, having a sidebar popup and start showing me errors with my code as I’m typing is also definitely NOT helping. Fortunately we can turn off “Show live issues” in the general settings.
- One thing that Xcode 4 appeared to have gotten right is the idea of showing multiple source files at the same time. Now many IDEs do that by default these days, so that was a plus. Unfortunately, it’s part of the “smart” assistant. As a general rule, I end up turning off anything with the word “smart” in it, and this is no exception. The assistant tries to present “relevant” files to the one I’m working on. No, no, no, no! *I* want to decide what to display and what to work on. Just get out of the way and let me do that easily. You can turn off the view to “Manual”, which helps a huge amount.
Just those changes make Xcode 4 into something that at least I can type into and not get sick at my stomach. We’re making progress.
Now I can finally build and… everything goes wrong. Xcode doesn’t show me the build output and it decides to flash a “build completed” screen overlay in case I looked away in the two seconds it took to build. Seriously? Maybe my attention was drawn into some of the flashing squiggles and I forgot it was building.
Fortunately for my sanity, it’s possible to fix both those things. The alert is easy: Go to behaviors, “Build succeeds” and turn off “Show bezel alert” (make sure it’s off for all the others while you’re there).
The other one is a bit trickier, but it’s certainly possible. Set up the “Build starts” behavior to open a named tab and go to the current log. Like this:
Now when you build your project, you’ll get to see something sane like this. It might initially be as a tab, but you can drag that out and make it into a separate window of its own so it doesn’t obscure the source code window:
You should be able to navigate through any issues found during the build with Cmd + ‘, or, if you like the fancy issue display, press Cmd + 4. Things are so much better when you initiate them on demand rather than when they’re forced on you!
Finally, a couple minor UI annoyances that are easily fixed:
- The toolbar is positively huge. I feel crammed in the high-res 15″ MBP (1680 x 1050), so I can’t imagine how anyone works with something smaller. In any case, hiding the toolbar helps tremendously. As a bonus, the setting is per window, so your source code windows get the extra real estate, but the build output window keeps the toolbar so you have easy access to changing the target platform.
- Line wrap is on by default. Seriously? Off.
The suck list
If that was everything, I’d be happy. It means that even though Xcode 4 ships with retarded defaults, it can be whipped into shape into something usable. Unfortunately, there are a two major things I haven’t found a workaround for:
-
Can’t build a single file. Someone at Apple, in their infinite wisdom, decided that building a single file was obsolete with the awesome new feature of “show live features”. Except that “show live features” sucks and has to be turned off. Apparently you either take it their way, or the highway, because there isn’t an alternative. As with the case of highlighting symbol instances, there isn’t a command I can use to “show live features” on demand.
The alternative is doing a full build. Most of the time that’s fine, but whenever you’re doing one of those refactorings that breaks half the codebase, then you’re really screwed. The only way I can stay focused in a case like that is by cleaning up one file at the time, but this makes it impossible as you keep getting errors from all over the codebase. And as you fix one, the first error in the next build might be in a different file. Very annoying to say the least, especially because this was working and they removed it on purpose. I never file radar bugs (long story), but I made an exception just for this.
-
Build configurations and schemes. Did you notice that when you built the project earlier there was no option to choose debug vs. release or some other configuration? That’s another one of those decisions that make you wonder if Apple uses Xcode to manage their own projects (and if they do, what kind of developers or projects they have).
They turned something simple like project configurations that nobody ever complained about, into something byzantine worthy of some of the best efforts from Redmond. This gets the award for “most complicated feature nobody needed or wanted”. It seems now we have an extra layer of indirection. So you act on a scheme, which then decides which configuration to build and what to do. That’s why there are “Build for analysis” (debug), “Build for running” (release), “Build for testing” (WTF?), “Build for archiving” (distribution?).
After spending some time with it, I’m still confused how I would go about running the release configuration, or how to mass-edit all the schemes at once (every target seems to get a different scheme).
The whole schemes thing leaves me completely speechless, and that vein on the side of my forehead is pulsating just from thinking about it, so let’s just move on.
The good
After you take the time to fix Xcode 4 into something usable, and (somehow) put up with the new broken features, is there something to like?
I had to dig deep, but I found a couple of things that I like better than Xcode 3:
- Much better project settings UI: Multiple panes, showing multiple values for different configurations, etc. Way better than Xcode 3.
- Better semantic analysis. During the build process, Xcode 4 was able to correctly flag some problems in my code that Xcode 3 never warned me about. Mostly to do with constness of parent-scope variable when using blocks.
- Better keyboard shortcut support for opening files in different windows (assistant pressing the Option key). I never found a way to open a file in a specific window in Xcode 3 without having to use the mouse.
And that’s pretty much the whole good list that I was able to find 😐
Conclusion
Xcode has been progressively evolving from version 1 until version 3.2. I have no doubt that’s the reason for some of the quirks in the later versions. Xcode 4 seems to be a total re-design and re-implementation, and suffers from the classic second system effect. It’s change for the sake of change, most of the time scrapping useful features and not offering useful alternatives.
I’m sure I only scrapped the surface of the horrors of Xcode 4 in the day I spent with it. I didn’t look very closely at the debugger or the Interface Builder (saving those for another day). I keep hearing about developers with stability problems with Xcode, although I didn’t run into any crashes (but I hardly did any real work with it).
Overall, my recommendation is that, if you’re comfortably working on Xcode 3, stay as far as possible from Xcode 4. We’ll all be forced to move there sooner or later, but in the meanwhile you can continue being productive. Maybe by the time they discontinue Xcode 3, Xcode 4 will have improved a bit.
Thanks for the tips. I’m still strugging to do anything with Xcode4… its painful how different and difficult it is compared to Xcode3. I’m trying to get my head around it though. Sooner or later there won’t be a choice. (And sadly I’m betting on “sooner”. sigh.)
Great tips! you should consider changing the title of this article as “xcode4: my way or the highway” 🙂
I disagree with your recommendation to stick with Xcode 3. Most of the annoying things you mentioned are really minor issues.
Autocomplete: I’m mostly bothered by its function, not how its displayed. In that regard it’s not really different from Xcode 3 and has the same issues: in some cases it doesn’t show any symbols at all, or not the symbols it *should* show. And it doesn’t do smart selection: if I used to pick one particular autocompletion it will randomly suggest another completion the next time I’m trying to autocomplete the same.
Highlighting instances, live issues, compiling a single file, bezel alert … I don’t really see a problem there. It’s a setting that can be turned off, or tweaked, as you said. As for single file compilation you could try and add a macro for that. Personally, I rarely if ever need “single file compile” but I agree that it can be helpful in some cases.
Schemes — the most misunderstood change in Xcode development. If you “archive” a build it will build the release version. If you want to test the release build, you run that “archive” build. Rarely, if ever, will you run the release build AND want to attach the debugger. If you do need that you can always duplicate a scheme, and set the duplicate to build as release. Properly named you will have two schemes “MyProject (Debug)” and “MyProject (Release)”. It’s a bit of extra work, but since you only do this once for each project it’s really a minor issue.
So overall I wish you had spent 1 week instead of 1 day with Xcode doing actual work, then write a post like this. I’m a bit disappointed by this article because you have a lot of followers, and with your recommendation you’re adding unnecessary oil to the “Xcode 4 sucks” fire.
It doesn’t suck. Yes, it’s different. Yes, not all improvement are actual improvements but not everything that’s being said is really bad in day-to-day development.
Xcode 4, simply put, just takes a week to get used to, and you’ll never look back at Xcode 3. Sadly, most just look at Xcode 4 for a day, find one or two really annoying issues, and dismiss it as Apple’s biggest plunder, or something like that.
There are REAL improvements, personally I say that workspaces are the best and biggest improvement.
Now we can work with multiple projects in the same IDE, and work with static libraries in a way that doesn’t require a lot of caretaking and manual setup. The simple fact that you can easily modify what happens when you do a build (start, fail, succeed) is a HUGE step forward in the right direction of customizing the IDE. Not to mention the much better integration of source control, in particular git.
Steffen, I’m saying is that Xcode 4 is totally not set up for me (or anyone who thinks like me). The fact that it takes a week to get the hang of it, it’s a tipoff that there’s something very wrong. Especially when there’s nothing (for me) that I want. A week down for an indie working on apps is a *huge* drawback. If you’re just messing around with sample code, or it’s a hobby, then not so much. So I definitely stand by my comments.
Unfortunately it doesn’t matter so much, because in a matter of a week or two, we’ll be forced to upgrade as iOS 5 goes out of beta. That was the reason I decided to byte the bulliet and give it a try, but it ain’t pretty, that’s for sure.
I’m not sure I understand the workspace comment. With Xcode 3 I had no problem having multiple targets that generated static libs and were included in another target. Are you talking about including a whole other project inside a project instead of having separate targets?
Every new tool takes some time to get used to. I was able to work “normally” with Xcode 4 from day one. Just here and there you do have to get used to things that work differently than you were used to, but you pick that up over time. That’s the week I was referring to, it’s not downtime … more like switching from a standard keyboard to an ergonomic keyboard. I don’t think that week indicates that something’s wrong, in fact I tend to say it’s rather short given that Xcode 4 is a complete re-write. I’ve seen much, much worse “re-writes”. The latest MS Office UI springs (pun intended) to mind.
The workspace concept is sort of like a “meta project” that contains other projects. Compared with Visual Studio, workspaces are the equivalent of a VS “Solution” that is the container for multiple projects.
You could add projects to a project in Xcode 3 but it had problems of its own (don’t remember off hand but there was something really crucial that just wouldn’t work). Personally I switched to Xcode 4 mostly to try out workspaces and how they allowed me to setup my projects in a more modular way, without having to manage multiple Xcode projects at the same time – now it’s all in the same “window” (sort of).
I have been using XCode 4 for almost 3 months now and I shipped iBlast Moki 2 with it. I wouldn’t be so negative about it.
The first version was definitely unstable and buggy (4.0) and forced me to revert to 3.0, I upgraded back when the update 4.0.2 came out and since it’s a real pleasure to work with it.
Regarding the auto complete, I am not sure which version you are using, but in 4.2 this has been greatly improved. I have been a heavy user of visual assist with visual studio, and it’s almost as good except it’s integrated to XCode which is totally awesome.
Other great points:
– If you use LLVM2, you get in realtime the compilation error, without having to recompile the project which saves you time (not sure if that’s what you are complaining about with “show live issues”).
– The compilation is also faster, it does a better usage of the multicores.
Regarding the configuration and scheme, I found that weird too at the beginning and new as I don’t know any other IDE doing that, but I think I like it now. It simplifies things. Most of the time I always use the same configuration which is in debug, it’s only towards the end of the project that I switch to release. So removing that choice from the dropdown list helps keep the interface simple.
In the end, I am really happy to have make the jump quickly, the transition was definitely not easy, like every time you have to learn something new, but I gained in efficiency and it would be really hard for me to go back.
4.2 is definitely a lot better than the rest of the previous 4.x versions.
“I’m sure I only scrapped the surface of the horrors of Xcode 4 in the day I spent with it”
A day? Seriously? For the tool that you will probably end up using more than anything else, day in day out?
I really like your blog, but I was surprised how reactionary you sound when talking about XC4. There are many things that I found hard to get used to, but now I’ve come to the conclusion that it is far superior to XC3. I don’t believe that I’m suffering from Stockholm Syndrome, but you do have to spend time adjusting to some new ways of working, and you have to learn how to exploit the features that XC4 offers you. Visual clutter, for example, can actually be greatly reduced if you configure the behaviours to shut down panels by default.
Initially I struggled with the whole one-window thing (despite working on cross platform game code that required me to work in Visual Studio and Eclipse too), but rather than trying to find ways to get back to a multiple window interface I decided to go with the flow and try to use it the way that the designers intended. On the whole I now find it quite natural, and productive – it usually shows me what I need to see when I need to see it, and hides the rest.
There are still gripes, for sure, particularly with the Interface Builder integration, which doesn’t quite work the way it should – but basically, I feel like it’s a step forward.
Seriously – give it a week or a month. A day just isn’t nearly long enough to get over the “bah! someone’s tidied up and now I can’t find anything” stage.
Oh, and +1 to the comments about XC 4.2, it’s worth downloading the betas. Also, watch the XC related videos from WWDC 2011.
I don’t agree at all with your final recommendation. I’ve been coding with Xcode since the firsts versions of the program. Xcode has been improved in many ways in 4.x versions and I would not recommend at all to stay in the past 3.x
This is an interesting experience share. I’ve also tested XCode4 few times ago (http://pixelsnack.wordpress.com/2011/04/05/trying-xcode4/). And although its issues, personally I really prefer working on this version than staying on XCode 3 for reasons mentionned in the blog post.
Hi Noel,
While I have not used XCode 4 yet, I frankly haven’t really used XCode 3 much as it was just too painful. I come form a Video Games Background like you and seriously give me CodeWarrior over XCode. I like to code the way you do, and to this end I suggest you get a copy of Slick Edit for the Mac, its an X11 app so a bit fugly, and it can open and read a XCode project just fine. You need to use XCode to add new files to the project which is a small pain, but after the first 2months how many do you add? If you only have one project in the project file you can run and debug the first configuration but can not change to the others. Leading me to use it in a Visual Studio + SN Debugger / Visual Studio + CodeWarrior fashion. If you don’t know SlickEdit it is Visual Studio + Visual Assist X. The obj-c capabilities are low, the Symbol browser doesn’t work and the Auto Complete is very limited but the file open works better than XCodes. Its layout is Visual Studio .net era with panels than can be docked or show/hide on hover, and it has tabs for maximum code space. You can split widows vertically and horizontally and you can have multiple tab groups. I don’t know how to make it open certain files in certain tab groups, so some manual arranging is needed, its a minor gripe I have. You can also fully adjust the keyboard mapping and layout, so you can make ‘end’ key go to the end of the line not the page like it does in a Mac environment, and CTRL+TAB swtich tabs, CTRL+F4 close files etc. or what ever else you want. It has proper bookmarks with popping and script recorders as you would expect. It has kept me sane in iOS dev. It has a free trail, but its pricey at $300.
Wonder if you tried an alternative to Xcode — JetBrains AppCode (http://www.jetbrains.com/objc/index.html). Hear many guys liking it.
I have yet to take the plunge, mostly because I’m nearing the end of a development cycle and I’m sharing my code base with the guy who is doing my artwork. I set him up on xcode 3 and didn’t want to have to change that.
The comment thread has been useful – clearly xcode 4 is a matter of personal taste / preference. I guess I’ll just need to try it for myself.
Thanks Noel (and others) for the configuration tips.
I remember Visual Studio creating a similar divide with VS.NET, people using the new features & language preferred it while those already deep into a workflow with VS6.0 hated it.
It took Microsoft 3 years to get Visual Studio back to a state where I enjoyed working with it (Visual Studio 2005). Hopefully it won’t take Apple that long.
Exactly. I remember that, and I used to be *very* vocal against VS .NET (much to my co-workers chagrin, I’m sure). Fortunately they fixed most issues in the following version (and I hear they’ve been getting better since then). Here’s hoping that Xcode 5 is a step in the right direction.
Thanks for the tips! As for me, I’m using vim exclusively for all editing and Xcode only for running on the device or debugging. This way I don’t depend on any version of Xcode.
Interesting post, Noel! While I definitely see the substance of many of your complaints, and have complaints of my own, I just can’t agree with your overall position of sticking with Xcode 3. I’ve been using Xcode 4 to some extent ever since I first got access to one of the first versions available after WWDC 2010, and I was hooked from the start, even though those early pre-beta versions were HORRIBLE compared to what’s available today.
Here’s some of what I love:
– It finally integrates IB and code editing in a way that Obj-C developers have been wanting for decades.
– Code completion is finally, after all these years, quick and functional.
– The jumpbar! With that, I can actually navigate the entire project from one relatively small control, and often close the project navigator entirely, saving precious screen real estate.
– The scheme system isn’t a new abstraction on top of the other things, rather it’s a filter that lets you define the configuration combinations that make sense. The default scheme works for at least 95% of what most people probably need to do.
I could go on, but I’ll stop there. I wouldn’t recommend anyone to stick with Xcode 3 at this point, and the only reason I’d recommend any newcomers to start with Xcode 3 would be the relative lack of books etc that cover Xcode 4 (though that situation is changing).
One critical tip for anyone jumping into Xcode 4: Learn to use the keyboard shortcuts to show/hide the panels on the left and right sides. Hugely helpful now that they’ve stabilized (the keyboard assignments were shifting wildly during the beta period, which was extremely aggravating).
//jack
Try AppCode. Worth it for JetBrains’ transparent process and responsiveness alone (very refreshing after enduring Apple’s arrogant indifference on so many issues). It’s only in beta, and already far more functional than Xcode 4.
I’m using Xcode 4.1 and I have no problems. It’s clean, works fast and the autocompletion and all that stuff is useful, for me. I only needed 1 day to migrate my project from Xcode 3 to Xcode 4 and continue producing.
I’ve been using Unity + Xcode (4.0.2 – I should probably upgrade) for a month now. Previously I was a PC/console developer for seven years and before that a PC developer, like you. I’ve run the gamut with tools as well – CodeWarrior, that new IDE Nintendo developer and then scrapped (I forget the name), various SN Systems tools, Visual Studio from version 5 up to 2008, and going back further, various Borland products (Turbo Pascal since version 3, Borland C++, Borland C++ Builder for Windows), makefiles + gcc, MultiEdit for DOS (a kickass editor!).
I find Xcode 4 to be one of the worst. The schemes thing is awful. I frequently want to do a release build and debug it, but I guess I have to create a new scheme for it (I’ve been changing the default scheme from debug to release but that means bringing up the scheme editor). I’ve been spoilt by Visual Studio I guess. I think that was a really good editor (although it has steadily been going downhill – with every new release they add more useless UI features). It feels really clunky getting around the IDE. I don’t want to have to reach for my mouse, but that visual noise with windows/navigators popping up and taking over really forces me to.
Thanks for the tips – it makes it slightly more usable..
Why would you want to “do a release build and debug it”? More importantly, why would you want to do so frequently?
Release builds optimize the code, that makes single-stepping through the code as well as inspecting variable values pretty much useless due to code optimizations.
Besides, just make a copy of the scheme, suffix it with “release” and set the build configuration to release. This is one step you’ll have to do once, takes you 15 seconds and after that you’ll notice no difference to how Xcode 3 works anymore.
Thanks for the post Noel. Glad I am not suffering alone!
I found early version of xcode4 crashed like craaaazy. Disabling the features you listed helped a lot. Particularly ‘live issues’. 4.1 is much more stable as well.
I had a lot of issues debugging mixed C++/ObjC and I still find stepping through code to do very strange things every now and then. The execution pointer jumps all over the place and doesn’t follow the execution path I would expect. The debugger console never can determine ‘self’ or ‘this’ unless I am explicit. etc.
I have not found a single advocate/supporter of xcode4 who:
1) has used 2 or more other IDEs for a significant duration (Visual Studio, Borland, Codewarrior, …)
2) writes mixed language code (mixing C/C++ and large chunks of existing code. Not just compiling apple samples)
Even with the latest version implementing breaking changes to code is near-impossible. I am forced to remove files from the project or comment out massive blocks to avoid UI freezes. I want to hit compile, fix the first issue, repeat.
Meet me. 🙂
I have worked with Visual Studio from version 6 throughout version 2010 writing VB, C++ and C# code. I have worked with the MS C++ compiler versions 6 and 7 if I remember correctly.
I have worked with Xcode since version 3.0 and I’ve been writing C, C++, Objective-C and Objective-C++ code with it.
I have no severe quarrels with Xcode 4. I’m glad it exists because Xcode 3 is rather arcane compared to VS. Xcode 4 is still not there but it’s definitely an improvement.
Finally, I should mention that Xcode 3 is incompatible with Mac OS X 10.7 Lion according to Apple, and it can’t be used to build and deploy iOS 5 apps. So I guess the whole discussing will have become moot in a few weeks once everyone got over the “culture shock” and moved on.
Xcode 4 is different than Xcode 3. That’s just about it.
No, the discussion will NOT become moot. Â The topic of making poor design decisions (yes, Apple is guilty of this at times) will never go away, despite Xcode 3 being ushered off the stage.
thanks for the nice article. I love 4.2 too, also its more difficult then the earlier versions.
For what it’s worth, I think XCode 4 sucks a$$….. I use VIM daily at work as my editor, and Visual Studio with Integrated VIM shortcuts, and find it so painful to work in XCode 4 that I can’t express it enough…. Maybe your a convert by now, but I’m definitely not!
Finally someone who dares to tell the truth ! Thank you very much Noel.
I shipped two iOS Products with it and it’s definitely not ready for production: the app is too buggy, over engineered (schemes ?!), too CPU consuming and does not reach the usual Apple Quality Standards.
I think the overall UI is good, but it really need fixes.
Apple guys should know that: stop adding features nobody cares about, just “make it work”.
Thanks Noel, you are right on all points. Â We need more seasoned vets to speak up (I work with half dozen here in my office, none of whom are happy with Xcode 4 even after many months). Â I’ve found it’s mostly the younger developers who generally aren’t thinking deeply about their efforts (e.g. assuming there is no case for debugging a release build or presuming that by some magic “live issues” works universally, or don’t know/care about the internals or object models of what they are working with) who are indifferent or positive on Xcode 4. Â
I completely agree with you. I have a project that has four different targets. I wanted to add some of the artwork files into a second target that are currently only used in the first target. In XCode 3, you select the files, hit the “i” (info) button or press command-i which shows you the list of targets and the ones that contain the files in question are checked. You would check the box next to the target to add it to. Done.
In XCode 4, it is no longer this simple. You have to select the project, then select the target, then add things to/from the target. Why? The way it worked before in XCode 3 was SO MUCH BETTER!!!
And we get no freedom of choice. Want to put your iPhone app in the App Store? You have to use XCode 4. If Metrowerks had done this in the old days with CodeWarrior, we would have just stopped upgrading.
I’ve just spent the last day using Xcode again after being full-time in AppCode for a couple of months. Good grief, what a dreadful experience. It’s like coding in stone with a hammer and chisel. Apple have got the tech right in so many ways, but it feels like an application designed without user feedback. Who would want an IDE that refused to reuse files already open in a tab? Who would continue to use an IDE with such fragile syntax colouring? And what about the awful keyboard navigation. And can anyone bear to use the limited refactorings with those godawful ‘previews’?
The top-down, feedback-restricted process that has served Apple so well in the consumer space just doesn’t work for developer tools. Thank providence (or I should say JetBrains) that there is some competition at last.Â
I wish Apple would ask developers what they want and take feedback, instead of just handing us a giant new system, take-it-or-leave-it.
The whole ‘Schemes’ Â Xcode4 thing would never have gotten off the drawing board if users had any say.
Apple needs to get their heads out of their rectal orifices. XCode 4 is an abortion compared to Visual Studio, Objective c is a stone-age tool compared to even c++, much less Python or Ruby on Rails, and FEELS like it even if you don’t have much experience with Python and/or Ruby.
I’m trying to pick up iP programming, and at the moment I’m trying to simply type in a line of code from a development book. Autocomplete is insisting for no intelligent reason that I can see that either I enter a const (or other declarator) or enter a name in ALL CAPS.
All I am trying to do is type in the following line of code from the book —
NameEditorViewController *newController = [[NameEditorViewController alloc] initWithDefaultNib];
It simple WILL NOT allow me to type the “*newController” in ANYTHING but ALL CAPS. And it WANTS desperately to put “const” or “restrict” or “volatile” there, and is in a snit because I won’t do it.
I’ve NEVER had this kind of issue with the autocomplete in VS.
Only Apple could/would actually make a FASCIST text editor.
>:-/
Xcode 6.2, same stuff different day?
Does anyone seriously use the folding editor? Very twitchy, a narrow strip of tough to click control. Nice idea but the implementation needs a good looking at.
What I really like (not so much) are the hieroglyphics… yes, a purple “A” icon button thingy is suppose to mean something? Green “L” assume to be “Local” variable but a purple “A”? Well lets see, purple coffee means cocoa (not in my kitchen but ok). Purple A? What, “Cocoa Attribute? It is a bloody “Oâ€object, why not an “Oâ€? And oh yea, it should be **blue** because it is **my** object, not the Cocoa systems object.
And then there are the buttons that take you to a function with no apparent way to get back. Like the “Jenga†button at the bottom of the source code pane which is “Debug View Hierarchyâ€. Press that and your source code goes away, a one-way-trip-button. Still have not completely figured out how to undo that damage. Why can’t you press it again to go back? Better yet, let me get rid of that all together by configuring the hieroglyphics bar. No, even better, let me tear it off so I can have my debug controls float where I WANT them.
There needs to be a glossary of Xcode’s hieroglyphics (what the heck are those squiggles anyway?!?)
But it’s biggest falling is the way Xcode does its damnedest to jam you into a one-window-internet-browser metaphor, very much like Windows 3.2 (better known as “Microsoft Window” no “s”). Extra key presses, extra settings, and any matter of extra actions gets you into a multiple window envelopment but just using Xcode scrambles the workspace far too often and the. Would it really be that hard to have a debug variable window and the ability to double click on a variable and have it display in it’s own window? Would it be too much to ask to be able to turn off the file browsing effect or make it the extra step instead of the norm?
The irony is that Xcode is the exact opposite of an object oriented tool. It still uses the old “file” style editing instead of being able to select a class / struct / function / method and have that as an atomic editable element instead of the entire file where that class / struct / function / method resides.
This sort of advance object oriented editing system with a graphical interactive class tree structure for navigation of very large source bases did exist in the good old days “ObjectMaster” from ACI.
Back to thumb-wrestling with Xcode…