The secret to enjoying Xcode
One of the things that made me like Xcode more and become more efficient with it is realizing that while all coders are insane, me and Xcode's designers are insane in different ways.
By that, I mean that aside from the standard keyboard shortcuts (Save, Copy... that sort of thing), none of the keyboard shortcuts made sense to me.
So I duplicated one of the keyboard shortcut profiles and deleted most of the keyboard bindings. I was brutal with it — if the combination didn't make sense to me OR it was something I'd rarely use it was removed. Then I added keyboard shortcuts that I needed. By using about an hour to customize these settings, I ended up having keyboard shortcuts that I fully understood and rolled off my fingertips.
At this point — and this is where it became a useful exercise — I added my ~/Library/Application Support/Xcode to version control so I could easily sync it between computers. So when I find something that isn't quite working out for me, I make a change and propagate it to my other system.
Am I going to share what I ended up with? No, because that's not the point of this. Rather, I want to point out a simple fact of Xcode: Xcode will adapt to how you want to use it, and if you feel like you're suffering at all with it you should spend the time it to takes to make it enjoyable to use.
And when someone tells me I can do something with a particular keyboard shortcut, I switch back to the defaults and see what it's bound to.
Xcode and iPhone OS 3.0.1
To get Xcode 3.1.3 working with iPhone OS 3.0.1, you'll need to teach Xcode how to target iPhone OS 3.0.1.
Xcode will automatically recognize iPhone OS 3.0.1 and look for a new SDK at a set path. The problem is that SDK doesn't exist. The good part is that the iPhone OS 3.0 SDK works perfectly for developing 3.0.1. The only apparent change is the SMS fix.
Assuming you've installed to /Developer, the iPhone OS 3.0 SDK is here:
/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0 (7A341)
When using Xcode with iPhone OS 3.0.1, Xcode looks for the iPhone OS 3.0.1 SDK here:
/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0.1
The trick, then, is to build a symbolic link that connects what Xcode is looking for with what it needs to find.
So what do you do? Assuming you've installed Xcode in the standard location, this is a Terminal command to fix the problem:
ln -s /Developer/Platforms/iPhoneOS.platform/DeviceSupport\
/3.0\ \(7A341\) /Developer/Platforms/iPhoneOS.platform/\
DeviceSupport/3.0.1
(I've split this into three lines to make it easier to copy and paste with the \ line continuation character.)
This will not add a SDK to Xcode's list, it will just teach Xcode to map your device to the 3.0 SDK.
A few other tips:
- If you still can't debug restarting your iPhone may help. Most of the iPhones I've tried to debug on, I've had to restart first.
- If you get an error regarding code signing, try downloading your provisioning profile again and re-installing it. Also, select it again in your build settings.
Based on information from iPhone OS 3.0.1 Advisory.
Apple's developer documentation website is horrible
Isn't anyone at Apple even mildly embarrassed about how poor the ADC search results are?
Like everyone other Mac developer (at least, those not using a seed... no comment otherwise), I've been bit by the Mac OS X 10.5.7 bug that causes Xcode to crash almost every time the documentation viewer is used.
Now I'm a reasonable guy. I get that a Mac OS X update has to be thoroughly tested. I wouldn't want it otherwise. So let me get this off my chest right away: it isn't the bug itself that bothers me.
Xcode 3.1.3 shipped after Mac OS X 10.5.7. So it should have been pretty easy to add code to Xcode see if the developer has executed a defaults write com.apple.xcode dontevershowthefuckingdocviewer 1 and then never show the documentation viewer, so I wouldn't lose unsaved work every time I forgot and tried to open it.1
And in the future, the documentation links should be handled via an URL type that can be handled by another application.
And, oh yeah:
Why is the documentation viewer embedded in the IDE?
Splitting the documentation viewer into a separate application would make a lot of sense. Browsers crash! If it wasn't this, it would be something else that crashed the documentation viewer. This was predictable. This was, dare I say, expected.
But what really, really makes me angry is the developer site. The content is generally pretty good, but the search engine is horrible:
- Fix your summary so it's actually useful.
Apple's summary:
Google's summary:
There's just no comparison.2
- I don't need to see every single empty redirect. Showing the same effective document multiple times is just random clutter.
- There are better ways to represent the format of documentation in search results than just including it in the URL.
- Add up those last two items, and you realize: I don't need PDFs in the search results. PDF should just be linked to from the documentation itself.
I'll update this when I have more points. The bile has receded enough for me to code again.
Setting up Subversion 1.5 on Xcode. (Instructions are for Collabnet build, but you can use MacPorts build instead by replacing the path /opt/subversion/lib/ with /opt/local/lib/.)
Loving Xcode + iPhone SDK
I've been full time on an iPhone project (more of a prototype, really) for one day, and I absolutely love it.
- It's simple and intuitive. Drop controls, set up outlets and actions.
- You don't have to fight the framework. It does what it does with a minimum of fuss.
- A good UI is a focused UI, rather than one full of features. I love this style of thinking.
I'm less thrilled with Xcode's documentation viewer. It feels like a really poor web browser that takes more of the screen for junk, runs in the same workspace so you can't command-tab in and out of it. Just splitting it into a separate process would immediately improve it.
In about a day, I created four screens and linked them all together. That doesn't sound horribly impressive, but it felt easy. Granted, I've previously spent a few hours figuring out UINavigationController, but things were actually simpler than I had understood. Finding things took a while, but they were generally hidden in plain sight. The few times I violated something in the runtime, the error message was simple, direct and accurate.
I do wish SQLite was a more recent version. I would love to use sqlite3_open_v2 in some of this code, especially the SQLITE_OPEN_READONLY flag.
Two strikes…
Apple's sample code includes an annoying disclaimer at the top of each file. I can understand the need for a disclaimer, but this code takes it to an obnoxious level: every .h file or .m file you open, you can't see any actual code to to the length of the disclaimer.
Strike one is including that disclaimer in every file. If the lawyers can't accept "Please see DISCLAIMER.TXT." in place of 38 lines of bullshit, you have stupid lawyers. Fine, though. I'll just remove it, right?
Luckily, Xcode has a great Find-Replace tool. So we'll use it.
And here's where we hit strike two:
It'd be nice if we could blame this on Xcode. Indeed, it's Xcode's fault that the text is so long. But it's Mac OS X's fault that the sheet goes under the dock rather than truncating before it.
May I please crash now?
This is from Xcode's Interface Builder. I've never seen a more polite assertion failure. It even asks if it's okay to crash. You don't see that very often. And keep in mind this is for a tool used by software developers. What's our excuse when developing software for regular users?
And yes, I'm going to choose Crash. They asked politely enough.
Xcode's documentation is automatically updated
I hadn't seen anything about this before:
Xcode's documentation is regularly updated using RSS downloads so you always have the latest information.
(Source: developer.apple.com/tools.)
This is awesome. I can't count how many times I've ignored documentation updates because the update process is complicated enough to be yak shaving.
Apple to Carbon developers: Switch to Cocoa
Despite being promised last year, it looks like Mac OS X 10.5 will not have a 64-bit Carbon. This is actually pretty pathetic - it seems as though Carbon 64 was almost ready. Despite the Carbon team having fewer resources and accomplishing more - and being a better environment for anyone trying to write code in a reusable way - the language bigots in Apple decided to kill it.
And despite years of calling Carbon an API on equal footing to Cocoa and assuring developers would remain fully supported, developers are suddenly left without a path forward. Apple, meanwhile, will just tell users "they can port to Cocoa," without mentioning how much work that is, or how it is simply impossible in some cases.
Apple, I don't really care how cool Cocoa is. I'm not using it for anything serious because of Objective C. It's really that simple.
Apple's been leading a misinformation campaign for years against developers. First it was about how little effort would be needed for Carbonization, then how little effort to move from CodeWarrior to Xcode, and then how little effort required to move to Universal Binaries. (To be fair, they were very nearly telling the truth about that one.)
I think it's time for developers to fight back. There's only one way to win this: Make it as embarrassing to Apple to withhold Carbon 64 as it was to not announce an environmental policy, or to not have a public battery exchange program in effect for iPods. A couple full-page ads in media publications would do it. End users don't need to know all the technical details, they only need to know there's a simple problem that Apple is withholding a solution to for political reasons that will cost them hundreds of applications going forward. Apple would roll over before the ink dries.
I'm utterly shocked that major companies such as Adobe and Microsoft haven't done this yet. It would certainly be cheaper than porting to Cocoa. And better for the Mac OS X platform, too: As long as Mac OS X isn't the only game in town, Carbon and C++ are far more important than Cocoa and Objective C. It's sad that Apple needs help seeing that.
Visual Studio vs. Xcode
Working with Xcode and Visual Studio on a day-to-day basis, it's natural that I'd compare the two tools. The following is not intended to be an unbiased comparison. These are my opinions only. They're based on how I work, and how I expect tools to work.
Project Configuration: Xcode
Xcode wins cleanly for its configuration editor, which can display all settings at once, predefined groups of settings, or only customized settings. Visual Studio, by comparison, can only display predefined groups of settings. Putting Xcode even further ahead is its ability to filter the settings view as you type. Visual Studio gets some points for having a more capable path editor, but that's really all it has going for it.
Subprojects: Visual Studio
Visual Studio does Xcode one better by showing all the details of the subprojects, including exactly which sources make it up, right in its solution explorer.
Editor: Xcode
Xcode scores a weak win here for having more useful keyboard customizations available. Part of this is the additional meta key available on the Mac.
Window Management: No winner
Visual Studio offers more in the way of window management, but the options are not ones I find useful. On the other hand, Xcode offers more styles of working, but I only use one of these as well. Comparing Visual Studio's style with Xcode's, I see no advantage to either.
Stability: Xcode
Visual Studio's Intellisense is worse than useless, making it impossible for me to work unless I use an undocumented trick to disable it. A quick Google search shows I'm not the only one having problems.
Price: Xcode
Xcode is free. Visual Studio isn't. Adding a replacement for Intellisense makes Visual Studio even more costly. (Swapping out hardware to prove to management that Visual Studio was the culprit and not my system made it even more costly.)
CVS: Visual Studio
Visual Studio does not include CVS integration. Xcode's CVS integration does not work for me. It would be a draw, except that Xcode's textual project files have minor differences when the project is cleaned vs. built. (I've been told this will be fixed in Xcode 3.)
Menu Layout: Xcode
Xcode provides a more logical menu layout, with fewer regularly used commands in sub-menus. In particular, Visual Studio banishes search/replace tools to a sub-menu of Edit. Visual Studio offers a way to customize menu commands, but I'd much rather have a logical if locked layout.
Source Search Tools: No winner
While I find Xcode's search tools more useful, both sets are so pathetic that I refuse to give it a win here.