I’m one of those computer programmers who downplays the difficulty of the profession, because “if I can do it, anybody can do it!” On the other hand, I have faced challenges that made me question whether I’m vaguely qualified for the job. What it boils down to is that programming is both incredibly simple and impossibly hard, like so many important things in life.

There was a time when nobody knew how to write literary prose. The geniuses who invented it shared their special tool with a few friends, and they relished in their private, elite communications. Eventually monks, politicians, and academics joined the club. Now, we judge a society’s overall level of intellectual advancement by the literacy rate: the percentage of people who have learned to read and write.

Literacy isn’t about becoming a Hemingway or a Chabon. It’s about learning the basic tools to get a job done. I think programming — coding — is much the same. You don’t have to be the world’s best programmer to develop a means of expressing yourself, of solving a problem, of making something happen. If you’re lucky, you’ll be a  genius, but you start out with the basics.

Long ago, it would have been ridiculous to assume a whole society could be judged by its ability to read and write prose. It feels ridiculous now, to assume that we might use computer programming as a similar benchmark. Yet it may happen.

Did you always mean to learn another language, but never did? By all means, learn Spanish, French, or Chinese. But learn to code, too.

C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it.

Brent affirms his support while paying homage to plain-old C:

But I will admit to an enduring love of C. I still think of C not as C but as the language.

I loved C. Emphasis on the past-tense. As object-oriented programming concepts became popular, those of us who were programming in C or similar procedural languages had to find new, object-oriented languages to fulfill our needs. At the time, I chose C++. Or I should say, I had C++ forced upon me. Because C++ popularized the notion of object-oriented programming, it was the only choice presented to many programmers.

Because I ended up at Apple, the time I spent with C++ was thankfully short. They were fortuitously behind the times at the dawn of my career, and wound up taking a different path while my career was ascending.

Objective-C was Apple’s response to object-oriented programming, and continues to be the lingua-franca for programmers on Macs, iPhones and iPads. I loved C. I love C. But it always fell short for me. It lacked something. Objective-C fixed that. I hope I never have to program in C++ again. But tellingly, I also hope I never have to program in C again.

There are lots of great features from Python, Ruby, or JavaScript, that I’d love to see incorporated into Objective-C. By no means is it perfect. But for its elegance, and for the fact that it fulfills many of the requirements of object-oriented programming, while maintaining the familiar simplicity of C, it presently earns the title of the language for me.

