MultiNC develops iPhone applications for a number of global markets, and sometimes we run into bugs unique to globalized applications.  One application that we’re developing has France as primary market.  U.S. users very rarely change their settings from the usual 12-hour mode (AM/PM mode) to 24-hour mode.  However, in France it’s not rare for users to switch from the more common 24-hour mode to 12-hour mode.  And that’s when things start acting strange, even causing your application to crash.

Because of users’ regional habits, developers of globalized applications are more likely to encounter this time bug than for US applications.

Region format & 24-hour mode setting

First, a little background on the iPhone user interface.  When iPhone users change their region format between, say, “United States” and “France”, the users’ “24-Hour Time” setting is automatically switched to the mode that is most prevalent in that region.  In France, that would set 24-Hour Time to “ON”, and in the U.S., that would set it to “OFF”.  The users can then manually override that setting and that’s where trouble starts.

NSDateFormatter bug

The pattern of this SDK bug was relatively tricky to determine because of the specific combination and sequence of user settings that would trigger it, but now it’s actually quite simple to explain.

The problem comes from NSDateFormatter somehow “getting stuck” in the 12 or 24-hour time mode that the user has manually selected.  So if a French user manually selects 12-hour mode,  and the application requested NSDateFormatter to output time with the 24-hour format “HHmm”, it would actually receive time in a 12-hour format, e.g. “01:00 PM”, as if the application had instead requested “hhmm aa”.  The reverse would happen if a US user manually selected 24-hour mode: outputting time with the 12-hour  format “hhmm aa” would actually get you time in the 24-hour format instead, e.g. “17:00″.

This bug turns especially nasty when your application is trying to parse time from a string, rather than outputing.  Similar to the above, the NSDateFormatter seems to be stuck in the time mode that the user has manually chosen and insists on reading time that way, regardless of the string format.  What you can end up with is an incomplete or invalid NSDate, which when later used can cause other parts of the application to crash, as the UIDatePicker did for us.

We are developing with the iPhone SDK version 3.1 beta, but we wouldn’t be surprised if it applied to all previous SDKs.

Workaround

Now that you know the source of the bug, a workaround is straightforward.  But to save you time until Apple fixes it, with our client faberNovel’s gracious permission, here’s our workaround when dealing in 24-hour time (dealing in 12-hour time would be very similar):

// Returns time string in 24-hour mode from the given NSDate
+(NSString *)time24FromDate:(NSDate *)date withTimeZone:(NSTimeZone *)timeZone
{
	NSDateFormatter *dateFormatter= [[NSDateFormatter alloc] init];
	[dateFormatter setDateFormat:@"HH:mm"];
	[dateFormatter setTimeZone:timeZone];
	NSString* time = [dateFormatter stringFromDate:date];
	[dateFormatter release];
 
	if (time.length > 5) {
		NSRange range;
		range.location = 3;
		range.length = 2;
		int hour = [[time substringToIndex:2] intValue];
		NSString *minute = [time substringWithRange:range];
		range = [time rangeOfString:@"AM"];
		if (range.length==0)
			hour += 12;
		time = [NSString stringWithFormat:@"%02d:%@", hour, minute];
	}
 
	return time;
}
 
// Returns a proper NSDate given a time string in 24-hour mode
+(NSDate *)dateFromTime24:(NSString *)time24String withTimeZone:(NSTimeZone *)timeZone
{
	int hour = [[time24String substringToIndex:2] intValue];
	int minute = [[time24String substringFromIndex:3] intValue];
	NSDateFormatter *dateFormatter= [[NSDateFormatter alloc] init];
	[dateFormatter setTimeZone:timeZone];	
 
	NSDate *result;
	if ([Util userSetTwelveHourMode]) {
		[dateFormatter setDateFormat:@"hh:mm aa"];
		if (hour > 12) {
			result = [dateFormatter dateFromString:[NSString stringWithFormat:@"%02d:%02d PM", hour - 12, minute]];
		} else {
			result = [dateFormatter dateFromString:[NSString stringWithFormat:@"%02d:%02d AM", hour, minute]];
		}
	} else {
		[dateFormatter setDateFormat:@"HH:mm"];
		result = [dateFormatter dateFromString:[NSString stringWithFormat:@"%02d:%02d", hour, minute]];
	}
	[dateFormatter release];
 
	return result;
}
 
// Tests whether the user has set the 12-hour or 24-hour mode in their settings.
+(BOOL)userSetTwelveHourMode
{
	NSDateFormatter *testFormatter = [[NSDateFormatter alloc] init];
	[testFormatter setTimeStyle:NSDateFormatterShortStyle];
	NSString *testTime = [testFormatter stringFromDate:[NSDate date]];
	[testFormatter release];
	return [testTime hasSuffix:@"M"] || [testTime hasSuffix:@"m"];
}
 
// Converts a 24-hour time string to 12-hour time string
+(NSString *)time12FromTime24:(NSString *)time24String
{
	NSDateFormatter *testFormatter = [[NSDateFormatter alloc] init];
	int hour = [[time24String substringToIndex:2] intValue];
	int minute = [[time24String substringFromIndex:3] intValue];
 
	NSString *result = [NSString stringWithFormat:@"%02d:%02d %@", hour % 12, minute, hour > 12 ? [testFormatter PMSymbol] : [testFormatter AMSymbol]];
	[testFormatter release];
	return result;
}

References:

• StackOverflow – NSDateFormatter, am I doing something wrong or is this a bug?

If you’re developing an iPhone application that you intend to submit to Apple’s App Store and you want to make use of a third-party’s software library that happens to be licensed under the GNU Lesser General Public License (LGPL), you have a couple of choices according to the license requirements:

