Under The BridgeUnder The Bridge

Tip: CoreGraphics Image Masks

Ever had issues with your CoreGraphics image masks just refusing to work right? Yeah, us too. But here’s a tip on how to make them reliable:

…Thus, I’ve found that the best and most reliable way to generate an image mask from an arbitrary image is to do this:

  1. Create a bitmap graphics context that is in an acceptable format for image masks
  2. Draw your image into this bitmap graphics context
  3. Create the image mask from the bits of the bitmap graphics context…

Well, that’s certainly straightforward, long as your images aren’t big enough to cause memory issues, isn’t it? Function provided at the link, enjoy!

h/t: iOS Development Goodies!

Integrating Burstly

[EDIT: Discontinued.]

So we’ve been half-heartedly tracking ad network monetization options for a while, and you might have noticed that those folk over at Burstly (“Make More Money. Gauranteed.”) caught our attention repeatedly, particularly since we like their usage policy:

Burstly is 100% free to developers. There’s no charge to serve ads and we don’t take any cut of your earnings with any ad network using our Open SDK. It’s also free to use our powerful in-app purchase API. You can even sell direct to other developers in the built-in Marketplace. If you’d like to advertise your app directly to other developers in the Marketplace, there’s a 10% transaction fee. That’s it. No hidden costs or commitments of any kind.

… and today we’re finally getting around to the job of putting ads into one of our very first, extremely simple, contracts; and as they requested both cross-promotion house ads and filled ads, we do need some kind of management structure, and hey that’s a fine excuse to check out Burstly, and make walkthrough notes along the way for you, Dear Readers.

First off, baseline from the 2.0 SDK (yep, that old) last released build: Executable — 30,576 bytes; Application — 5,508,896 bytes. Bringing that rather trivial codebase up to a standard-architectured build with our current coding practices and the 4.0.2 SDK expands it to 52,688 bytes; the application, 5,527,993 bytes.

Alrighty then; let’s just jump in and see how good their quick start documentation is, shall we? Off to the downloads page, where we grab

Full Ad Serving iOS 4.0 SDK (iAd, AdMob, Mobclix, Google AdSense, Millennial Media, Greystripe, Smaato, Flurry Appcircle, and Burstly)

which is a 27 meg download expanding to … a 76.4 MB static library and a handful of header files. Woah. (And there’s a couple sample projects there too; or you could just go to Burstly-iPhone on github where they’re hosting all the goodies.)

First step: Add the SDK download to the project. Plop.

Next step: add a whole whack of frameworks. Plop, plop, plop.

On to Add an OAIAdManager to your view:

In your ViewController.h file, just import OAIAdManager.h and OAIAdManagerDelegateProtocol.h, declare an instance of OAIAdManager, and have your view controller conform to the OAIAdManagerDelegate protocol.

OK, there’s only three required protocol methods; but they need a “publisher id” and a “zone id” from the website. (The third is returning the host controller in the explanatorily named -viewControllerForModalPresentation). So off to find those IDs then.

Had we actually created an account before? Ah yes, we did. But not actually set it up or anything. So we add a new app, nothing complicated there (although you’ll need a custom URL if you want to use Burstly for in-app purchase); that gives us the “publisher id”. On to adding an “ad slot”, which we’ll make a standard size banner at the bottom, optimize for 100% fill, and leave all the various filtering options (alcohol, gambling, political views, adult content, …) checked for now; and that gives us our “zone id”. Good, that’s all the required setup apparently. Which took all of about ten minutes.

Next, they suggest that you automate ad refreshing every 20 seconds, which requires one more protocol method and a post-initialization call. And there’s two more protocol methods to control resizing behaviour of the ad view. Pasting in the provided samples appears fine for that; and … that’s it? Run it and … why yes indeed, that is all there is to it, ads are showing up! Just a little adjustment to the xib to move a couple buttons out of the way, and there’s our ad-displaying version all looking pretty.

OK, that was surprisingly easy to get off the ground, about a quarter the time to actually implement as it did to type out this post so far. Let’s see how big the distribution build is now … 4,946,384 bytes of executable, and 10,421,685 bytes overall. Well, since the wireless download cap is 20 MB these days, that’s not a worry in our case.