[Update Nov 7: I've had a lot of reaction to my claim above that Objective-C was "Apple's response to object-oriented programming." This makes it sound like Apple invented the language, and they didn't. But they have done more to popularize and promote it than anybody else. I stand by the meaning of it being "what they bring to the table," when it comes to object-oriented programming].

I’m really excited about sandboxing and also really terrified. Apple has given us, thus far, a limiting set of entitlements that don’t quite cover everything that reasonable apps want to do, or even everything that Apple itself has approved as acceptable behavior in the Mac App Store. Yet Apple has made it clear that it wants to see all apps adopt sandboxing, and the writing is on the wall that in particular, participants in the Mac App Store should be prepared for the day when non-sandboxed apps may not be approved for sale in the store.

For us developers looking into sandboxing our own apps, it can be tough to wrap one’s head around exactly what privileges need to be requested. One way to go about it is to sandbox your application with the strictest of controls (basically disallow everything disallowable), and see what breaks. Then you could add back whatever entitlements are necessary to get things working again.

On the other hand, it would be handier to have the system simply tell us what kinds of behaviors our app is engaging in, and what the corresponding entitlements would be to allow it to work even while sandboxed. Thanks to a tracing mechanism in the sandbox, this is in fact possible. Furthermore, you can use a command-line tool to apply arbitrary sandbox profiles to an application without having to modify the application itself.

I defined a handy shortcut in zsh for running an arbitrary app with the “trace” mechanism enabled, to show exactly what the app is accessing, simplify the output, and open it in my default text editor:

function sbx()
{
        echo '(version 1)\n(trace "/tmp/traceout.sb")' > /tmp/tracein.sb
        sandbox-exec -f /tmp/tracein.sb $1
        sandbox-simplify /tmp/traceout.sb > /tmp/tracesimple.sb
        open -t /tmp/tracesimple.sb
}

After you’ve defined this in your .zshrc (other shells, you are on your own!), you can do something like:

sbx /Applications/FastScripts.app/Contents/MacOS/FastScripts

Then you use whatever features in your app you are concerned about, and quit the app. A text file will open with exquisite details about all the privileged actions your app was permitted to do, which would otherwise be forbidden by the sandbox.  Great, just copy that list of permissions into your sandbox entitlements plist, and we’re done. Right? Not quite.

The rules generated by the trace are very precise and may not be sufficient to cover your app’s behavior in practice. For example, if I open FastScripts, my scripting utility, and run a single AppleScript that controls the terminal, the resulting permissions trace reveals a sandbox rule that would allow that behavior to happen:

(allow appleevent-send
       (appleevent-destination "com.apple.terminal"))

That’s well and good for a utility that only ever needs to send events to the Terminal, but of course FastScripts is a general purpose scripting application that needs to send events “wherever the heck the user wants to send them.” Currently, Apple doesn’t offer a sandbox entitlement for this broad behavior, so it is not possible to sandbox FastScripts.

I think that Apple would have a lot more developer enthusiasm for this feature if it wasn’t so clear to many of us that our apps will be forced to lose features in order to adopt sandboxing. And while users may be happy about the prospects of improved security with the sandbox, I think there will be less excitement about the diminished functionality of apps whose features don’t fit nicely into the sandbox confines.

Developers and power-users can use the sandbox command-line tools now to get a good sense for what will or will not work down the road if sandboxing, with the current set of entitlements, is enforced by Apple for a large number of 3rd party applications. There is some documentation for these tools in e.g. “man sandbox-exec”, but the documentation is pretty minimal. If you want to read more, check out this useful document, which aims to give a better understanding of the sandbox, entitlement profiles, and how to use the command-line tools.

1. Navigate to a .app file in the Finder, e.g. /Applications/Mail.app
2. Control-click the app icon and select “Show Package Contents”
3. Navigate to Contents/Info.plist
4. Open with a plist editor or your favorite text editor.

These files advertise a number of interesting attributes including the application’s official version and copyright strings. They also include important clues to the system about what kinds of files the application knows how to read and write, and what its minimum system requirements are.

Minimum System Requirements

Declaring the right Info.plist values not only allows a developer to control which operating systems a product should run on, but which of the application’s architectures should be considered for a particular operating system. For example, Black Ink uses a number of keyed values describing its requirements:

	<key>LSArchitecturePriority</key>
	<array>
		<string>x86_64</string>
		<string>i386</string>
		<string>ppc</string>
	</array>
	<key>LSMinimumSystemVersion</key>
	<string>10.4.0</string>
	<key>LSMinimumSystemVersionByArchitecture</key>
	<dict>
		<key>i386</key>
		<string>10.4.0</string>
		<key>x86_64</key>
		<string>10.6.0</string>
		<key>ppc</key>
		<string>10.4.0</string>
	</dict>

Notice the fidelity of some of these options. Black Ink is an application that is compiled with binary code for three separate architectures embedded into it: 64-bit Intel, 32-bit Intel, and 32-bit PowerPC. In order to give the user the best possible experience after they double-click the application icon, the system consults the Info.plist values to determine which binary is most appropriate to load on the current system.

The options for Black Ink start by indicating that all things being equal, it prefers to run as 64-bit Intel, but will settle for 32-bit Intel or PowerPC in a pinch. Next, it conveys that it should not be run on any operating system earlier than Mac OS X 10.4. Finally, it adds an additional restriction by architecture, stating that in the case of 64-bit Intel, the system should consider Mac OS X 10.6 the minimum required OS.

Why so picky? For example, Mac OS X 10.5 will run on computers that are new enough to support 64-bit Intel code, but the 10.5 operating environment itself doesn’t contain enough compatible libraries to make it very useful to a full-featured Cocoa application. So we need to convince the 10.5 system to ignore our 64-bit Intel code. And this is how it’s done.

Embedding Info.plist

This is all well and good for applications, but what about other code that may be run on a variety of hardware and operating systems? In particular, command-line tools do not come in the same bundled-folder format that applications do. Fortunately, Apple thought of this when they implemented support in their developer tools for embedding the contents of an Info.plist directly into the binary itself. You just have to pass the Info.plist path to Apple’s linker tool when it’s constructing your binary file. (Thanks to Paul Kim for reminding me of this functionality). What this means in practice is adding arguments like this to your Xcode target’s “Other Linker Flags” build setting:

-sectcreate __TEXT __info_plist $(INFOPLIST_FILE)

This instructs the linker to crete a new text segment named “__info_plist” in the resulting binary, and to fill it with the contents of the referenced Info.plist file. To make sure the INFOPLIST_FILE expands correctly, just make sure you set it in the separate build setting for identifying the Info.plist (the one you’d normally use in an app, and that is just ignored by default for a command-line tool target).

I brushed up on all this information because I wanted to help ensure that some recent work I did to create a standalone MultiMarkdown tool would be backward compatible with older systems. This required adding an embedded plist much as I’m describing here.

(Note: I have gotten some feedback to the effect that the __info_plist segment’s minimum system version requirements may not actually be consulted properly on Mac OS X 10.5. This would be a bummer, and in fact sort of reject the whole point of embedding the Info.plist in this case. I’m going to see if I can confirm whether it doesn’t in fact work.)

You could technically embed all kinds of stuff in the binary, with different section names. But the contract in this case is that when Mac OS X is determining information about an executable, it will consult the bundle’s Info.plist file, if it happens to be an executable in a bundle, or the binary’s __info_plist segment, if it happens to have one.

Another common reason for needing to embed Info.plist information into a standalone binary is if you are using Apple’s code signing mechanism to sign an individual binary tool. Code signing uses information from the Info.plist of a product, and in the case of standalone binaries, the only product-cohesive place to put this is in the binary itself.

Examining Binary Info.plists

After you’ve performed the magic above, you’ll probably be keen to inspect your command-line tool’s Info.plist to see if it worked. To do this, you can use the otool command from the Finder. If you run otool with the “-l” option to show all load commands, it will include the load command that identifies the __info_plist segment. Use grep to narrow it down to the part you’re interested in:

otool -l ./yourTool | grep info_plist -B1 -A10

Any results at will confirm that there is Info.plist information in the binary, but how does it look? The “-s” option to otool lets you examine the contents of a specific segment in a binary, but it dumps it out as hex code. Fortunately, another system-bundled tool called “xxd” is capable of easily converting between hex-dump and text formats. As it turns out, some of Apple’s bundled developer tools (at least on my Mac) contain these embedded __info_plist sections, so if you don’t have a command line tool of your own to try this on, you can peek at what the “atos” tool has to say for itself:

otool -s __TEXT __info_plist /usr/bin/atos | xxd -r

In Summary

Info.plist values are important for conveying information about your product, from the crudest, most obvious stuff like version number, to the most nuanced details such as which architectures are supported. Knowing how to specify an application or tool’s requirements as precisely as possible will ensure that the product performs optimally on whatever supported system your user happens to be using. I’ve barely scratched the surface here with a few common deployment keys that control execution behavior on Mac OS X. Be sure to skim Apple’s Information Property List Key Reference to see if there are other useful bits of information you can share for your application or for your command-line tool.

Consider the work that went into the first word processors and web browsers, whose work can now be mimicked by a Mac developer who knows how to embed NSTextView or or WebView. Imagine the time that early game developers invested in rudimentary sprite drawing, animation, and collision, which is now achieved easily in iOS games with open source packages such as cocos2d.

Still, building truly great software continues to elude most developers. It’s easy to assume that a large amount of time invested in a project, combined with an impressive outcome, is the key to a successful product. But it’s not so simple.

The ninety-ninety rule is often cited when describing the challenge of finessing a product after most of the hard work has seemingly been done:

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.” — Tom Cargill

I agree with this perspective, and I cite it often when discussing software with others. The rule as stated is in terms of “code” but is also applicable to all the visual design, user experience, marketing, and positioning of a product. I think the rule is also recursive: whatever is missing can always be split up such that an “easy” 90% of the job can be done, leaving an elusive 10% of finesse work.

Many developers mistakenly assume that after they’ve put a ton of work into a project, and it achieves some impressive feat, that their work is done. When you focus on the enormity of work completed thus far, it’s tempting to pat yourself on the back and call it a day.

But customers don’t care about the hard work that went into the 90%. They only notice the flaws or omissions in the 10%. Imagine if Michelangelo’s statue of David was perfect in every detail, except that where David’s face should be, a clump of ragged, unfinished marble lay crudely in its place. Instead of marveling at the exquisite details of David’s feet, torso, and arms, viewers would reject it as unfinished and clumsy.

An important takeaway for software developers is that the missing 10%, or the missing one-tenth of 10%, may be something that will take a great deal of work to get right, but it may be something you simply overlooked the importance of.

You might build an impressive skyscraper projecting 40 stories into the sky. The architecture, interior design, plumbing, and electrical work may all be superior to that of your peers. But if some blindness in your product vision prevents you from adding windows, the product will never sell. It doesn’t matter how much time or effort went into this masterpiece: nobody will live in a windowless skyscraper.

For the longest time, I assumed it was simple mistakes: I had neglected to ever approve “remember this password,” or I had somehow invalidated the password in my keychain. But recently I have come to realize that Safari is no longer auto-filling passwords for me on any site. Ever. This sucks. Usually when something like this happens, the first thing I do is “Repair Keychain” from the Keychain Access application. But in this case, the keychain is reportedly not damaged. No help.

To research this problem, I started the way I usually do: Googling it. While there are many promising search results, most of them lead to “solutions” that are not applicable to my scenario. Most commonly it seems the user has somehow ended up with the appropriate “User names and passwords” checkbox being turned off in Safari’s AutoFill preferences.

So how does a programmer like myself approach a problem like this? In recent years, Apple’s Instruments application has become an incredible asset for tracking down weird behavior not only in my own apps, but in other apps and in the system itself. I opened it up and started a new “Time Profiler” instrumentation session, targeting Safari. I know that Safari used to autofill my password whenever I typed in an account name that it recognized, so I start Instruments “sampling” Safari while I type my PayPal account name into the PayPal login page, and stop it after I’m done.

I want to figure out where Safari is failing to get my password, so I take a wild leap and assume the corresponding function call in Safari contains the word “password.” Typing this into the Instruments search box yields promising results:

Now I know that Safari is at least making an effort to fetch the corresponding password for me. I see that it’s calling -[NSURLCredential password], which in turn calls a lower-level Keychain Services function, SecItemCopyMatching(). But why isn’t it filling in my password?

At this point I switch to gdb, where i can attach to the running instance of Safari and dig a little deeper into the issue.

% gdb
(gdb) attach Safari
(gdb) b -[NSURLCredential password]
Breakpoint 1 at 0x7fff8ddff4af
(gdb) c
Continuing.

I know from Instruments that Safari will call this method when it tries to autofill my password, so I go back to Safari and enter my PayPal ID again. Sure enough, Safari “freezes” indicating that gdb has interrupted it where my breakpoint was set. Now, I realize this isn’t for the faint of heart, but you can use gdb to effectively debug an application, even if you don’t have the source code. You just have to know a bit about how Apple’s compiler translates source code into corresponding assembly language instructions, and where the arguments are placed when calling methods.

Breakpoint 1, 0x00007fff8ddff4af in
-[NSURLCredential password] ()
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) po $rdi
<NSURLCredential: 0x7ffd34d62920>: paypal@jalkut.com
(gdb) po [$rdi password]
2: x/i $pc  0x7fff9192760e <gdb_class_getClass+4>:
	mov    0x20(%rdi),%rax
