Stormy's RadioKit SDK licensing

I am happy to announce there is now a fairly low-cost method available for other developers to license our iPhone radio steaming technology for their own apps. At just $100 per app project, you can include the same radio streaming technology that is powering the Radio Paradise and Tunemark Radio apps (as well as scores of other radio apps).

This RadioKit SDK includes full support for time-shifting a live stream, allowing pause, rewind, and fast forward back to the live stream. It also includes our robust dropped connection handling which can seamlessly restitch together the old buffer with the new stream, which often eliminates any interruption in listening even though the data connection had been completely dropped.

Aren't sure if the SDK is worth $100? You can test it in an XCode demo project with no financial obligations. When installed on a device (iPhone or iPod Touch), the audio streaming portion of the demo will only function for 10 minutes at a time, however you can test the SDK without any time limits using the simulator.

The SDK is licensed on a per-app project basis, meaning you must purchase a license key tied to each unique iPhone app bundle ID. Volume discounts for license keys are available for those who may be interested in using this SDK in a large number of projects.

You can read more about Stormy's RadioKit SDK at http://www.stormyprods.com/products/radiokit.php

Browsing photos and videos on your iPhone via your Mac

Since owning an iPhone 3GS, I've accumulated quite a few videos captured using the built-in camera feature. Oddly, Apple doesn't provide a method for viewing these items via iTunes. In order to access them, I'd launch iPhoto, copy out the movies in which I was interested and then drag the items out of iPhoto into my preferred movie management tool.

It was all a bit of a nuisance since I don't like to use iPhoto.

I figured there must be a simple way to get at these photos and videos without having to use iPhoto or some other bulky image management program. Well, it turns out there is. The iPhone follows the normal "Design rule for Camera File system" convention, so any tool that can browse photos or movies on a camera will be able to access these files. No big surprise there. That's what I expected.

But what did come as a surprise to me was with Mac OS 10.6 there is an ImageKit API which makes accessing this data via a custom program incredibly simple. How simple? How about not even having to write any code simple? Using XCode and Interface Builder, you can literally drag and drop an application which will provide a simple browser interface for any attached cameras on your Mac.

Apple details the simple 2 step procedure in their XCode documentation.

If you don't don't feel like building your own XCode project for this feature, the "Image Capture" program supplied with Snow Leopard provides this exact functionality.

Also, I should note, when I say this allows you to browse videos stored on your iPhone, I am referring to videos you have recorded using the built-in camera. It does not allow you to browse videos loaded via iTunes.

Increased caution regarding "undocumented" API calls

It has always been Apple's official policy that you shouldn't use private frameworks or undocumented API calls in iPhone apps. However, in the past, it seemed the policy was only enforced with regard to using private frameworks. Using undocumented APIs in an app would usually go unnoticed, although as a practice they were risky since at any time Apple could change or remove the undocumented API causing your app to break with a newer release of the OS.

Well, based on reports from many developers recently, it seems Apple now has a tool for scanning submitted apps for undocumented API calls and Apple will reject such apps.

So, double-check those compiler warnings in your code. It could be you are using some undocumented API calls and are at risk for having your next app submission rejected. It's easy to accidentally add some undocumented API calls when searching the Internet for a code snippet to address a problem you've been struggling with for days. A quick cut and paste and your problem is solved, and at the time you might overlook the compiler warning that states the object may not respond to the method being passed (a sure sign that you are using an undocumented API).


Note the compiler warning for this undocumented API call above...

Regardless of how useful some of these undocumented API calls might be, and regardless of the fact that Apple may be using them, if you use them in your apps, your app WILL now get rejected during review.

If Apple does in fact have an automated tool which is scanning submitted apps for these violations, it would be extremely helpful if Apple were to integrate this into the iTunesConnect submission process. Why make a developer wait two weeks to find out their app was rejected because of an API violation when it could have been flagged immediately on submission?

Apple already scans the app binary for some simple items such as version number matching the version listed in the app description during the upload process, so it should be possible to add some more scanning features. Even if it were to take a few minutes, getting an automated rejection several minutes after submission would be preferable to waiting 14 days.

Minor ITC update - Thanks Apple!

Nice! Apple has made a minor change to iTunesConnect which will make the review process a little easier to track.

When you submit a new app or a new update, it will now list the app as "Waiting For Review" rather than "In Review".



Then, when the app is actually being reviewed by Apple the status will change to "In Review". And when approved, yes, as expected, it changes to Approved.



But, best of all, these activities are timestamped! Next to the status of the app is a link called "Status History" which when clicked produces something like this:



This last bit will be useful when setting the date of the app so it appears in the proper date range in the store.

It's just a minor change, but it is nice to see Apple is giving more transparency to the review process.

Date parsing on the iPhone

I recently ran into an unexpected behavior using the NSDateFormatter on the iPhone. I was using it for converting strings to internal NSDate objects. Basically, I was parsing an XML file and was trying to turn the dates into usable dates in my code.

All the examples I had seen for using the NSDateFormatter to convert a string to a date went something like this:

You define the format string of how the date is expected to be parsed via:

NSDateFormatter *inputFormatter = [[NSDateFormatter alloc] init];
[inputFormatter setDateFormat:@"yyyyMMdd hh:mm:ss a"];
[inputFormatter setPMSymbol:@"pm"];
[inputFormatter setAMSymbol:@"am"];

And then you can parse a date using this formatter like so:

NSDate *formatterDate = [inputFormatter dateFromString:@"19990711 10:30:00 pm"];
NSLog(@"date:%@", formatterDate);

Well, this doesn't work quite as you might expect. I discovered that on some iPhones, the end resulting date had a time of 10:30AM rather than PM!

It turns out the difference in behavior was due to the "locale" settings on different phones. Specifically in this case, if the user had their phone configured (via Settings) to use a 24 hour clock display, then my format string specifying the am/pm designation was being completely ignored! All times I was trying to convert from text strings were always ending up as AM times.

To prevent this, I needed to add one more step to my NSDateFormatter configuration after it was initialized:

[inputFormatter setLocale:[NSLocale systemLocale]];

By setting the locale to systemLocale, this would prevent the NSDateFormatter from using any custom locale changes the iPhone user may have made.

Artificial Life 1.5 now available

Apple has just approved the latest update for Artificial Life (v1.5). As mentioned earlier, this now includes support for editing the chromosomes of individual protozoa. Now you can see if you can do better than natural selection in creating a creature that survives a long time.