Now, the next question is, where are these 4 ads we see rotating here coming from, since we didn’t enter any credentials for any ad network? Ah, there we go, they were picked from people who signed up for Burstly’s PPI marketplace. If we want to add other ad sources, then we follow the instructions here. Note that the list of networks there is not exhaustive, a more complete parameter list can be found here.

The two networks we have credentials with (that we can remember offhand, anyways) are iAds and Flurry; so we create campaigns for those two, add them to our app’s ad slot, reading over the tiers and weight configuration stuff just enough to figure to put each in a different tier, run it, and …. why yes, there’s our Flurry ads popping up. Doesn’t want to serve us any iAds, though. Which could be because we just enabled them for this app in iTunes Connect, or it could be because we’re in Canada; we’ll email Burstly support and see how quickly they get back to us on that.

[EDIT: Burstly support was back to us at 9:14 AM the next morning, and the problem wasn’t them apparently; our own ADBannerView returned “no qualified ads found for this request” instead of the expected test ads as well until … wait for it … we ran the app in the Simulator. And it continued serving up test ads as expected once we built for the device again. Black voodoo magic like that always makes us profoundly nervous; but hey at least whatever the deal was appears unrelated to using Burstly…]

Lastly for now, we’re to add some house ads to this as well; so we create one following the instructions, with a 320×50.png and a link to the App Store; add it at the highest tier, and … there it is, link works, ex-cellent.

So we’ve got a little reading up to do to sort out these tier and weight things to get the rotation working the way we want, and signing up for a few more networks would be a good idea no doubt; but hey, from what we’ve run through so far here, we do believe that we can give Burstly our pretty well unqualified stamp of approval for your advertising management needs … just as long as that five meg it adds to your executable isn’t a dealbreaker!

Locayta Search

Historically options for natural language search functionality on iOS have been not precisely trivial to implement, but here’s something in beta you’ll probably want to look at if that’s something you have a need for: Locayta Search Mobile!

… The challenge for any content publisher therefore, is how to support their users in finding the content that they are looking for.

Locayta Search Mobile solves this problem by providing highly accurate and relevant search results, enabling users to find exactly what they’re looking for. Locayta Search Mobile is one of the most advanced search engines on the market. A Beta version of the software is now available for the iOS platform…

Yes, yes. And what makes it “advanced”?

The search engine provides full text search using a probabilistic model of document terms, along with clever features to improve search success such as automatic spell correction (based on trigram analysis of terms) and word stemming.

OK, that sounds “advanced” yes; more details here on what’s in now and what’s promised for later.

And no doubt your immediate reaction is “So how much?” and that is in the FAQ:

The Software is free of charge to use for development and testing only during the Beta programme. Thereafter, you will need to acquire a Software Distribution Licence, which is free of charge for non-commercial use or $1,000 one-time charge per published iOS application for commercial use applications.

So hey, if you’re doing some pro bono work, there you go then; otherwise, well, if you really REALLY need super-duper search, $1000 is almost certainly a good deal. Assuming it works, of course. Don’t have the spare time to check it out ourselves in the near future, but if you do, sign up here for the beta and let us know how you get on!

h/t: @Dr_Touch!

Wireless Ad Hoc Distribution

[EDIT: Obsolete.]

So a while back there was this article drawing our attention to the fact that the description here

Installing Applications and Distribution Provisioning Profiles Wirelessly

iOS 4 supports over-the-air installation of enterprise applications, allowing you to distribute in-house software to your iPhone and iPod touch users without having to use iTunes or iPhone Configuration Utility…

is not, in fact, limited to enterprise applications; any ad hoc application can be distributed this way. Long as they’ve upgraded to iOS 4, and so iPads are right out, mind you; but still, this would appear to have significant possibilities for simplifying our ad hoc install support, so let’s give it a try and see how it works, shall we?

Conveniently (this is the great thing about being behind the curve, isn’t it?) there’s been a couple runs at simplifying things even further:

Introducing iOS Beta Builder — wait for it — introduces iOS Beta Builder, just released on github:

… Enter ‘iOS BetaBuilder’ – a simple MacOS X app takes your archived IPA file and creates the required manifest and HTML files for wireless distribution. It even zips up a copy of the app for folks on 3.x that need to install via iTunes…

