Xcode user defaults allows some good stuff!

Thanks to @ddribin for the reminder that Xcode user defaults contains some good stuff.

Apple documentation is here.

Here are the settings I just set different from the defaults (yah, I know, I like lots of space):

defaults write com.apple.Xcode XCCodeSenseFormattingOptions -dict InExpressionsSpacing " " InFunctionArgsSpacing " " InMessageSpacing " " PostColonSpacing " " MessageArgSpacing " " BlockSeparator "\n"

Not sure that’s all how I want it yet, but hopefully that’ll fix a few things I dislike (like when I select something in the help text and it’s pasted in all cramped with no white space.

Unfortunately, MessageArgSpacing doesn’t seem to be working… in Xcode v3.1.4 anyway… ūüė¶

Reminder that the application shouldn’t be running when you’re editing user defaults.

iPad design

Geek & Dad have a coveted early-access developer iPad? How in the world did we get on that list?!

Geek & Dad only has one small app in the AppStore! Maybe Apple’s trying to motivate young programmers for that’s where they see the innovation coming from? Astounding!

Ah, not quite ūüôā :

Reality: after reading a tweet by @ravenme, dad decided to make an iPad prototype to get a sense of how users will interact with the device. Definitely helps to get a feel for it! However, the pictures above before dad realized it needs to weigh more. ¬† Matte board and cardboard make for a very light iPad! ¬†Dad quickly realized that he was holding it in portrait mode with one hand in a manner that was not something users were going to be doing (at least not for long. ¬†Adding weight is clearly needed. That’s next.

Fun experiment.

Launch Services Database; 64 bit vs 32 bit on 10.5.x

Some notes on using lsregister to modify the launch services database to get the Finder to acknowledge changes you’ve made to your info.plist. Also sample info.plist entries to get your app to launch in 32 bit mode in 10.5.8 and 64 bit mode in 10.6.

Dad was working on a Mac Application and put in the entries in the info.plist so that the application would launch as 32bit in 10.5.x and 64 bit in 10.6 and later. ¬†Unfortunately, it wasn’t doing the right thing and it took some detective work to track it down.

Turns out this application was using a slightly modified version of Chris Campbell’s SystemVersionCheck shim and it launches the real executable via execv which seems to ignore LSMinimumSystemVersionByArchitecture and code>LSArchitecturePriority and always seems to launch the first architecture in the application executable (not 100% sure on what rules it uses to decide).

What works without the system check launch thing is this:


While trying to track this down I ended up wanting to purge the entries in the Launch Services database. The lsregister tool is used to do this, and there is an applescript out there that’ll do it with a GUI and force a complete rebuild. If you want a more surgical approach, you can use commands like:

./lsregister -dump > ~/Desktop/ls_dump

to get a dump of the launch services database to figure out what’s going on. Note that ./lsregister -h provides helpful information.

I ended up using the ./lsregister -f -r -v -u {path_to_parent_folder} version of the args to unregister an old bogus entry (and -v to see what was going on). Note that you can’t get rid of an entry at a path that no longer has the file – I had to put a copy of the app into the trash, run the -u version and then quickly empty the trash in order to get rid of an entry referencing it there.

In 10.5.x this tool is in the LaunchServices.framework/Support/ folder. LaunchServices is in CoreServices.framework/Frameworks/

or (sorry about formatting)


Note that in 10.6 this tool has moved to


and may have other commands (I was working in 10.5.8).

ok. Now I can find this info again when I forget ūüôā

How Times change…

When Dad starting programming for the Mac it was in MacPascal (one quarter of freshman physics lab), then in Rascal [1] (on which he later worked), then LightSpeed Pascal (which became Think Pascal), and then Think C (previously LightSpeed C), and so on. [2]

However, when we were writing a Mac application back then we just needed to know one language (Pascal or C) and maybe some 68xxx assembler for interpreting what Macsbug was telling us (if writing low level code). ¬†We did have to learn the Macintosh Toolbox which is equivalent to the class libraries of today (e.g., Cocoa) – Dad still has 2 feet of shelf space devoted to “Inside Macintosh” books from that era that probably should be recycled already :-).

In contrast, Dad is close to finishing an iPhone app for a client that displays data from a database on a server (and some live XML data feeds from the server).  To complete this project has required:

Server Side:

PHP, SQL, XSLT (+XPath), HTML, CSS, JavaScript, XML, Python, Apache2 config files, make files, command line syntax for svn, tar, pax, and various other command line tools.

iPhone Side:

Objective-C, HTML, CSS, JavaScript, XSLT (+XPath), XML, Property Lists (yes, just a variant on XML, but need to know the differences), and shell scripts (for a Run Script in Xcode).

So, the point is, Wow! The breadth of knowledge that is required to create the software we create today is astounding compared to what it was back when this adventure started 25 years ago.

Not the new Rascal¬†languages (rascal-lang or the Rascal DSL meta programming language), the old one (dare I say original one ūüôā) which was the first (or one of the first) native IDEs that would let you program the Mac in something other than assembly language without a Lisa (see 1985 entry at old one, but it was in development before then I believe).

For the history nuts, my older-than-40-memory says my complete sequence on the Mac was roughly:  MacPascal, Rascal, Consulair C, LightSpeed Pascal,  Think Pascal, Think C, Think C++ (TCL РThink Class Libraries), MPW Objective Pascal (MacApp) & C++, Metrowerks CodeWarrior C/C++ (PowerPlant), Xcode C (Carbon) and Objective C (Cocoa) and now on the iPhone Xcode Objective C (Cocoa Touch).

Some of the relevant history is¬†here (Dad was there from 1984-1990 and hanging out and eventually working in the “DLab” from sometime in late 1985 or early 1986 onward). ¬†The rest is work related from 1990 onwards.

Lots of other side languages for learning, fun and contracts over the years, some on the Mac, some not: ¬†Basic & Pascal (high school, before Mac), 68k assembler (MacAsm originally), 8051 assembler, Java,¬†Smalltalk, Lisp, Eiffel, Visual Basic, Visual C++, whatever PocketPC required (straight C? can’t remember), and so on. ¬† What a strange soup of names. ¬†What’s it all mean? ha!

Make Xcode stop prompting to save files in other editors

Tired of having Xcode (3.x and later) prompt to you “Save Changes To ‘index.html’ before building?” when index.html is open in TextWrangler/BBedit and so on and has _nothing_ to do with the current iphone project you are working on? Read on for the answer!

The easy way is to just set the “For Unsaved Files” setting in the Building section of the Xcode preferences to not prompt you, but this defeats the prompt for files IN Xcode that you maybe DO want to be prompted to save.

In Xcode there was support for “external editors”. In Xcode 3.x I don’t see the UI for configuring these any longer so I’m not sure if it still exists or not. In any case, this functionality is the cause of the annoying prompts to save totally unrelated files other editors.

The list of external editors is in the com.apple.Xcode.plist file in your ~/Library/Preferences/ folder and removing that list “solves” the problem. There may be better ways to solve it, but this is the one I found that works.

The two keys are XCExternalEditorList, and PBXExternalEditorList, however in my test only the second one had to be removed to make these annoying prompts go away; in the terminal:

$ defaults delete com.apple.Xcode PBXExternalEditorList

Of course Xcode shouldn’t be running when you do that or it’ll either ignore you or just rewrite them into the file.

*** Note that you probably DO want Interface Builder in the list of external editors in XCExternalEditorList (the newer key), so if you want to remove entries from that one, do them individually instead of removing the entire block of entries ***


Work-around for multiple iPhone Dev account and code signing and Xcode Organizer problems

Xcode gives errors when you have multiple iPhone developer accounts and the name on the keys for the certificate are the same. This post outlines the two areas (Xcode Organizer and code signing) where there are problems and provides work-arounds.

Update 2/2010: This is no longer a problem because apple now issues certificates with a hex hash after the name. ¬†So if you regenerate all your certificates and profiles they can then all live in your login keychain just fine (you’ll have to delete the old ones).


Ok, maybe everyone else already knows this, but since it boggled apple dev support (the bug I wrote 6635822 and the duplicate someone else opened, 6229180 both seem to still be open) I thought I’d write about the work-around I figured out today:

First, the problems:

There are two related problems, with two related work-arounds.

Both problems arise when you have two iPhone developer accounts and the name on the keys for the certificates are the same (likely since you are required to use a person’s name and your real name when signing up with Apple, AND your name on the certificate request has to be the same as what you signed up with).