I created a new iPhone project today and got a rather vague error message from Xcode when I tried to run it on a device:

Error launching remote program: security policy error

After some digging it turns out that the problem was that I had two provisioning profiles on the device: - a wildcarded one (which had expired) that I use for quick hacks that don’t warrant going through the hassle of setting up new provision profiles - one created specifically for this application

The wildcarded profile had expired, and for some reason the iPhone was trying to launch the app with the expired profile even though it had a valid profile that it could have used. Deleting the expired profile from the device did the trick. If only that error message had been a bit more explicit …

After much toiling kgb’s first iPhone app is on sale! Get it now. Only in the US unfortunately.

For the record, we submitted two versions of the app: an earlier version that we didn’t expect to release (we wanted to see what the approval process was like and if apple was OK with the basic idea of our app) and the one that is on sale today. Both were approved in about 10 days - no approval horror stories here!

This is probably obvious, but in the interest of saving someone else the few minutes I spent scratching my head on this one…

Your app probably has some code that looks like

1

managedObjectModel = [[NSManagedObjectModel mergedModelFromBundles:nil] retain]

If you pass nil then the main bundle is searched. When your an iphone app, that is the app itself - no surprises there. But when you are a unit test bundle, you are no longer the main bundle (the test rig application is). You need to tell CoreData to look inside your unit test bundle, with something along the lines of

1
2

managedObjectModel = [[NSManagedObjectModel mergedModelFromBundles:
[NSArray arrayWithObject:[NSBundle bundleWithIdentifier:@"com.yourcompany.unittests"]]] retain];

For this to work you also need your data model to be present in your unit test bundle. For some reason, unlike your .m files the inspector doesn’t show you a list of targets the model should be included in - you need to drag the data model file into the compile source build phase of your unit test target.

I recently needed to deal with ssl connection using client side certificates. The ruby openssl bindings are fairly impenetrable, here’s what worked for me (at least in part as a note for myself in the future)

1
2
3
4
5

ctx = OpenSSL::SSL::SSLContext.new
ctx.cert = OpenSSL::X509::Certificate.new("mycert.cer")
ctx.key = OpenSSL::PKey::RSA.new("mykey.pem")
ssl = OpenSSL::SSL::SSLSocket.new(sock, ctx)
ssl.connect

If the key you’ve got is a .p12 file (which is what the key chain utility on the mac exports) then you’ll need to convert it like so

openssl pkcs12 -in key.p12  -nocerts -nodes -out key.pem

Quite a few people have written about the performance failings of Net::HTTP, but until recently, to be honest, I never really cared a lot. Most of my http request needs have been fairly meagre, often not much more than hitting a url and checking the result code.

I’ve been playing with couchdb recently, and so my app does a fair amount of http requests. I’ve been using RelaxDB which uses net/http, so Net::HTTP’s performance has started to matter.

Net::HTTP is not the only game in town. I spent some time recently playing with rfuzz, eventmachine and taf2-curb and came to largely the same conclusion as Paul Dix.

Leaning on a mature library such as libcurl gives taf2-curb a huge advantage. While eventmachine was on par speed wise, neither of the 2 http clients it includes are a complete implementation of the HTTP protocol. For example HttpClient will tell the remote server that it speaks HTTP/1.1, yet it does not support chunked encoding (mandatory part of the spec). HttpClient2 does understand chunked encoding, but doesn’t let you set headers or a body to the request. Fine for just pinging a url, but not up to the task of working with couchdb. Something to do with couchdb’s chunk encoded also seemed to confuse rfuzz.

taf2-curb does the job very nicely. On my dumb benchmark, 1000 requests for a static html page hosted on the same machine (ie we’re pretty much only testing overhead) the numbers are:

1
2
3
4
5
6
7
8
9
10
11
12
13

Benchmark.bmbm(5) do |x|
  x.report 'net/http' do
    u = URI.parse('http://docs.local/')
    1000.times {Net::HTTP.get u}
  end

  x.report 'curb' do
    1000.times do
      c = Curl::Easy.new 'http://docs.local/'
      c.perform
    end
  end
end

               user     system      total        real
net/http   0.560000   0.270000   0.830000 (  1.065960)
curb       0.310000   0.170000   0.480000 (  0.696188)

On the other extreme, these numbers corresponds to ~1 meg of data pulled from couchdb (benchmark code the same apart from the urls, and I did 100 iterations rather than 1000).

               user     system      total        real
net/http  17.400000   8.900000   2.630000 (  32.067821)
curb       0.700000   1.300000   2.000000 (  29.586022)

curb comes up squarely on top. Another thing of note during this test is cpu usage (as you might expect from the difference in user time). With Net::HTTP the ruby process running this was taking up 60-70% (on a 2.4GHz core duo), with curb it used around 5% of cpu.

The commit to switch RelaxDB from net/http to taf2-curb is here for those interested - really very straightforward stuff. There may well be more to be had by fiddling with libcurl options, I haven’t tried yet.