Archive for February, 2010


Script: dsym-archiver

[UPDATE: Xcode 3.2.2 has, apparently, rendered this kind of workaround obsolete. W00t!]

Here’s a possibly handy with a little editing script for use with your iPhone development, which does two things:

This script is intended to be run during an Xcode build to archive your build’s dSYM bundles (needed for symbolicating crash logs received from iTunes Connect or beta testers’ feedback) and, for beta releases, to create an .ipa package to send to your beta testers.

There’s a few path assumptions that probably need fixing for your setup, and it needs to run as a separate target since the binary has to be signed for making an ipa to work, but hey it’s a useful start.

If you’re wondering just why making an .ipa is worth any trouble whatsoever, rumour has it that making an .ipa is an effective way of getting around The Problem That No Doubt You Have Encountered if you do any ad hoc builds for Windows users –That Problem being that the @(#$&@!!! things never work. OK, we exaggerate … but they certainly do cause problems on a regular basis. Personally, we’ve had a good deal of luck remedying that by zipping up our .apps with this fine product,


as it seems that the problem is due to something in the .app folder which sometimes doesn’t get decompressed properly on a Windows machine, and keeping it in .ipa (which is just your .app zipped with some enclosing folders) format through to dropping it on Windows iTunes avoids that. We’ll go to the trouble of checking to see if that is indeed the case next time we run into a complaining Windows user. And perhaps, we’ll even do it without sending first our usual response of “Oh, your problem is very easy to fix. Simply visit your local Apple Store, and BUY YOURSELF A MAC!” since that never really seems to go over all that well, for some strange reason. We certainly don’t understand, it seems a perfectly logical and reasonable solution, don’t you agree?

h/t: iPhoneSDK!


Tip: iTunes Links

Just in case you managed to miss this so far, Technical Q&A QA1633 has the official scoop on creating easy to read iTunes Store URLs for a specific application and/or company. The three types are:

  • Company Name:<companyname>

  • Application Name:< applicationname >

  • Application by Company:<companyname>/< applicationname >

The rules for constructing <companyname> and <applicationname> are basically to convert the text displayed in the App Store to lowercase ASCII and remove anything without an obvious counterpart in that set, with the exception that “&” becomes “and”. Like these examples:

  • Sega =>
  • ngmoco, Inc. =>
  • Chen’s Photography & Software =>
  • Ocarina =>
  • Watchmen: Justice is Coming =>
  • Brain Challenge™ =>
  • Spanish Class 2 – Bueno, entonces… ¿qué pasó con el cinco? =>

There are some extra caveats, like that these are not guaranteed to be unique in which case they bring up a search page, so it’s very likely a good idea to hand craft and test these individually rather than construct them programmatically. But hey, baby steps.


Selling Bookmarklets

Now this is an intriguing twist on the App Store discussed over here at Mobile Orchard: Let’s say you’ve written a clever piece of JavaScript to extend Mobile Safari, like for instance

So, instead of writing a complete Safari replacement to add the missing Find In Page capability, you write JavaScript to take the search term and then find it in the page. Add that JavaScript as a bookmark and you’re all set.

Now, let’s say you feel like monetizing that. Through the App Store. The App Store? Why yes, through the App Store!

Vais’ twist is this: he’s selling his bookmarklet in the App Store for $0.99. His angle is clever: he’s created a simple app that places the bookmarklet JavaScript on the pasteboard. The user can then add a bookmark and set its location by pasting the JavaScript…

Now that’s a cool idea. Wouldn’t have occurred to us that Apple allows such a thing, but the proof is in the pudding. Where by “the pudding” we mean “the App Store”, of course. So there you go, if you have some clever browser extension code, now you know how to monetize it!


Barcode scanning

So let’s say you want to put barcode scanning into your iPhone app. Sounds like a lot of work, yes? Well, no, there’s actually three options:

1. You develop your own barcode reader. Open source libraries like zxing are a great start, but they will not work on the iPhone 3G, still the most common iPhone out there. Most commercial libraries have the same limitation.

2. You license the pic2shop barcode scanner library and SDK. We spent hundreds of hours to make it work quickly and accurately on all iPhone models. Get more information from Vision Smarts’ web site.

3. You take advantage of the pic2shop: custom URL scheme to launch pic2shop, read the barcode, and get the barcode digits back in your app, for free.

Hey, that last one sounds interesting, yes? Aside from that depending on somebody else’s app bit. But they claim that won’t be a problem,

This method requires that your users install pic2shop. However, pic2shop is, and will remain, free, so it does not cost you or your users anything. Moreover, pic2shop is lightweight (less than 400k), and loads very fast.

Takes a little effort to set up a custom URL scheme and so forth, as detailed here, but hey it’s pretty hard to beat the price. An interesting side effect of that strategy is that you can also barcode enable your Web sites, since the invocation is a URL:

Web developers, the above link ["pic2shop://scan?callback=p2sclient%3A//EAN"] is all you have to do to integrate barcode scanning in your site. In your case, the callback will be a regular URL pointing to your web app.

That’s pretty nifty, indeed.

h/t: iPhoneFlow!


Class: AutoScrollLabel

Here’s a handy little class … well, handy if you want your UILabel to be a scrolling marquee. Fairly straightforward to do that in any number of ways, but this particular one is mildly notable for leveraging native facilities:

… The scrolling is implemented using two UILabels contained in a UIScrollView. Each label contains an identical copy of the text and the labels are resized to be just large enough to hold the text without any truncation.

If the text in the UILabel is wider than the containing UIScrollView, then the two UILabels are laid out side-by-side, and the scroll view is animated to scroll from the beginning of one label to the beginning of the next label. The second label is there just to give the illusion of the text looping forever.

The class registers itself as the delegate for the scrolling animation block, so when the animation block ends, it waits the defined pause time, and then just performs another animated scroll, in which case the scroll view is reset back to the beginning of the first label and the process is repeated.

And that’s it! Pretty simple. The animation block feature of a UIView does all the hard work.

Yes, we do tend to overlook just how powerful an engine we have sitting there with UIViewAnimation, indeed. So here’s another reminder!

h/t: iPhoneSDK!


TweetPhoto API

Feel like sending photos to Twitter from your iPhone app? Yes? Well, let us put you on our Christmas list then, “Intended Present: A Life” …

… er, we mean, we’re here to help. And not cynical about the value proposition in the slightest.

Any-ways, of the veritable plethora of services that have sprung up to serve this nonexistent need (OK, we’re done being cynical now, we swear) seems that TweetPhoto should be the choice of the discerning iPhone developer, as only they provide an open source Objective-C API:

The TweetPhoto Objective-C library is a set of drop in classes designed to allow developers to get up and running quickly with the TweetPhoto Photo Sharing API.

This library includes every feature you’ll need to manage the entire photo sharing experience within your application – from uploading photos, commenting, favoritng, and voting to social feeds, user feeds, and everything in between…

Indeed. Who could possibly resist?

h/t: MobileOrchard!


Quality Control

There’s a most excellent set of posts to read over at CocoaWithLove on unit testing your Mac/iPhone apps … and why not to!

In my last two posts, I’ve shown a Mac app with full unit tests and an iPhone app with full unit tests. The reality though is that I do not write or test code this way. In this post, I look at why so few applications are actually developed using unit tests. I’ll also look at the alternate approaches — both manual and automated — that are normally used to maintain high quality and low bug rates in application development.

Must read, indeed. Personally, since pretty much everything we write here is handled by ourselves and completely user-driven to boot, it’s rather hard to make a case for devoting the time to a formalized unit test regime; what fits our developing style is a kind of extreme iterative testing. Which works perfectly well … when you’re working on your own, and your apps aren’t data driven. So we’re always on the lookout for sensible ways to scale up the process — whilst avoiding the “what do you mean all the !(@#$^!!! tests are eight months out of date?” problem — and this is a not miss set of insights on that!

PS: And while we’re on the subject of unit testing, here’s a handy tip about using OCMock with asynchronous callbacks, handy if you need it…


Fashion Network Original

Aaaaaaand another fine troll project just pranced its way onto the App Store today, this one a simple little online video player for the Fashion Network; and why yes, yes indeed — we don’t even have to tell you this any more, do we? — the screenshots feature, surprise! scantily clad attractive women.


Yes, we know our protestations that this is not at all intentional in the slightest are getting increasingly unbelievable with each new attractive female featuring release, but it’s completely 100% true, we just happened to get an email about dashing off a few hours’ worth of video player project at just the exact time we had a few hours to spare, and in short order, here we are. It just happens to work out this way. Weird, huh?

(Unfortunately, this one does not qualify as a successful troll project — one rejection cycle this time, as playing these MP4 fashion videos over cellular broke Apple’s data use policies, whoops. So take notes, Application Rejection Reason #Umpety-Nineteen: do not attempt to play high quality MP4s over the cell network. YouTube, however, that’s cool.)

Any-ways, it’s just a simple list of videos you can play; but hey, it’s free, so if keeping in touch with the latest fashion productions is your kind of thing … here you go!

Fashion Network


Doom code review

Here’s something not to miss if you’re interested in game performance on the iPhone; an extended code review of the Doom for iPhone release!

I took some time away from programming something I hope will become a really good shmup and read the source code of Doom for iPhone. I was very interested in finding out how a pixel oriented engine made the transition to openGL. Here are my notes…

Good stuff, good stuff. With bonus exposition on exactly how the Doom Classic renderer goes about doing its thing.

h/t: Slashdot (check the comments)!


Bump API

So, you checked out that Bump app that lets you exchange contact info and photos by, well, bumping your iPhones? Kinda cool, huh? Wouldn’t it be neat if you could add that to your own apps easily? Well, guess what

This week, we (Bump Technologies) announced the availability of an iPhone SDK/API that allows developers to use the Bump matching technology in their own apps. The API lets you add easy in-person connectivity / identification by just bumping two phones together…with only about 10 lines of code.

The really interesting part, from the FAQ, is that since this is server-based it supports Android apps as well:

Q: Cool, but doesn’t this only work between two iPhones?

No! Bump currently supports iPhone, iPod touch, and Android. We are working to bring Bump to other platforms soon. Today, there are several other phones that include the sensors that Bump needs to feel bumps, but in the next few years, the vast majority of new phones will have these sensors. We plan to offer Bump on all of them, and Bump will work between any two of them.

Q: Wait, you are saying an Android phone can bump an iPhone?

You bet. Any two devices running Bump can bump each other.

Cool beans, yep. And apparently it won’t be a huge license fee, although this is a trifle nebulous:

Bump for Free!

We want to make it as easy as possible to use the Bump API. If your app isn’t overloading our servers or generating incremental revenue with each bump, chances are the Bump API will be totally free to you.

They have a list of suggested apps here, just in case your imagination is limited, but we’re quite sure you won’t need it. So check out the tutorial here, and the API resources here, and if that looks interesting, get an API key here and go!

h/t: Cocoa and Cocoa Touch Developers!