Can't print the description of a NIL object.
(gdb)
(gdb) p (int) [$rdi hasPassword]
$11 = 1

What I’ve done here is first delete the breakpoint, so I don’t get interrupted while poking around from gdb itself. Then, I display the NSURLCredential object’s description, confirming it corresponds to the account I’m trying to log into. Finally, I call the password method on this NSURLCredential object myself, so I can see quickly and easily what the response will be. Gdb’s objection to trying to print a NIL object confirms that the password is not being returned. I am further able to confirm with NSURLCredential’s “hasPassword” method that the keychain does have a password for this account, but it isn’t being returned.

Here we have a situation where apparently Safari is trying to get my password, but the system is vexing it. Let’s confirm by setting a breakpoint a little deeper, at the Keychain Services level that we also noticed in Instruments.

(gdb) b SecItemCopyMatching
Breakpoint 3 at 0x7fff85919582
(gdb) c
Continuing.

Breakpoint 3, 0x00007fff85919582 in SecItemCopyMatching ()
(gdb) po $rdi
{
    acct = "paypal@jalkut.com";
    atyp = form;
    cdat = "2007-06-02 16:17:01 +0000";
    class = inet;
    desc = "Web form password";
    icmt = default;
    labl = "www.paypal.com (paypal@jalkut.com)";
    "m_Limit" = "m_LimitOne";
    mdat = "2011-07-29 15:30:15 +0000";
    port = 0;
    ptcl = htps;
    "r_Data" = 1;
    srvr = "www.paypal.com";
}

