Core Data without Fetch Requests

If you follow me on Twitter, you’re probably aware of a really nasty problem I encountered with versioned Core Data models. Suffice it to say that was two days of hell caused by a single Fetch Request in a .xcdatamodeld file.

The irony of it all is that I no longer use Fetch Requests this way: the queries defined in the model file weren’t being used so I was happy to delete them all.

In my opinion, fetch requests that are stored as a part of the managed object model have some downsides:

  • You need to carry around an instance of NSManagedObjectModel in order to access the requests.
  • A text-based search (such as Find in Workspace from Xcode’s Search Navigator) doesn’t find the requests.

Instead, I use a category for NSManagedObjectContext that adds some nice functionality for creating fetches and executing them purely with code. The original idea and implementation comes from Matt Gallagher.

A picture’s worth a thousand words, so let’s look at how this works in code. Instead of creating an “existingPartner” fetch configured as:

Fetch all: Partner objects where:
Expression: name == $NAME

I write this code:

NSArray *objects = [managedObjectContext fetchObjectArrayForEntityName:@"Partner" withPredicateFormat:@"name == %@", name];

If I need the managed objects in sorted order, there’s this variant:

NSArray *sortDescriptors = [NSArray arrayWithObject:[NSSortDescriptor sortDescriptorWithKey:@"name" ascending:YES]];

NSArray *objects = [managedObjectContext fetchObjectArrayForEntityName:@"Partner" usingSortDescriptors:sortDescriptors withPredicateFormat:@"name LIKE %@", pattern];

Getting count entity objects is just as easy:

NSNumber *salaryLevel = [NSNumber numberWithInteger:1000000];
NSUInteger count = [managedObjectContext countForEntityName:@"Employee" withPredicateFormat:@"salary > %@", salaryLevel];

After reading about how NSExpression can be used to significantly speed up fetches against attribute values, I extended Matt’s NSManagedObjectContext+FetchAdditions category. This lets you do things like this:

NSNumber *marketingPayroll = [managedObjectContext fetchObjectArrayForEntityName:@"Employee" usingAttribute:@"salary" andFunction:@"sum:" withPredicateFormat:@"department == %@", marketing];

One thing to keep in mind when you’re using NSExpression against a SQLite store: it only works on data that has been persisted. Since the underlying implementation relies on SQL functions such as min(), max() and sum(), any managed objects that you have in memory (because the context hasn’t received a -save) won’t be included in the results.

One final trick I use is to keep the code for these fetches as close to the objects and attributes as possible. I’ve found it very handy to create class methods in the NSManagedObject subclasses. For example, using our partner name example from above, I’d implement the following class method for the Partner object:

+ (Partner *)fetchInManagedObjectContext:managedObjectContext withName:(NSString *)name
{
	Partner *result = nil;
	
	NSArray *results = [managedObjectContext fetchObjectArrayForEntityName:@"Partner" withPredicateFormat:@"name == %@", name];
	if ([results count] > 0) {
		result = [results lastObject];
	}
	
	return result;
}

Then when I need a Partner with the given name, I use:

Partner *partner = [Partner fetchInManagedObjectContext:managedObjectContext withName:@"CHOCK GLOBAL INDUSTRYS INK"];

I hope this category cleans up your code as much as it has mine. Feel free to use this code in any way you see fit.

VMware for developers

Many of us rely on VMware Fusion for testing our products both on older and newer versions of Mac OS X. Your development machine may be running Lion, but it’s incredibly handy to run both Snow Leopard and Mountain Lion on the same machine.

With the recent release of Mountain Lion DP2 some problems cropped up with Fusion 4.1 (you’ll need a developer account to view that link.) Luckily the new VMware Fusion Technology Preview 2012 makes it possible to run the latest Mountain Lion release without any problems. This preview release also allows you to keep Fusion 4.1 installed if you encounter any problems in other virtual machines: the only requirement is that you can only run one version at a time.

Also worth nothing: if you used the bug in VMware Fusion 4.1 to create a virtual machine that uses the client version of Mac OS X 10.6, you’ll be disappointed as soon as you try to restart that VM in the Technology Preview. During the reboot, you’ll see a window pop up with the message:

The guest operating system is not Mac OS X Server. This virtual machine will be powered off.

You’ll need to keep VMware Fusion 4.1 around if you want to apply Software Updates to your test environments.

I wish Apple would relax this restriction with the 10.6 clients: we still have products that rely on older versions of Xcode. Apple themselves even have sample code that can’t be opened in Xcode 4, preventing developers from exploring older, but useful, projects.