So, let’s try that out. ‘Build and Archive’ today’s beta release, check. ‘Save To Disk’, check. Drag onto BetaBuilder.app, check. Type in a URL … hmmm … check. ‘Generate Deployment Files’, and … yep, there’s some files there. Notably, “index.html”:


Alrighty, pop that folder up to the website, and let’s try this out. Deleting the appropriate ad hoc profile from the device just to make sure the magic all really happens. Off to the URL we entered, tap to install, installing … yep, it works. Woah. That was, like, too easy.

So hey, mad propz to Messr. Hunter Hillegas for a fine job well done there, indeed!

Now, if you want to be more hardcore about your wireless ad hoc support, look into “Hockey”:

Announcing Hockey, an iOS developer framework

The beta application can be installed by clicking on a link on a webpage and the application will notify the user automatically when it starts, if there is an update available and the user can install it from within the application. Wherever they are and whenever they want. No iTunes required, in fact, not even a computer is required any more! All that is required, is a webserver and some simple code to be integrated.

To fill in more details from the github page:

Hockey is a iOS Ad-Hoc updater framework. It can be used for all apps that target the Apple AppStore and improves the beta testing process dramatically. All beta testers. It consists of two components, a server and a client framework.

The server component is required for all scenarios. But it also can work standalone without the client library. It provides a web interface which beta testers can use to install the latest AdHoc provisioning profile and also the latest beta version via Safari right from the device. One server installation is able to handle multiple applications via different bundle identifiers (I highly suggest using different bundle identifiers for Debug, AdHoc Beta and AppStore release builds !!!).

The client framework should only be included in AdHoc builds and should NOT (!!) be used in AppStore distribution builds! By default the client library will check for updates on your server whenever the app is started or will wake up. The user can adjust this in the settings dialog to alternatively only check once a day or manually.

So there’s definitely more capability there, having the application notify the testers to update does streamline the process even more, yes … but this strikes us as just a little more effort than we really need to go to at this exact moment, so we’ll stick with the dead simple iOS Beta Builder flow for now. At least until we get some real world experience with how reliable this method actually is … and most likely until iPads get 4.x so they can use it too. But hey, if you go straight to setting up this Hockey thingy, let us know how it works for you!

h/t: iOS Development Goodies

Prototyping: Briefs

So maybe you heard about this Briefs thing before,

Presenting a toolkit for packaging your mobile concepts into prototypes that run live on the iPhone and iPod Touch. It allows you to experience the feel of your concept without expensive development.

and if you had you’ve been waiting a while apparently, but the wait is now over … kinda:

… I have waited three months for a resolution—any resolution—on the matter of Briefs’ admission into the App store and have grown weary waiting for a response…

(Yes, “weary” is one word that could be used in that kind of situation, we feel for you dude…)

… So instead of trucking along, and growing more resentful of the project, I’ve decided to take a break. And to cool the sting, I’m releasing the 1.0 code base to github today.