So far, so good. It looks like NSURLCredential is properly passing a set of criteria to the keychain, describing the kind of password item it’s looking for. I take a peek at the second argument to SecItemCopyMatching, which is a pointer to where the result will be stored, and then I ask gdb to continue executing until the function is complete.

(gdb) x/x $rsi
0x7fff62eb3590:	0x0000000000000000
(gdb) fin
Run till exit from #0  0x00007fff85919582 in SecItemCopyMatching ()
0x00007fff86417c29 in URLCredentialInternetPassword::copyPassword ()

When gdb returns control to me, I know the function has finished calling, so I examine the result area in memory.

(gdb) x/x 0x7fff62eb3590
0x7fff62eb3590:	0x0000000000000000

Indeed, it’s NULL! What is going on, here? I decided to dust off my Usable Keychain Scripting tool, which makes it easy to use AppleScript to search and inspect the keychain. Is the inability to access the password a system-wide thing, or just something that is vexing Safari?

tell application "Usable Keychain Scripting"
	tell current keychain
		password of keychain item "www.paypal.com (paypal@jalkut.com)"
	end tell
end tell

The script works perfectly, first causing the system to ask permission to authorize “Usable Keychain Scripting” to access the keychain item, and then returning the expected password string. This got me thinking, is it possible I’ve somehow got Keychain Accessing refuse access only to Safari?

