In Xcode, projects organize files and resources used to build a software product. Read this article to learn how Xcode handles projects and how best to work with them. Other recently posted dev articles include “Introduction to AGL Programming Guide“, “Introduction to Bonjour“, “Writing PCI Drivers“.
Understanding Xcode Projects; Other OSX Dev Articles
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
1) Fire everyone who has ever been involved with the Xcode project – everyone, even employees who just happen to be sitting near the Xcode team just to be safe.
2) Appologize to Apple dev community
3) Annouce Eclipse as the new OS X dev tool
4) Setup IB integration for Eclipse
5) Start contributing to CDT big time – including first class Obj C support
That was brilliant!
And unfortunately, there’s so much truth in it. I have seriously evaluated using Eclipse for Carbon and Cocoa projects exactly because Xcode was such a horrible experience.
someone’s not a fan! Still, in many areas, XCode outshines Eclipse on OS X. Eclipse has a long way to go in integration w/ the OS, keeping parity with the features Apple integrates into the OS, and … speed. You may say, well, if Apple had put all these features into Eclipse, then we would have the best of both worlds. Instead, we’d probably see an ugly mishmash of code as Apple tries to twist Eclipse into the ideal of whoever happens to be managing the project. Maybe we’d see a fork, enraging the Eclipse community, and whoever else associates themselves with Eclipse solely by virtue of the fact that Eclipse is open source.
This is thebackwash posting, by the way.
Yes thats a fantasic idea
Lets dump Xcode and use a JAVA IDE for Objective-C/Cocoa Development – I mean who the heck needs Universal Binaries were only transitioning to intel here in a while.
Furthermore lets go back to the craptacular WindowsIDE-like style of development we’ve all been trying to get away from in favor of something that actually works well.
I mean wow you must be like the smartest person alive on Earth or a Windows troll. WOW!
“Lets dump Xcode and use a JAVA IDE for Objective-C/Cocoa Development – I mean who the heck needs Universal Binaries were only transitioning to intel here in a while. ”
Uh…
“”Lets dump Xcode and use a JAVA IDE for Objective-C/Cocoa Development – I mean who the heck needs Universal Binaries were only transitioning to intel here in a while.”
You don’t need Xcode to create Universal Binaries. Gcc and make are sufficient, and Eclipse supports them.
Okay, stay calm, do exactly as I say, and you will not be harmed.
Now, place the crack pipe on the ground at your feet and slowly step away. Do it now.
You have no idea what you’re talking about. I have yet to see any other IDE match the ease of use and integration that Xcode has. It’s completely object-oriented nature allows you to develop Objective C apps in a snap. Hell, I don’t even have to write a line of code to get a basic app going.
And creating UIs? Does Eclipse allow me to design UIs entirely with drag-and-drop that meet Apple’s HIG? Is it smart enough to snap various elements to extension lines/borders so that you don’t end up with the fugly UIs that I see from most Java apps?
Go take your JIT-compiled ass and tell someone who cares.
XCode is good for developing Objective-C apps – pretty much the same way Visual Studio is good for MFC and ATL. It doesn’t mean that both aren’t awkward, unstable, crappy development environments, they just have a lot of specialized automation for specific tasks.
I do have to applaud Apple for giving away usable development tools: brilliant move, will gain them a lot more than charging $495 for MPW did. On the other hand, it had to have helped ruin CW, leaving no commercial, professional quality tools for those who need them.
My quibble is #4 (IB integration.) I really can’t find anything good to say about IB: it’s simply the worst UI tool I’ve ever used (well, neck and neck with Visual Studio, but I can edit .rc files directly when that abomination refuses to play; with IB, I’ve had to completely recreate way too many .nib files that suddenly wouldn’t open or load correctly any more.)
Powerplant Constructor (overall about the best UI tool I’ve used) is supposedly going to be open sourced next month. If I was going to do a lot of Cocoa, I’d think long and hard about adapting that to GnuStep’s resource system and modifying Cocoa to ditch Apple’s buggy, closed format .nib files entirely.
i like the smell of cum ear wax and ringworm rash an some times i like to mix all 3 toghter to form the ulitmate smelll emmmmmmm it smellls so good
I want the year I wasted with Xcode back Apple…
XCode is garbage.
I recently switched to OS X from Windows. Mostly, I’ve been pretty happy with the switch.
However…
I have been *very* disappointed with XCode.
XCode, in its current state, seems capable only of working well with a limited variety of project types. For example, XCode seems capable of handling the job of managing a Cocoa project. But it seems to be almost completely incapable of managing a Makefile-based project such as Apache httpd.
In particular, when working with the httpd project, XCode seems incapable of correctly communicating breakpoints and the location of httpd source files to gdb during a debugging session. I know that the problem isn’t gdb’s as when I use gdb from the command line, all goes well.
In another particular, when working with the httpd project, XCode’s source editor only recognizes #include <…> and doesn’t recognize #include “…” in the httpd files as being references to header files that should be listed in the upper right hand corner of the editor. This is very annoying as the coolest feature of the editor is its ability to jump to symbols and header files. Yet this feature is lost when it is most needed since the editor doesn’t recognize the #include “…” of httpd header files.
I believed at first that I was the source of the problems, not XCode. To try to figure out what I might have been doing wrong, I created a small Makefile project that consisted only of a project directory, a main.c file, and a Makefile. When I attempted to debug that simple project, I got the same failures as when I attempted to debug the complex httpd project. After considering every possible (I think) source of user error, I concluded that the problem lies with XCode, not me.
With regard to a previous poster’s comment about Eclipse being a good alternative to XCode, I would have to respectfully disagree. First of all, after failing to get XCode to debug httpd, I attempted to do the same with Eclipse and got the very same failures.
Secondly, although Eclipse is indeed a nicely architected piece of code, it does not offer (yet) a GUI designer.
Although it pains me to say this, if Apple were going to choose a Java-based IDE, I would prefer that they choose Netbeans. Version 5 (now at beta 1) has a lot of pre-integrated features (e.g. webserver) that Eclipse lacks and has a GUI designer that provides excellent assistance when positioning controls on design surfaces. And Netbeans seems to look and feel better on OS X than does Eclipse.
At any rate, I would prefer that Apple not default to either of the Java IDEs and would prefer instead that Apple put a *lot* more effort into making XCode into an IDE that may be used for managing (and creating) Makefile-based *UNIX* projects. Like it or not, many of us switched to OS X (instead of Linux) because OS X is desktop UNIX that actually works. And many of us want to be able to work with open source projects. And many of those open source projects are autoconf/automake based (for example, version 2 of the Apache httpd project that is part of the OS X “distribution”).
At this point, given my frustratingly poor experiences with XCode, I would have to say that I would strongly prefer to be using KDevelop over XCode. In fact, I would go so far as to say that I would prefer to be using Linux instead of OS X when working with open source code bases such as Apache httpd.
XCode made a huge mistake when it split off from Project Builder: it went from a makefile to a binary project format. It’s faster and allows for a few cool features, but it’s incompatible with anything else and impossible to work on in case of trouble.
Metrowerks had the same problem: it was at least possible to export their projects to XML (and I’ve successfully fixed a few that way.) CW10 (the final release, due Real Soon Now) is supposed to have text project files. Selling anything is going to be a challenge for them; this is one of the few things that would make me willing to look.
Debugging on OSX in general has been a huge disappointment. Up through Jaguar (at least) we did all development on OS9, on the theory that a few reboots were less annoying than a few dozen 20 second waits for a debugger to start up, and the 1 second/line “pause” when single stepping. It took a G5 w/ Panther to finally match the debugger speed of OS9 on a G4/450.
Netbeans? LOL!
Netbeans is the biggest piece of garbage in existence. We had to use that at school for Java work, and I found it to be the most convoluted, intrusive, nasty piece of software that I’d ever used. Not to mention the fact that it was slow as molasses on a cold winter day.
That shit was laggy even on a 1.8 GHz Athlon XP with 512 MB of RAM.
What version of NB were you running? If it was 3.6 then I agree wholeheartedly but check out 5 beta 1 and you would be pleasantly surprised.