In the Apple Developer Library, it explicitly states that for MacOS applications take both the Language and Regional preferences of the user into account, but only look at the preferred language on iOS – Support for Internationalization. This means that a single variant per language is supported.

However, these is a way around this. I’m not sure if this is a good thing to do, but it works for me and I haven’t noticed any ill side effects yet.

To support both US English and British English in your iOS application, create 2x Localization.strings files just as you would for multiple language. Put the US English translation file Localization.strings in a directory in your iPhone app called English.lproj (Apple defaults) and the British English translation in a directory named en_GB.lproj (just in case they decide to support regions in the future).

Then, you’ll need to create some code to manually set the preferred localization. In your main.m file (yup, main.m is being edited) alter it so it performs some logic similar to below.

int main(int argc, char *argv[]) {
	NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
	NSString *language = [[NSLocale preferredLanguages] objectAtIndex:0];
	NSString *locale = [[NSLocale currentLocale] objectForKey: NSLocaleCountryCode];
	if ([language isEqualToString:@"en"] && [locale isEqualToString:@"GB"]) {
		[[NSUserDefaults standardUserDefaults] setObject:[NSArray arrayWithObjects:@"en_GB", @"en", nil] forKey:@"AppleLanguages"];
	}
	int retVal = UIApplicationMain(argc, argv, nil, nil);
	[pool release];
	return retVal;
}

When the line

int retVal = UIApplicationMain(argc, argv, nil, nil);

gets executed, it seems to set up all the Localization bundles before calling the application:didFinishLaunchingWithOptions method on your app delegate, so putting Localization code in the app delegate is too late. So, what the code above does is retrieve the users current language and region, and compares those against pre-determined values – en for the language and gb for the region. If these match, then I force a new setting in the NSUserDefaults to overwrite the users preferred language. Then, when the UIApplicationManager function gets called, it appears to retrieve the users preferred language setting, and look up the Localization for that – which in my case I’ve forced to be en_GB.

One thing you need to be careful about is persistence of this NSUserDefault setting. It is saved once it’s set, and persists through multiple application executions. To get around this (lets say the user changes their region back to US), you need to remove the setting after the bundle initialization has taken place. In you app delegates application:didFinishLaunchingWithOptions method, just execute the following code.

[[NSUserDefaults standardUserDefaults] removeObjectForKey:@"AppleLanguages"];

This wipes out the NSUserDefault setting that the app made in the main.m file.

If anyone knows of issues with this approach (apart from being a dirty hack), or faults with my code please let me know in the comments below. I wish Apple supported different regions per language natively in iOS but they don’t. This is the only way I’ve found to do this, and continue to use localization functions such as NSLocalizedString.

How frickin’ exciting!

Seriously, WTF? I assume it’s some sort of movie tie-in…

- (NSInteger)age:(NSDate *)dateOfBirth {
  NSCalendar *calendar = [NSCalendar currentCalendar];
  unsigned unitFlags = NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit;
  NSDateComponents *dateComponentsNow = [calendar components:unitFlags fromDate:[NSDate date]];
  NSDateComponents *dateComponentsBirth = [calendar components:unitFlags fromDate:dateOfBirth];

  if (([dateComponentsNow month] < [dateComponentsBirth month]) ||
      (([dateComponentsNow month] == [dateComponentsBirth month]) && ([dateComponentsNow day] < [dateComponentsBirth day]))) {
    return [dateComponentsNow year] - [dateComponentsBirth year] - 1;
  } else {
    return [dateComponentsNow year] - [dateComponentsBirth year];
  }
}

ARGeoViewController as the overlay on a ImagePickerController on iPhone

I want to tidy up some of the code before I check it back into my clone of the source, but this is a really good basis for some smart location and direction aware augmented reality apps on iPhone.  Wonder what the iphonearkit license is – it’s unclear…

— EDIT —

Bugger.  It appears that zac has implemented similar functionality to me already  Bloody github and it’s slow (never!) updates to fork queues and network graphs.  Oh well, maybe I won’t bother tidying my code.

Marker with no overlaid image

Blue cube over the Hiro marker

Next up, something more substantial.

My 4th iPhone application was approved yesterday by Apple, and it launches in the iTunes store today. It’s called Kit Quiz: UK and is a UK team based football (soccer) shirt quiz game. It features over 130 shirts from UK football teams, and will have more added shortly.  There are 3 modes of gameplay, from the practise model “Friendly” to a time challenge “Blitz”.

It’s integrated with Twitter and Facebook so you can check out your friends scores and find out once and for all who can recognise the most football shirts.

Couple of screenshots below for anyone interested.  Download it now!

Kit Quiz: UK menu screen

Kit Quiz: UK - Blitz screen

</shameless self promotion>

The situation I was finding was that PHP apps would run, but only if you explicitly call the script (ie index.php) rather than just the directory. If you called the directory, passenger would take over and give me a rails routing error.

The issue was to do with the passenger vhosts configuration. On my machine I have an number of ruby on rails apps configured with the passenger preferences pane (creating vhost entries within /private/etc/apache2/passenger_pane_vhosts/. I have enabled user_dirs, so that the users of my machine’s pages (and other apps) are served from their ~username/Sites directory.

My users configuration info for apache is installed in /private/etc/apache2/users/, and the instructions to load the configuration from that directory is stored within /private/etc/apache2/extra/httpd-userdir.conf (content below).

# Settings for user home directories
#
# Required module: mod_userdir
#
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.  Note that you must also set
# the default access control for these directories, as in the example below.
#
UserDir Sites
#
# Users might not be in /Users/*/Sites, so use user-specific config files.
#
Include /private/etc/apache2/users/*.conf

To get everything working together nicely, I merely wrapped this inside a vhosts configuration directive, and gave it a ServerName of localhost – so that this vhost would be the one that responds to requests for localhost, rather than some random passenger vhost assuming it was the boss of everything. New /private/etc/apache2/extra/httpd-userdir.conf below.

<VirtualHost *:80>
  ServerName localhost
  UserDir Sites
  Include /private/etc/apache2/users/*.conf
</VirtualHost>

Thanks to this, all of my rails apps are served under passenger, and I can have static HTML, PHP and camping apps (previously configured – nothing to do with the above) all served from within my ~username/Sites directory.

Hope this helps someone.