Archive for September, 2009


More Accessory Development

Here’s a few more handy links for hardware accessory development outside the official program to go along with the headphone connector modem we mentioned earlier:

iPhone/iTouch Serial Port Tutorial

Dock Connector Breakout Board

A Portable User-Space Bluetooth Stack

Let us know if there’s any other happy hacking stuff floating around we could list here!

h/t: iphonesdk!


Creative nib tricks

Here’s an interesting read on creative exploitation of nib file binding behavior. Specifically, to load UITableViewCell instances:

This is what confused me at first:

   if (cell == nil) {

   [[NSBundle mainBundle] loadNibNamed:@”TVCell” owner:self options:nil];

   cell = tvCell;

   self.tvCell = nil;


The method loadNibNamed:owner:options returns an NSArray with the contents of the nib, but this code completely ignores that array. It doesn’t even capture it. Then, it goes on and blithely assigns some instance variable to another instance variable, and then sets the first instance variable to nil.

Yes, that does indeed look unintuitive, does it not?

Then it dawned on me. The bundle loader automatically connects outlets made to File’s Owner when it loads a nib file if the outlet is nil. Notice that when the nib is loaded, the code specifies self as the bundle’s owner. So, since this controller class is the File’s Owner, when we load the nib, the outlet will get connected to an object in the nib if the outlet with that name on File’s Owner is connected to an object in the nib…

That’s just brilliant. Kudos to whomever at Apple thought of it.

We think we’d go more with “sadistically twisted” than “brilliant” per se — that’s what anyone tasked with maintaining your code would think, almost certainly — but it certainly is creative, yes. Try it out yourself … for enhancing job security, if nothing else!

h/t: 71^2!


If you decide to use this strategy, be warned that you need to set the identifier in InterfaceBuilder to match the table’s reuse identifier — otherwise you will allocate a new instance for every row! Link to article with details can be found here.


Play MPE Player

Ah yes, another excellent Trollwerks project has hit the App Store: Destiny Media Technologies‘ Play MPEĀ® Player, the iPhone version of the desktop client for the Play MPE secure music distribution system!


And we’ve been waiting to tell you that news for a looooong time now. “How loooong a time”, you ask? Why, let us tell you how long! The binary that hit the App Store this afternoon was submitted on May 9th. How long is that? That’s 130 days. ONE HUNDRED AND THIRTY DAYS. 18 weeks. 3120 hours. 187,200 minutes. 11,232,000 seconds. And not a single word of feedback anywhere in that ONE HUNDRED AND THIRTY DAYS except from the trained parrot that Apple has warbling “Your application is requiring unexpected time for review! Your application is requiring unexpected time for review! Awrk! Squawk!” in response to every attempt at opening some kind of communication channel.

Not that we’re bitter or anything, mind you. All’s well that ends well … eventually. But it certainly would be nice to have just a smidgen more transparency to this process wouldn’t it? But hey, it could be worse, they could have actually found something wrong in my code!

Any-ways, if you’re not aware of the Play MPE system already, chances are this isn’t for you; but if you are in it, you want to go get this RIGHT NOW to get at all your prerelease music on your iPhone!




And continuing our theme from yesterday of things to be vaguely aware of but not get overly excited about, in case you didn’t read any news today, now — the joy! — porting .NET apps to the iPhone just got a lot easier:

Mono developers have shrunk their open-source implementation of the .NET runtime down to iPhone size. Novell on Monday unfurled MonoTouch, a commercial toolkit that allows developers to use Microsoft’s development framework to build apps for Apple’s ubiquitous mobile.

MonoTouch consists of a suite of compilers, libraries, and tools for integrating with the iPhone and iPod Touch SDK. It lets developers use C# and other .NET programming languages for the Apple devices, rather than wading into C and Objective-C…

Indeed. Whilst one’s natural reaction is “come on in guys, the water’s fine” or perhaps “that’s ok, we like our pool clean” (we kid! we kid!) there’s always the possibility, hard though this is to imagine, that there could be something worthwhile written in .NET one might want to port to the iPhone. Or that you’re developing something which has a requirement to run natively on Windows. In which case … hey, this would be handy to know about!

h/t: 71^2!


Authoring: GameSalad

If you’re the type to be interested in cross-platform authoring tools like Torque and Unity, here’s another option for you to check out: GameSalad!

GameSalad is the world’s most advanced game development tool for non-programmers. From an easy to use logic and physics system, to a visual based interface, and even the means to share your games to the iPhone, Desktop, and Web – GameSalad provides everything you need to get your game from concept to execution. Simply download the tool to a your Mac, install, and start making games!

Indeed. Good luck with that. But hey, it does look more Mac-centric than the more established competitors, which is always a good thing, and if your ideas really are that simple, perchance this could be an option. This little note and lingering vague awareness of its existence are about as far as we plan to get involved … but hey, if you actually try it out, we’re certainly interested in hearing your opinion!

h/t: ipodnn!


Here’s a site possibly worth bookmarking: apparently aims at becoming a comprehensive directory for all sorts of, well, iPhone dev tools, eponymously enough; coding, tracking, advertising, networking, yadayadayada. Not too terribly impressed so far, as their comprehensiveness doesn’t really match up to what the Faithful Reader will have collected through their rapt attention to this humble blog in many of the categories; but hey, they are well organized and show promise!

h/t: MobileOrchard!


Review: iSimulate

So you may recall a little while back we mentioned the various options out there for integrating input from the device into your simulator-running application, and today we’re going to delve into just how well the paid option, Vimov’s iSimulate, actually works — since they were trusting silly kind enough to provide us with a review copy. Let’s see how that works out for them, shall we?

First off, we’re going to try it out with an accelerometer-controlled cocos2d game that we’re going to be working on soon as things slow down a bit around here — so look for that around the year 2015! Ho ho! — but has the accelerometer input working, so makes a solid test.

Having installed on our device, we start it running, then download the SDK and read the instructions:

1. Add the iSimulate library file named “libisimulate.a” to your Xcode project…

Drag, click, done.

2. Add the CoreLocation framework to your project…

Click, scroll, drag, click, done.

3. Add to “Other Linker Flags” the value “-ObjC”…

Hmmm, that’s an interesting request. And what is that option, exactly? Ah, so that’s what it is. That explains how they do this without any source changes, then. Any-hoo, we do all our configuration in .xcconfig files, so we’ll just edit the base one for this project to


4. Oh, wait … there is no 4.

Alrighty then. So we run the app, and lookee there, immediately up shows our computer on the device (You remember from above we started it running before downloading the SDK, yes?):


Tap that, and in scrolls the active view:


Very pretty, yes. Now, your immediate reaction is that makes it impossible to use the thing to actually manipulate a touch interface, since you can’t see what you’re touching. But they’ve addressed that in a surprisingly effective fashion; translucent dots appear on the simulator at the points where your fingers are touching, as in this screenshot of three fingers touching, one directly over the’Menu’ button:


Turns out surprisingly workable, too, if not the most precise.

And speaking of precision … just how precisely does the response in the simulator reflect the actual device input? Hmmmm … well, it’s not absolutely perfect, we definitely noticed a tendency to overshoot the ball’s acceleration on the play sceen. But it is somewhere between “very good indeed” and “excellent”. As well, our test subject here has extremely twitchy response (by design) so we’re inclined to believe that the input lag here is as good as you can reasonably expect anything going over Wifi to be.

We proceeded to try various combinations of stopping and restarting the device app and the simulator app to see if we could manage to confuse it, and nope; managed to detect/connect/reconnect with casual aplomb.

So it works great for an OpenGL game.

For part 2, we were going to try it out with the multitouch resize ‘Fit Pose’ overlay feature of Poses Volume 1 … but somehow it managed to escape us that iSimulate would, in fact, not make the simulator magically have a camera. And that didn’t occur to us until we’d taken the 30 seconds to go through Steps 1-3 to add it to the project and run it, of course. Oops. So while we were there anyways, we tried it out with the swipe navigation gestures in the full screen gallery, and it worked just as expected on those; and since those work, and we can see the pinch/zoom dots rolling around, we’re quite sure if we bothered to enable the transmogrification in those instances the multitouch would work as well as the single touch does.

However, there was one failure we noticed; whilst tapping on an individual table cell works as expected, it did not seem to recognize a swipe to scroll the table. Which, had we bothered reading to the bottom of the documentation page, we would have seen documented:

Due to technical restrictions, iSimulate does not send touch events for the following UIKit objects (as well as any object based on them): Keyboard, UIScrollView (including MKMapView), UIPickerView and UITableView. All of the other UIKit objects receive all touch events. There are no limitations on OpenGL-based applications.

Hmmm. Wonder what’s up with that? Well, you can always just use the computer’s devices to provide those inputs, so that’s just a mild inconvenience. Although it would be interesting to know exactly what these “technical restrictions” would be, curious trolls that we are.

So! What’s the verdict? Pretty much unqualified recommendation, that’s what the verdict is. As you can see above, integration with our test products took longer to liveblog about than it took to actually perform; there was no mucking with the source whatsoever, just adding a couple libraries and a linker flag; the application found risible our best efforts to confuse it; and although it’s not absolutely faithful to how the device reacts natively, it’s very close indeed and probably as good as you can reasonably expect given that there’s a Wifi connection in between. For the $16 it’s priced at as we write this, by the time it saves you half a dozen install cycles it’ll have paid for itself quite handily.

And we haven’t even touched here on the other big benefit of having this around: that when it comes time to make screencasts of your finished product, they’re going to be much more helpful when made off the simulator with this assistance rather than pointing a video camera at your hand blocking the screen like most of the blurry demo videos you see around. See the samples here for how well that works out; those little gray dots really do make the video quite more informative, indeed.

Convinced? Of course you are. And you know what to do now!



Library: AntiCrack

Whilst as we’ve mentioned before we feel it is at the very best a complete waste of time and more usually actively harmful by way of annoying your honest customers to spend anything past the most cursory efforts at copy protecting software that’s delivered to a user’s machine … there are many who do not agree. Some of which have money to back up their disagreement with! So, for their benefit — and ours if they’re paying — here’s a library that may be of some interest:

AntiCrack contains proven technology which completely eliminates the risk of your apps getting pirated. As of version 2.0 it contains the strongest defense mechanisms possible to detect cracking attempts as well as technology to thwart Crackulous. In version 1.x it was only possible to detect cracks and not prevent them. Our cutting edge research team has developed two new methods which make it impossible for Crackulous to even decrypt your app. Also AntiCrack 2.0 is completely rewritten from ground up to make it unfeasable for crackers to try to disable AntiCrack with a hex editor…

A certain red flag and bull air to the hubris on display here, wethinks. But hey, if you’re less cynical than we are, give it a shot!

h/t: iphonesb!


Roundup: Xcode Tips

Aaaaand to celebrate today’s release of the iPhone OS 3.1 SDK with the latest Xcode versions for Leopard and Snow Leopard, let’s make a list of useful Xcode tips and resources from around the web, shall we?

Oldies but goodies:

Stack Overflow’s Xcode Tips And Tricks

Mobile Orchard’s 14 Essential Xcode Tips, Tricks and Resources

Up-to-the minute stuff:

Static Code Analysis (Clang) and Xcode 3.2

Xcode 3.2: teh awesome edition

Complete Xcode Keyboard Shortcut List

clang Source Annotations

Helper Goodies:




Any others you find particularly useful, Dear Readers?


Hardware Connectivity: H4I

Now here’s something a bit different for this neck of the woods: how to develop hardware iPhone products. Yes, indeed, hardware products … that do not use the ExternalAccessory framework for Apple-blessed accessory connectivity development:

Progical Solutions LLC is targeting an audience of iPhone professionals in the software and hardware industries currently unable to bring their accessories to market.

Now just how do they do that, one wonders? Well, get this, they turn the audio jack into a modem. Yes, a modem. Seriously.

The H4I program has evolved from the initial work done by Alex Winston. Although this work was groundbreaking at the time there wasn’t an easy way to support developers who might adopt this technology. However with the release of the iPhone SDK 3.0 Apple also released the External Accessory framework. With this framework as the model Progical Solutions LLC has implemented these interfaces as a standardized means to integrate apps with external accessories through the 3.5mm audio jack. At speeds up to 19.2K baud, serial data can be programmatically sent and received by the iPhone and iPod.

Must admit we’re not 100% clear on why exactly you’d want to go this route instead of through the official method; but hey, it’s an impressively geeky achievement nevertheless!

h/t: MobileOrchard!