When I look at the “Access Controls” for the affected keychain item, it lists Safari as one of the permitted apps. What the hell, I think. I’ll remove it from the list, and then re-add it. To try to “dislodge” something. Confoundingly, everytime I try to add it, it just silently fails to appear in the list. I am able to add any other app without an issue.

As a quick check, I change the setting to “Allow all applications to access this item,” and save the changes. When I return to Safari and type in the login name, it instantly fills in the password for me.

My system has a functional keychain but Safari seems unable to be authorized to access it, either on a one-time basis or as a “always allow” permission. I finally got the clever idea to look at /var/log/secure.log, which frankly, I should have done about 5 hours earlier. What’s this?

com.apple.SecurityServer[33]: suppressing keychain prompt
for invalidly signed client /Applications/Safari.app(2938)

Aha! So that would explain it. Funny, I don’t remember tweaking anything inside the Safari application bundle, but this is certainly a very real example of how a broken code signature on Mac OS X can cause extremely subtle, hard to track-down “bugs.” I re-signed the applicaton on my own:

codesign -f -s - /Applications/Safari.app

When I reopened the app, and went to PayPal’s site, voila! It prompted me for permission, I approved, and now everything is back to normal.

I examined the Safari.app bundle contents to try to remember what I might have tweaked. Then my memory was jogged. I had opened and edited Safari’s Info.plist file to play around with some settings. Don’t ask, it’s an even longer story than this.

