Mac App Store Receipt Validation Sandbox – cannot connect

If the Mac App Store sandbox answers your attempts to log in (and obtain a test purchase receipt) with a “Cannot connect” error then you have to first log in with the Apple ID associated to your developer account where the sandbox user is registered.

So open the Mac App Store and perform a simple customer log in with your developer Apple ID. After that obtaining a debugging receipt with your sandbox account shouldn’t return any “can’t connect” errors.

This little quirk cost me today a lot of time. First I assumed the sandbox was down. I only accidentally discovered the solution to this problem.

NSView’s -setNeedsDisplay: is not thread safe

One could assume such a trivial task like setting a BOOL (which is all that setNeedsDisplay does) would be thread safe. Well, it isn’t as I found out after a rather long debugging session. (With individual debug runs going up to 2 hours till the bug showed up).

If you get really unlucky and set the flag to true when the Cocoa drawing thread is doing its work the drawing thread will hang/crash. Event dispatch, your main thread, everything else will work – only your interface won’t get updated (your views’ -drawRect: methods won’t get called). A rather weird bug.

So call -setNeedsDisplay: only on the main thread. Luckily GCD makes that pretty straightforward:

dispatch_queue_t q = dispatch_get_main_queue();
dispatch_async(q, ^{
  [view setNeedsDisplay: YES];

Building PortAudio under OS X 10.7 Lion

The current SVN snapshot can be built under Lion but it has some quirks you have to fix first:

1. Edit include/pa_mac_core.h and uncomment the #inclusion of AudioToolbox.h (around line 49).

2. Run ./configure with your options.

3. Edit the Makefile and remove ‘-wError’ from the CFLAGS line.

Now you can type make and everything should build. (Don’t forget to strip PPC code from the generated fat lib (man lipo) if you’re planning to submit to the Mac App Store!)

Disabling ARC on a per file basis

ARC is fine as long as you don’t do fancy stuff. Luckily you can disable ARC on a per file basis so that most of your code can benefit from ARC and the more complex stuff can be manually handled by you.

To disable ARC for a file (or a group) select your project in Xcode 4, go to the “build phases” tab and select the files you want to disable ARC for. Add then the -fno-objc-arc compiler flag to these files.

ARC will be now disabled for the chosen files and you can retain/(auto)release as you desire :)

Localizing iOS/OS X apps [quick reminder]

This is a little reminder about iOS/OSX app localization for myself. I don’t localize apps too frequently so I always forget the details and have to google around. This shall be a quick reminder for myself:

To localize sourcecode strings
Add a new .strings file to project and call it “Localizable.strings”. Click on it and add a desired target localization. Let’s take german (de).
Then in the terminal (for our german example):

$ genstrings -o de.lproj *.m

To localize interface builder files (nib/xib):
First make the desired nib localizable. Then create a strings file for translation. Do this by firing up the following command in the terminal.

$ ibtool --generate-strings-file SomeXibStrings.strings en.lproj/SomeXib.xib

Then translate the generated “SomeXibStrings.strings”.

To create a translated nib:

$ ibtool --strings-file SomeXibStrings.strings en.lproj/SomeXib.xib --write de.lproj/SomeXib.xib

It’s good practice to save the translated files into the lproj folders so you have them at hand when you need to regenerate the IB files.