Archive for October, 2009


Flash in the pan

So yeah, unless you were hiding under a rock this week you heard that Flash CS5 won the Nobel Peace Prize … no, wait, that was some other guy — but it would be quite easy to make that mistake, the way commentators were hyperventilating about how transformative, amazing, yadayadayada this was! — for promising to output iPhone applications.

Well, color us underwhelmed.

Not to take away from the technical achievement of creating an LLVM front end for ActionScript 3, but it’s a technical achievement of the dancing-bear type; just because it’s amazing to do at all doesn’t mean it’s actually done well. For starters, let’s look at what FlashMobileBlog says will not be there:

Some typical iPhone features that are not supported are:

  • Photo selection from file system
  • Contact selection from the address book
  • Camera
  • Cut/copy/paste
  • Accessory support
  • In app purchase support
  • Peer to peer
  • Maps

  • iPod library access
  • Compass

  • Push notifications
  • Audio recording
  • Video recording
  • Parental controls

Um, yeah. Add to that no native UIKit — you have to code the entire interface in Flash — and, you know, we have a very limited indeed subset of applications this is even vaguely appropriate for. And even if you do have one of those, there are … issues … to consider. Of which, we’ll highlight what users are going to notice right off:

… On my iPhone 3G it runs really choppy, on my 3GS it runs acceptably, but it still isn’t smooth. Given the OpenGL performance people have seen on the 3GS that is still pretty bad. I have not done any invasive tests by instrumenting the binary, that is just what I can get via basic usage. The sad thing is that there is no reason it has to have performance like this. This is not an inherent issue with the ActionScript used in this app (though that may have issues), it is that what is coming out of the toolchain is a huge, monstrous binary that stresses the runtime and has performance characteristics completely different than anything the iPhone is currently setup for….

… I want to be excited about this thing, both because it is a seriously cool piece of tech, and because there are Flash games I would like to run on my phone, but looking at what this thing is spitting out I think the apps it will generate will perpetuate the stereotypes about Flash (especially on cell phones), and give Objective C programmers a (somewhat misplaced) sense of vindication about their views on Flash.

Yeppers, count us in that misplacedly vindicated group. You want to change our mind, show us a built-with-Flash app that measures up even remotely to something developed using the real SDK. We’ll be waiting.



If you’re the excessively inquisitive sort, perhaps you’ve noticed that there’s a new framework in the public 10.6 SDK, IOSurface.framework — that has absolutely no mention in the documentation whatsoever past the single line here

Contains low-level interfaces for sharing graphics surfaces between applications.

Not big on documentation, apparently, the IOSurface folks. But here’s some detail for you as to why it exists and what it’s good for:

As one of the long overdue issues, not to mention all the limitations derived from its venerable age, Apple has introduced a first step to the future of the old Quicktime (that will stay in 32 bit universe) with the new Quicktime X: however, Quicktime isn’t so easy to replace in one shot, and it’s still present in the system, transparently invoked by Quicktime X (or, for us developers, by QTKit) whenever it’s needed.But, how can a 64-bit software (like the Quicktime X Player, or the Finder itself) use a 32-bit library? The answer is, it doesn’t, the technique used behind the scenes is far more interesting: when a 64-bit software needs a frame from a movie it can’t process otherwise, a specific software is launched (you’ll see it in the Activity Monitor as QTKitServer-(process-ID) process-name) that gives back the frames to the 64-bit app.Hey, isn’t that nice? Graphics passed from one process to another, how can they do that? The answer looks like it’s in a new framework, IOSurface…

Now isn’t that nifty? Not that we have any software that uses plugins or anything like that which will have to deal with a 32 -> 64 bit transition far as we can see, but hey, if you do … IOSurface is there for you!


iPhone Wax

And today, we’re going to tell you how to make your iPhone extra-shiny!

No, actually, “iPhone Wax” is an oddly-named project that lets you write native apps in Lua, of all things.

I started investigating how I might wire up — and then write native iPhone apps from — a scripting language. Lua was on my radar already. It’s compact, expressive, fast enough, and was designed to be embedded. Took only about 20 minutes to get the Lua interpreter running on the iPhone. The real work was to bridge Lua and all the Objective-C/CocoaTouch classes. The bridge had to work in two directions: it would need to be able to create CocoaTouch objects and also be able to respond to callbacks as part of the familiar delegate/protocol model.

I tweeted about my intentions. Corey Johnson responded that he’d been working along the same lines and, dang-it, his implementation was exactly what I had in mind. It’s called iPhone Wax, it’s brilliant, and Apple has already approved one app using it.

Intriguing? If so, read the above article, check out the code on github, a sample on github, and the Google group.

Now, there is some fuzziness about what exactly the status is of interpreted scripts for App Store acceptability purposes. Downloading scripts to extend application functionality is pretty clearly out of bounds, but it’s not completely clear whether scripts bundled in your application are officially acceptable or not — and if not, whether using Lua’s bytecode interpreter for semi-compiled scripts avoids that line. But hey, one slipped through at least … if it’s still on the store by the time you’re reading this, apparently you can get away with it!


LinkShare analytics

So as a conscientious IPhone developer, no doubt you signed up to be an iTunes affiliate to get that extra 5% on your upgrades and all as we described here, but as you’ve probably noticed, there’s a definite dearth of feedback through LinkShare on where exactly all those monthly megabucks (well, in our case it’s decabucks, but we trust you’re putting more effort into it than we’ve bothered so far) are coming from. Wouldn’t it be great if there was some way to track exactly which clicked link resulted in what kickbacks?