I take full responsibility for getting myself into this mess. I’ll certainly be more careful in the future to consider the implications of breaking code signatures on apps. However, I do think that the failure behavior could have been more informative. That NSLog I found in the console about refusing to prompt the user because of a broken code signature, could have been presented as a dialog that would instantly inform the user something is fishy. If my copy of Safari actually had been compromised by a nefarious individual, I wouldn’t have thought twice about continuing to enter my passwords and trying my damnedest to get Keychain to share my passwords with the compromised application.

On the other hand, I wrote an alternative years ago, called Usable Keychain Scripting. Its main advantage over Apple’s implementation is that it is (or at least, was) enormously faster. Today I updated the app to be 64-bit compatible and to fix a pernicious bug in which the password value returned for a keychain item would sometimes have garbage appended to the end of it.

Download Usable Keychain Scripting 1.0b4

This is not a supported product, and your success with it may vary. But it has been very handy in the past for me, and hopefully it will come in handy for you if you need to script the keychain.

Downloads used to be shown in a completely separate window, which could be toggled using the keyboard shortcut Cmd-Opt-L. In Lion, they appear in a popover panel attached to the toolbar of whatever browser window you happen to be using. Unfortunately, there is no keyboard shortcut to toggle the appearance of this popover.

Using FastScripts and a simple UI Scripting script, I was able to restore this functionality, so that Safari on Lion toggles the panel using the familiar Cmd-Opt-L shortcut.

Download the “Toggle Downloads Popover” script

Download the script, and copy it to:

[Home] -> Library -> Scripts -> Applications -> Safari

Here it will show up in FastScripts (or Apple’s script menu) only when Safari is the front-most app. You can also assign it a keyboard shortcut, like Cmd-Opt-L, that will only be active when Safari is active.

Important: If your Mac is not configured to run with English as the primary language, the script will not work without a minor adjustment. You will need to open up the script and change the text string “Downloads” to the language-specific description for the downloads panel in your language. For example, to make it work with Safari running in Spanish, you would change the string to “Descargas”.

I find it very useful to be able to popup the panel when I am checking on the status of a long download, or when I want to check quickly whether I already downloaded something I had intended to. Hope this script works well for you as well!

Apple has apparently taken advantage of the 64-bit runtime in Lion by optimizing the Objective C runtime itself to use some of these extra bits for, shall we say, clever purposes. Bavarious describes an optimization through which Apple is able to replace previously full-fledged opaque objects such as NSNumber with an object-placeholder that exists entirely as the 64-bit “object address” itself. This means that, for a wide range of “simple” objects, no additional memory allocation is required, and no retain/release memory management is required for the “object.”

The trick relies on a implementation detail of the system, that allocated blocks of memory will always be aligned at 16-byte offsets into the address space. This leaves a bunch of numbers that can be represented in 64-bits, that cannot reasonably be assigned to any other object. To understand this practically, imagine that your neighborhood’s postal addresses are all assigned at offsets of 10: 30, 40, 50, etc. A clever postal service could institute an addressing system that uses an “invalid” address such as “31,” to perhaps mean “deliver to 30 with expedited afternoon delivery.”

Cleverness like this with encoding extra information in memory addresses is a time-honored tradition. I recall the days of 24-bit addressing on classic Mac OS, where Apple, and many 3rd party developers, observed that the high 8 bits of a typical memory address could be tweaked and used to store additional information, because the system would never reference those bits when resolving a particular address.

In those days, using those extra bits turned out to be a pretty significant headache when 32-bit addressing ultimately came along, and lots of code had this “crufty” treatment of addresses to clean up. Perhaps it is a memory of situations like this that caused Jon “Wolf” Rentzsch to comment in his bookmarking of the above-referenced blog post:

“Every tagged pointer has its lowest bit set, hence tagged pointers are odd integers” Strikes me as a really bad idea. [Emphasis Mine]