Sandboxing

The recent release of xScope 3.0 is our first product to use the new application sandbox that will soon become a requirement for submission to the Mac App Store. I’d like to share some experiences and advice on how to use it in your own products.

First off, Ivan Krstić and the rest of the team at Apple have done a great job in making the whole process easy to implement. Adding entitlements and signing your code will be the least of your worries as you transition to the new sandbox.

Of course there are some applications that have a harder time than others: primarily if those apps require access to all or part of the filesystem (think about syncing data with Transmit, for example.) Apps that make use of AppleScript for inter-app communication will also have a difficult time: this includes our Take Five app. Apple is actively listening to developers who are encountering these types of issues, so if you haven’t filed a Radar yet, quit bitching.

Speaking of Radar, we encountered a fairly nasty problem after launching xScope. Many of our customers are designers and developers who love SSDs. It’s common to use a symlink in your Home folder to put big datasets like Pictures, Music and Movies on a separate hard drive. When you do this, folder access in the application sandbox container breaks. A small number of users who use symlinks are also getting crashes after launching the app that was downloaded from the Mac App Store:

xpchelper reply message validation: sandbox creation failed: 1002
Container object initialization failed: The file couldn’t be opened.

We also encountered a problem when using Sparkle to update an app running in a sandbox: an app can’t update its own binary. Changing Sparkle so that it uses an XPC service is a major architectural change, so we decided to remove the sandbox for the version we distribute on the website.

Besides being the path of least resistance, it also gives us a version of xScope that doesn’t run into the sandbox bugs reported above. I highly recommend that you give yourself this option for any customers that experience sandbox related problems.

All things considered, adding an application sandbox has been a fairly smooth transition. But it’s also clear that we’ve only just begun putting the genie back in the bottle.

Updated January 27th, 2012: The bug reported above is a duplicate of Radar 9865143.

Homebase

A lot of people I know and respect have been commenting on problems associated with the iPhone mute switch:

John Gruber – On the Behavior of the iPhone Mute Switch
Andy Ihnatko – Unmuting on The Mute Question
Marco Arment – Designing “Mute”
Guy English – Mute This

Both sides of the argument have valid points-of-view. This really is a situation with no right answer given the current mechanisms.

That got me thinking that there might be something missing that’s causing this ambiguity. I’ve come to the realization that this is a problem bigger than just alarms going off at inopportune moments. What we really want is for the devices in our pocket to behave differently depending on where they’re physically located.

Let’s imagine a new feature in iOS called “Homebase”. A user would be presented with a simple UI that lets them select a location that’s a “safe” environment. After the setup is complete, your Homebase would be recognized by GPS coordinates and/or available Wi-Fi networks. The important thing here is that the user gets to define where they feel safe with their device.

With that information developers can make smarter decisions:

  • Alarms that go off while the mute switch is on make noise at Homebase and just vibrate elsewhere. There’s no need to worry about alarms going off in public places (such as concert halls) and you won’t oversleep when you go to bed with a mute switch on.
  • The lock screen doesn’t need to display a Passcode lock at Homebase. People who use the Remote app with their Apple TV will no longer be annoyed by an unnecessary security precaution, nor will folks forget to turn their Passcode lock back on when they leave for the local bar (where they’re certain to get a Poopin’ tweet.)
  • Apps, like Find My Friends, could use cached Apple ID credentials at Homebase and avoid asking the user for them over and over and over and over again.

Of course, this feature is needed most by people who don’t even know the Settings app exists. It’s my opinion that if developers are careful with this additional knowledge about the user and device, default behavior can be adjusted appropriately without additional confusion. It’s analogous to the Energy Saver on the Mac: people don’t question why the screen dims when the power cord is removed because it just “makes sense”.

The examples above use Apple’s own apps, but the Homebase status would be useful for third-party developers, too.

If you’d like to see something like Homebase in iOS, please be sure to file a duplicate Radar.

Un-Trusteer-ed

The bank we use for our business account recently mandated the use of a product called Trusteer Rapport while accessing our information online. Although Mac OS X doesn’t have any problems with “increasingly sophisticated malware in the online environment”, I do need to periodically check our accounts and transactions so I proceeded with the installation.