Well, turns out there is a really complicated super secret way to manage that. And here it is:

All you really need to do is add a ‘&u1=<your_custom_signature>’ to the end of the url.

OK, so it’s not that really complicated.

It’s not all that super secret either, actually … more like hidden in plain sight from those that don’t bother looking around much. The trick is to find the LinkShare Affiliate Resource Center and click on LinkShare Signature Technology, which gives you a document to fill out to request that they turn on this signature tracking for your account — [EDIT: And when you do, you get an email back the next day telling you "Please note that all affiliates are enabled for the LinkShare Signature Technology. Thus, you no longer need to submit us that form." Apparently website currency is not a high priority at LinkShare... ] — and a PDF of instructions on how to use it and access the reports. Which pretty much boils down to the quote above.

So there you go; built-in analytics with your LinkShare referrals! W00t!


Simple Unit Testing

So you read our earlier post on unit testing but haven’t gotten around to actually setting it up yet? Well, here’s a simpler way to dip your toes into the water:

One of the biggest gripes that folks have about the built in unit testing for Xcode is that it’s a pain to setup and debug. I’ve also hear from folks that this is the reason they don’t write tests, which is a shame. But I’m going to share a little secret with you today: thanks to Objective-C, it’s pretty darn easy to roll your own solution.

Here’s some code for you: CallTestMethods.m

I’ve even got it hooked up to my build process these days; I launch Acorn from my build script with a -runtests argument, and away it goes. I’m not sure how much easier it could be. It’s very low friction and easy to debug, which is important to me.

Ah, yes. It’s all about the low friction, isn’t it?


Tip: className

So you got some desktop Cocoa code to port that does some introspection, like

if ([[args className] isEqualToString:@"NSCFBoolean"])

and you noticed — whoops! — that -className doesn’t exist in the iPhone SDK, for no apparent reason other than to confuse you?

Well, no, neither did we until today. But if/when you do … here’s the trick to faking it yourself:

#import <objc/runtime.h>

- (NSString *)className
return [NSString stringWithUTF8String:class_getName([self class])];

Now you know!


Code: Appirater

Here’s another option to deal with the problem of negative review bias in the App Store by asking your frequent users to post for you: Appirater!

Now every time the user launches your app, Appirater will see if they’ve used the app for 30 days and launched it at least 15 times. If they have, they’ll be asked to rate the app, and then be taken to your app’s review page in the App Store. If you release a new version of your app, Appirater will again wait until the new version has been used 15 times for 30 days and then prompt the user again for another review. Optionally, you can adjust the days to wait and the launch number…

So that looks like a rather simpler alternative to the previously mentioned L0SolicitReview for accomplishing your begging. Code is here on github; enjoy!

h/t: iPhoneSDK!


Building HTML Apps

So we’ve mentioned favorably before that using HTML5 to build iPhone apps is an interesting looking alternative, but there’s been a dearth of public information targeted specifically at that. Well, now there is! Over at O’Reilly Labs they’ve published

Building iPhone Apps with HTML, CSS, and JavaScript

Now web designers and developers can join the iPhone app party without having to learn Cocoa’s Objective-C programming language. It’s true: You can write iPhone apps quickly and efficiently using your existing skills with HTML, CSS, and JavaScript. This book shows you how with lots of detailed examples, step-by-step instructions, and hands-on exercises.

  • Learn how to build iPhone apps with standard web tools
  • Refactor a traditional website into an iPhone web app
  • Hook into advanced iPhone features (e.g. accelerometer, geolocation, vibration, and sound) with JavaScript
  • Do most of your development with the operating system of your choice

Yes, we’ve definitely got that on the reading list. Just as soon as there’s a spare minute around here…

h/t: DZone!


New releases

Looks like October’s a big deadline date all around: we’ve got a veritable plethora (ok, three) of new releases that all came to our attention today!


Zennaware Cornerstone which we’d already designated the best SCM client EVAR jumps to version 1.5, with a laundry list of new features and interface improvements — go click and read it yourself, it’s very long indeed — but we’d like to note that we particularly appreciate how the 22 working copies it’s tracking for us (yes, it’s been busy around here since we first started using it…) which were taking just enough seconds to synchronize at startup to border on mildly annoying, are now instant. Yes, instant. FSEvents rock. If you’re using any other SVN client, you really should check Cornerstone out. If there’s any reason left to use any other Mac client, we sure can’t see what it could conceivably be.


Vimov iSimulate which we’d concluded was pretty darn handy for hooking up the Simulator and device input is now version 1.1, and get this, they’ve added screen streaming:

While your application is running on the iPhone Simulator, whether it is a UIKit-based application or an OpenGL game, iSimulate will stream it as a video to your iPhone or iPod Touch in realtime, so that you can more easily move your fingers across the screen, and accurately touch the buttons and controls.

We actually hadn’t found lacking that as much of a problem as you’d think — but hey it’s great to have! Also adds orientation change notification and customizable touch indicators. So yep, for the $32 it’s up to know, we’d call that a pretty compelling addition to your bag of development tricks, yep.


Graphic Remedy’s gDEBugger which we’d sized up as vital if you do low level OpenGL is now officially released and up to speed with SDK 3.1 and OpenGL ES 2.0, at an introductory $550 price. Still a bit pricey, we grant you … but hey if you are doing any hardcore OpenGL work, there’s just no other way to get this kind of information and it’s going to pay for itself right quick.

Why, it’s just like Christmas with all these new toys to play with!