• You can open-source your app.  Specifically, you provide to your users the source code of your entire application under the LGPL or GPL.  That means for example all the .h and .m files.
• You can keep your app closed-source, but you provide to your users all the object code of your  application necessary to re-link your application.  That means for example all the .o and .a files.  Most people forget that this option is in fact available to iPhone app developers.

Of course, if you modify the library itself, you have to provide these code changes in source form either way.

Dynamic/Shared Library

The above LGPL conditions can be thought to apply to the case when the LGPL library is statically linked.

But outside of the world of Apple’s App Store, the LGPL would normally give you another way to use LGPL code without releasing the source code or object code for your application: compiling your application with a run-time shared library (hence, allowing users to run your application with an updated library if they choose to).  The problem for us is that the Apple iPhone developer agreement doesn’t allow the bundling of shared libraries.

If you don’t care about the App Store and want to release/sell your application through Ad Hoc Distribution or to jailbroken devices (e.g. via Cydia), you can actually link apps with a run-time shared library and thus satisfy the LGPL without providing source code or object code.

Static Library Exception

Some library developers are aware of these iPhone and LGPL incompatibilities and provide a “static library exception,” loosening LGPL requirements for the iPhone platform.  For example, the cocos2d author intended to offer such an exception: even though he neglected to distinguish between the source code and object code requirements of the LGPL, it’s fairly clear he intended to relieve the app developer from having to provide source or object code even if they linked in the LGPL library statically.

It’s a good idea for you to consider contacting the author of the LGPL library you’re interested in to offer a similar exception for the iPhone.  That way you don’t have to worry about having to provide object code for your app.

Spirit of the LGPL

Whether you decide to release the object code for your app or take advantage of a “static library exception,” the spirit of the LGPL is violated by the iPhone restrictions: it becomes very difficult for your app user to customize your app with a modified or updated version of LGPL library.

Let’s say you do release all the object code and all the utilities that your app requires to build a new app based on an improved LGPL library.  How can your users install the new binary?  They are faced with the following unhappy options:

• Jailbreak their iPhone to install any binary that they want
• Join the iPhone Developer Program for $99 a year to be able to legally distribute “Ad Hoc” the new app to up to 100 devices.

In other words, you may end up spending a lot of time distributing object code to satisfy the LGPL and protect the source code of your app, but the object code is very unlikely to get used anyway.

In fact, even if Apple allowed apps to link with dynamic shared libraries, how could users even substitute the libraries without jailbreaking their iPhone?

No wonder the Free Software Foundation hates the iPhone.

References:

• GNU Lesser General Public License, particularly section 4.d)
• StackOverflow – Which open source licenses are compatible with the iPhone and App Store?
• Nabble – iphone, and releasing object code satisfies LGPL Re: Static building and bundling of SDL.
• Nabble – iPhone SDK <-> SDL License

Before this will work, you may have to ensure the following:

In Windows, the “Apple Mobile Device” service must be running
You should enter the Passcode on your iPhone or iPod Touch
The device must be jailbroken if you want to see anything outside the Media folder, e.g. if you want to see the root folder.

When the iPhone SDK came out in March 2008, mobile developers were very excited to be able to develop native applications for the increasingly popular device.  However, that excitement was partially tempered by some requirements of the platform, which for most meant learning how to program Objective C, a language that only Mac developers are familiar with.  Just as with iPod users, iPhone application developers do come from all walks of life–they’re not all Mac die-hards.

As as result there have been several efforts to produce a framework or tool with which applications could be developed using more familiar languages. Rhodes does this for Ruby programmers. XMLVM does this for Java programmers.

XMLVM

I watched the Google Tech Talk about XMLVM, which goes into significant depth about the conversion process.  Essentially, the technology does cross-compilation from the compiled version of your Java application, in other words JVM bytecode instead of Java source code. Thus, the entire process of compiling an iPhone application would consist of Java source -> JVM bytecode -> Objective C source -> native iPhone binary.  The speaker goes into detail with an example showing the conversion of JVM bytecode into Objective C source, which is easy to understand and can be educational.

Opting for bytecode as source for XMLVM makes it easier to implement but produces bloated code.  Not only that, but the bytecode is converted not into native iPhone native code, but into Objective C source code.  Add to that that the conversion is done using XSLT, and you can guess how inefficient the process and the output will be.

The speaker emphasizes that this is an academic project without abundant resources, with the implication that the code produced by this reference implementation is not expected to perform well for commercial purposes.  So while it’s interesting to see this idea in action, not even the speaker believes that this cross-compiler can be put to serious use yet, if ever.

Other languages for the XMLVM

Java is not the only source language that can benefit from XMLVM.  There is support for other input languages and output code.  See the website for more information.

Enhancing the iPhone emulator with hardware data

One nice tool that the XMLVM team developed was a way to send device data to the desktop emulator, which naturally cannot emulate everything that the iPhone can do.  For example, you can use a real iPod Touch or iPhone to send accelerometer to the emulator.  The same could be envisioned for other functionality, e.g. GPS, light sensor, proximity sensor, etc.  I imagine this is so helpful for the development process that others must have implemented something like that as well.

Better to Develop in Objective C

My opinion regarding these kinds of language-adapting frameworks or tools that allow developers to code in their familiar language is not very positive.  In general, I don’t think it’s a good idea to distance yourself from the target platform.  Problems include:

• Limited functionality
• Lower performance
• More complicated development process
• More source of bugs in your way (from not just the iPhone OS and SDK, but from the language adapter)
• Smaller community of developers, fewer development tools, less documentation

All these problems are multiplied when you’re dealing with a hot platform like the iPhone, where innovation comes fast along with bugs and the language adapter is always one or more steps behind on completeness, robustness, and performance optimization.  Do you really want to develop cool apps with only features that are “so last year”?  The fact that the iPhone platform and its evolution are so closed doesn’t help either.