The first warning sign was after starting the Installer: I was prompted for an administrator password indicating that this software wanted to run from protected areas of my system. Being a developer, I immediately dug into the installer scripts and configuration files to see that the app is placing items in the Rapport/bin, PreferencePanes, LaunchDaemons and LaunchAgents folders of the main system Library folder. The launch folders indicate that the software will be run whenever my Mac is restarted and will be able to do things a normal user would not (because of elevated permissions.)

I placed my security concerns aside as I need to access my bank website, so I went ahead with the installation. Afterwards, I was directed to a web page describing the new software.

Again, as a developer, my first thoughts were suspicious ones. From experience, I know that it’s not easy to modify Safari’s user interface in the way that Trusteer was doing. My guess that there would be a new, always active, background process was confirmed by the presence of “rooksd” in my process list.

However what happened next really opened my eyes. Safari crashed.

Of course that, in and of itself, isn’t the end of the world. But I was surprised to see a new library named RapportUtil1 while looking at the Safari crash report. It was pretty clear that the new Trusteer software caused the crash. But how?

As a longtime Objective-C developer, I know a thing or two about “method swizzling“. In a nutshell, this allows a developer to replace the functionality of code they don’t have direct access to (typically in the system or other frameworks.)

Seeing “_nsapplication_sendEvent_override” tells me that Trusteer is using this technique to change the behavior of Safari. The function that is being affected is -sendEvent: — the part of every Cocoa application where mouse, keyboard and other input is routed.

Method swizzling is a dangerous activity. You have to make assumptions about how some other code, that you’ve never seen, is behaving. You also need to think about how that code might change in future versions. There are extreme cases where this technique can be effective: overriding the default behavior of my web browser is not one of them.

It’s clear that the folks taking control of my browser aren’t as clever as they think. Do you see a common theme when you search Apple’s discussion forums for “RapportUtil1“?

Even more troubling is the method being overridden: every key press or mouse movement is first being sent to Rapport and then forwarded onto Safari. Since this happens often, the intruding software can do pretty much whatever it wants, whenever it wants. And remember that part of this package is running with elevated permissions in the background.

After mentioning my findings on Twitter, I got back some very interesting replies. Graham Lee (@iamleeg) pointed out that I’m not the first developer to question the technical merits of this software. But then Peter Hosey (@boredzo) dropped the real bomb. Trusteer tacitly admits to recording my password. That’s easy to do when you take control of -sendEvent:.

Essentially, my bank is asking me to install is a keylogger. Just so they can warn me not to use the same password on suntrust.com and playboy.com.

Hopefully, the engineers behind Rapport are smart enough to be using hashed passwords rather than clear text. And hopefully none of the personal information Safari has access to is being forwarded to the Trusteer servers. And hopefully they’re not recording how many times I visited playboy.com last month. But that’s beside the point, because as a closed source product, no one can audit their activity. That’s not true with Safari.

Oh, and there’s one other thing: the Rapport software isn’t supported on Lion. One of the tenets of method swizzling is to test your software early and often with any new release of the system or framework that it’s modifying. As a developer, you need to be proactive about fixing any problems that pop up in the code you are overriding. Not doing so is irresponsible and puts your users at risk. The last update for Rapport was in 2009.

(One could speculate that the new privilege separation architecture for Safari in Lion is causing Trusteer’s developers a lot of headaches. The other tenet of method swizzling is to remember that it’s not a matter of if your hack will break in the future, but rather when it will break and how painful it will be to fix.)

Needless to say, I have uninstalled this software and will never be installing it again. I would recommend this course of action to any end user.

But that leaves me with a problem: how do I access my bank’s website? I have three options:

1) Find another bank. This is a difficult choice, as there are many systems that are hooked up to this account: ACH transactions for sales via iTunes, bi-weekly payroll, automatic payments for services, etc. I’d also like to give SunTrust a chance to reconsider their position in requiring this software (they will be getting a copy of this report.)

2) Use the telephone. I can call the bank when I need the information. Sure they’ll get tired of hearing from me, and it will cost them more for customer service, but it’s their choice to require Trusteer Rapport.

3) Run the Trusteer Rapport software in locked down environment. Once it’s supported on Lion, it should be possible to create a virtual machine that that will only be used to access the bank website. Needless to say this is inconvenient, a waste of resources, and severely limits my ability take advantage of my bank’s services.

In closing, I’ll leave you with one final irony: I will never be able to access my bank’s website from what is arguably the most secure computing device in existence today. That’s because the iPad is not a supported platform. Apple only allows third-party applications to run in a secure sandbox where they can’t affect other applications or the operating system. What you’ve seen above is exactly the reason they’ve done this.