Under The BridgeUnder The Bridge

Source: iPhoneDevCamp 3

Here’s a good selection of open source that we’d missed ’til now: Several of the winning projects from iPhoneDevCamp 3’s Hackathon have their source available online. Stuff like:

iPhone ARKit

An open source ui library for displaying location based data in spherical coordinate systems mirroring UI Kit on the phone. A list of CLLocation objects can be submitted and our library will handle drawing of the locations on screen.

OpenFlow: a CoverFlow API replacement for the iPhone

A free, open source replacement for Apple’s private CoverFlow API. The initial release is simple, but it is also efficient and very fast, even on first generation iPhones.

Avatar Wall

AvatarWall recreates the experience of the WWDC App Wall using the Twitter avatars of iPhoneDevCamp followers, and whenever one of them posts a tweet, their icon pulsates to help you more easily identify the source of the latest banter.

Lots more too

Tip: First Responder

So you ever found yourself thinking “gee, it would be really handy to know what the first responder is right now” and wonder why you couldn’t find what must be the quite obvious call to get it? Well, we did, and it turns out no, there actually is no supported way to do it far as we can tell. But if you really really need to figure it out, Matt Gallagher is on the job:

This is an important piece of information, so it’s strange that Apple didn’t choose to provide a public method to access it. Curiously, there is a method, firstResponder, on UIWindow which returns this value but it isn’t public. This will work:

Now, you do have the UIResponder isFirstResponder method publicly available if you want to query about a specific view you know about, but the generic case, nope. Most likely because arbitrary access would get you closer to the dreaded “There is no documentation for the custom subclasses or self-contained views of…” rejection notice, I suppose. But hey, if you want to know how, there you go.
Also of note in that article is code for finding the keyboard, drawing round rects, and providing a nice-looking progress view; good stuff all!

Roundup: Push And Purchase

[EDIT: Discontinued, all except Urban Airship.]

(Alright, this isn’t a “roundup” as we post this, since it’s pretty much just the links from this fine, fine post at NSCoriolisBlog — but hey, we’ll be editing as developments occur!)

So as you’ve noticed no doubt if you’ve even cursorily looked at how to go about implementing push notifications or in-app purchasing in your sparkly new cutting-edge iPhone apps … there’s a lot to do there. More importantly, you can’t just toss your binary up to Apple and forget about it any more, there’s ongoing service and scalability issues. That’s a pretty big leap in project complexity. However, there are services that are springing up to take care of the hassles for you! The two that are actively deployed and providing push and purchase both are

Urban Airship — got all the big name clients so far

iLime — make a big production about being cheaper for messages

Both charge 5 cents a download for content, it seems.

As well, there’s several upcoming competitors in beta:

Bigcurl HTTPush




[EDIT: AppNotify — thanks, Josh!]

Seems like a few too many gearing up there for what the size of the market is likely to be. So although in line with the programmer’s natural desire to avoid work we thoroughly recommend getting started with one of these services, we suspect that if we actually ended up depending for our livelihood on a particular product we’d want to go through the trouble of getting our own host set up to remove this possible point of failure, at least unless/until one of them is clearly profitable enough to stick around for the long term. And so, here’s some links to help you out with that:

Tutorial on how to setup your own server in PHP

Source code (in PHP), requires PHP with memcache

Python wrapper for Apple Push Notification Service

Apple Push Notification Library for Haskell

Apple Push Notification Library for Ruby

Apple Push Notification & Feedback Services Client C# Library

And again, our grateful acknowledgement to NSCoriolisBlog for providing all the links for the first edition of this “roundup”!

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!

App Store


[EDIT: Discontinued.]

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: iPhoneDevTools.com 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 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 iSimulate.app 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.