But the difference now, in this scenario, is the “cute hacking” is all being done by a central power, with and in terms of opaque objects that only Apple has the authority to change. I think this is a really clever hack that will undoubtedly lead to some serious performance gains in Lion and beyond. It’s hard to imagine specific outcomes that will make Apple regret adopting this strategy. In the worst case scenario, an addressing system of future Macs will not leave any “spare” bits to be exploited, so the runtime will simply revert to its previous behavior.

As a developer, the obvious upside to using Core Data is Apple’s powerful framework manages most of the nitty-gritty details of managing the … well, the data your app uses both in memory and on disk. But giving up precise control over the storage and mangement of this data also becomes maddening when you run into problems: you’re not directly responsible for the management, so you’re less likely to know exactly what is going wrong.

I ran into a problem recently having to do with versioning of core data model schemas, and how good a job the frameworks do or do not do of automatically updating existing data that a customer may have on disk. In recent years Apple has made it increasingly easy to make minor changes to your model schema and having the frameworks handle the migration easily. Apple calls this trivial technique lightweight migration, and when it works well, it works very well. To modify your existing data model, you just add a new “version” of your xcdatamodel file, and add a few options flags when creating your persistent store:

NSDictionary *options =
   [NSDictionary dictionaryWithObjectsAndKeys:
   [NSNumber numberWithBool:YES],
     NSMigratePersistentStoresAutomaticallyOption,
   [NSNumber numberWithBool:YES],
     NSInferMappingModelAutomaticallyOption, nil];

[myPSC addPersistentStoreWithType:NSSQLiteStoreType
   configuration:nil URL:storeUrl
   options:options error:&error];

This actually works quite well for simple addition or removal of entity attributes, but you might be forgiven for assuming its completely freaking broken if you run into a problem I did, having to do with a stale “.mom” file being left in the built application’s bundle in the iOS simulator and on iOS devices.

Essentially, if you’ve been building your project up to now with a single, unversioned xcdatamodel file, and you convert it to a versioned xcdatamodel file, it will start producing a new “.momd” file in your application bundle, and stop producing the older “.mom”. But because of a bug in the way Xcode installs the application binary in the simulator and devices, it will leave existing files from previous builds where they were in the bundle.

If, like many folks, you use the convenient [NSManagedObjectModel mergedModelFromBundles:nil] method to initialize your managed object model, this will, to use a technical term, bite you in the ass. The problem is Core Data looks at the .mom and the .momd files as equally viable, and attempts to merge them into some cohesive whole. When it discovers they both redundantly describe the same entities, it blows a gasket with a runtime error like “Can’t merge models with two different entities named ‘MyEntity’”

I did some googling around and discovered that the simplest solution is to simply delete the iOS app from the device or simulator, ensuring that the next time you install, you get a pristine, clean copy of the app without the troubling “.mom” file. But there’s a huge problem with that: in deleting the app you also delete its associated data files, and thus are left in a position where you aren’t actually testing the ability of Core Data to effectively migrate from your previously versioned data.

On the simulator, it’s no problem to dive in and trash the problematic, stale file. You can find the application binary somewhere in:

[Home] -> Library -> Application Support -> iTunes Simulator

Once you’ve deleted the “.mom” file you can test with your new model and everything hopefully works great.

On the device, it’s not as easy (I think) to get in there and do pinpoint editing of the application contents, but I still wanted to test my changes against the real data on my device. I was also starting to get paranoid about the possibility of an App Store update at some point also causing a stale “.mom” file to be left in an app bundle, and wreaking havoc. So the 100% safe solution to make sure the one-true “.momd” file is consulted when building the Core Data object model, is to point directly at it:

NSString *momdPath = [[NSBundle mainBundle]
	pathForResource:@"MyModel" ofType:@"momd"];

NSURL *momdURL = [NSURL fileURLWithPath:momdPath];

managedObjectModel = [[NSManagedObjectModel alloc]
	initWithContentsOfURL:momdURL];

Hopefully seeding this solution into my blog will make it available for folks searching on similar failures in their Core Data projects.