Worth checking out no doubt; and to get your self-righteousness fired right up if it isn’t already, don’t miss Jeff Lamarche’s rant on the situation. Yes, if there’s one thing that does actually strike us as well-taken criticism of Apple, it’s when your products disappear down the review well like this and THEY WON’T TELL YOU WHAT THE @(#$&@#$^!!! PROBLEM IS, indeed.

h/t: @iosdevgoodies!

Gesture Recognizers

So no doubt as your projects move to requiring iPad/4.x you’ve been considering using those newfangled UIGestureRecognizer thingies to save a bit of code; and here’s a few pieces to help bring you up to speed.

Nice gentle introductory walkthrough:

Implementing Gesture Recognizers

More detailed introduction, with sample project:

Gestures Recognizers in iOS

Dr. Touch has a couple handy tips for mucking around with default UIScrollView behaviours, and simplifying cell interaction:

Hacking UIScrollView Gesture Recognizers

Tap&Hold for TableView Cells, Then and Now


Couple more good introductions:

The Joy of Gesture Recognizers in iOS and followup Adding subgestures to iOS gesture recognition

AppStore Review Links Redux

[UPDATE: How did you get here? This is way obsolete — go read iTunes Affiliate Changes!]

If you’ve been including direct review links in your apps — personally, we’ve found the itms-apps:// URL scheme described here to be the most reliable for that — here’s a subtlety for iPad-only apps that may have escaped you:

… The above link takes you directly to the review page, which is one layer down below the main app description page on the iPhone. If you have an iPhone-only, or a universal app, this link will also work on the iPad (however, it will give you the iPhone AppStore review page for the universal app). Unfortunately, this page does not exist in the iPad AppStore. All reviews are listed at the bottom of the description page, similar to the desktop iTunes AppStore, without having to drill down.

When setting up a review link to an iPad app, it makes more sense to link to the main page of the app (just change the appname and id#–the id# is optional):


This time, we use “itunes” instead of “phobos” because on iPad, the “itunes” link knows where to go, and doesn’t have any redirects, opening the iPad AppStore directly.

Good to keep that in mind, whatever scheme you use for non-iPad only apps. Of which, besides the itms-apps:// that works for us, and the http://phobos.apple.com scheme in the above link, another popular one is https://userpub.itunes.apple.com as mentioned here. Hopefully one or the other of those will have some chance of working no matter what changes Apple makes in the future…


h/t the last link there, this article tells you how to provide a single URL for redeeming a promo code, in case like us you’d managed to overlook that so far:

There’s a little-known iTunes Store URL that enables you to easily provide promo codes that can simply be clicked or tapped to be redeemed (replace “REPLACEWITHPROMOCODE” with the actual promo code):


And the great thing is that these URLs work in both in iTunes on the user’s computers and on their iPhone/iPod touch devices.

That’s significantly easier than trying to explain “OK, this is what you do with a promo code…”, indeed!


Here’s another take on the etiquette and practice of requesting reviews:

Asking for App Reviews

iOSDevCamp Hackathon

Just in case you missed it, the iOSDevCamp Hackathon Winners are posted; worth reading through all the winners, but here’s some particularly interesting open source bits:

Coolest App: SuperRover “Want to control a Lego Mindstorm NXT rover with an iPad over bluetooth? There’s an app for that!”

Most Accessible: Accessible TableView Library “Open source library to make table-view apps more accessible to people who are blind or visually impaired”

Best Open Source: DragKit “DragKit is an opensource framework to help developers implement drag and drop within their app. DragKit also allows for drag and drop between applications that implement the framework.”

That last one does sound like there’s some interesting possibilities there, indeed.


[EDIT: Discontinued.]

So, looks like there’s a new App Store alternative around these days: OpenAppMkt! Basically they’re doing their best to replicate the App Store experience with HTML5 apps; and they seem to be getting a little bit of traction. As well as a good deal of frenzied yammering about “loopholes” and the like, from people whose memories apparently are not good enough to extend back to 2007 when we were all being told that HTML5 would be the only way to write iPhone applications. My, my, how things do change.

But, as we’ve pointed out before, Apple has continually improved the HTML app capabilities and development experience right along with SDK development; it’s just that people almost completely ignore that alternative … even when an HTML app makes scads more sense for what they have in mind. As well as being potentially cross-platform and all, especially as WebKit-based browsers continue their apparently inexorable march towards complete dominance of the mobile landscape.

But the thing that actually intrigued us whilst reading around on OpenAppMkt is that although several commentators have mentioned that Apple has their own web app directory, absolutely not a single piece we read seemed to have any idea of the existence of the first HTML app marketplace, that we posted about pretty much exactly a year ago; Hottrix and their Premier App Shop,

Screen shot 2010-08-21 at 10.34.35 PM.png

another genre-specific shop that blushing modesty bars us from mentioning, and Your App Shop for creating your own store.

Why that initiative hasn’t, in a year, seemed to go anyplace in particular and OpenAppMkt seems to have pretty solid interest out of the gate rather escapes us. Maybe the timing was wrong before, maybe the technology is better now (although the Premier App Shop webapp actually seems like the superior user experience to us) or maybe … well, we dunno. if anyone has any insights, please share!


My, it’s been a while since the last time we had a new trollish trifle for you to try, isn’t it? Our recent projects do just seem to be wandering off into the weeds in every direction, cha. But hey, here’s one today; yet another in the ever expanding collection of trinkets for those great Wayz guys, it’s … iGoalKeeper!


Just your basic catch the falling balls kind of thing,


but hey, if you’d like a momentary diversion … there you go!

[POST-MORTEM: Now withdrawn from store…]