Archive for November, 2009


Rejection Sites

Although the site for chronicling misadventures with the Apple review process that we mentioned a while back seems to have gone hors de combat, and the site listing issues you may run into doesn’t appear to have been updated in quite a while as well, we have a new site for dishing out the rejection goodness:

App Rejections!

If YOUR iPhone app has been rejected by Apple in an unusual or unfair way, please write about it on your blog / news / etc, and send a link to @redglassesapps on Twitter.

Always good to keep on top of this kind of thing to avoid problems … or just for a good laugh.

Our book about the iPhone has been rejected from the App Store BECAUSE IT CONTAINS THE WORD iPHONE.

Heh. Besides the inherent humor factor, that’s actually a particularly good one to read to illuminate the frustrating capriciousness you can run afoul of … not to mention how making a big public fuss can resolve things for you. Heh, heh.

Any-ways, we thoroughly recommend reading and keeping up with the posts on any sites of this sort. Forewarned is forearmed, and all that.

h/t: iphonesdk!


In-App Purchase experience

Don’t miss reading this post mentioned on iphonesb about one first movers’ experience with in-app purchase for a free game:

I thought many of you might be interested in seeing our initial results from releasing Gravity Sling as a free app with In App Purchase a couple weeks ago. I’ve posted a lot of data and charts here:

The super-quick hits are: 

  • Total conversion rate around 2%
  • Regional differences are present, with US at almost 3% conversion 
and Italy at just .78%

Also interesting is the corollary between OpenFeint and conversion. We 
found that OpenFeint users were 3 times more likely to purchase a 
level pack than non-OpenFeint players…

Lots of hard data to chew over there!


Tips: Demo Video

Good article over at Mobile Orchard today:

Five Tips for Producing a Demo Video for Your iPhone App

One of the best ways to showcase your application’s functionality is to produce a great video. A video is one of the few opportunities potential customers will have to experience your application before buying it. And, a great video is an important key to getting iPhone app reviews. Here’s five tips to get you pointed in the right direction:

Worth the read. Check the comments as well for alternative suggested workflows!


Tools: Texture Atlases

Here’s a list of tools you may find handy for creating your OpenGL texture atlases, aka “sprite sheets”:

As always, if you have other suggestions, or direct experience with any of these, comment away!


Review: Wifi Body Scale

And today something we don’t get to do nearly enough around here; play with a new toy! Specifically, soon as we found out that there was such a thing as a wifi-enabled weight scale with an iPhone app — no, seriously, a wifi-enabled weight scale, with an iPhone app, you read that right –


– well hey, we just had to order that sucker immediately. So you get it in a couple days, the Withings people are good with their shipping, and — ooh! It’s shiny! — snap in the batteries and connect it up with the USB cable and go to their website, and it downloads a little native application that fixes your shiny new scale all up for you:


There’s just something intrinsically hilarious about a dialog that reads “Restarting the scale…” isn’t there now? Ah, the marvelous cognitive dissonance of our increasingly wired world. Oops, we mean, “wireless”, because the included USB cable mentioned above is only for the initial setup apparently, once you’ve sorted it out with the target wifi network apparently you don’t need it again. Surfing around the web we saw some complaints from people who claimed it wasn’t so good at connecting, but certainly we haven’t had any trouble getting started; found a place for it, hopped on, waited a few seconds for the little fat-measuring bar to dance across, and yeppers by the time we got back to the computer there it was on their web dashboard. You can even have it tweet every measurement, if you’re like extra narcissistic or something; but we figure that for pretty much everybody in the world except ourselves knowing the exact fat content of a troll would be way way into the TMI category.

And, of course, the defensible motivation for getting this shiny toy was to check out the iPhone app integration,


which is quite nicely done indeed. About the same information as in the web browser interface, but very dextrously adapted to the iPhone, particularly the very natural feeling way they use swiping and orientation changing to get the various graphs displayed. Nice job all around, and worth taking a gander at if you’re designing any kind of horizontally charted data displaying application, we’d say.


So there you go. If you’re really obsessed about tracking your weight/fat composition comprehensively, or if you just dig cool toys, we quite thoroughly recommend picking one of these up! At least judging by our exactly one weighing so far; but hey, how cool is it to say “there’s an app for that” about your weight scale?


iPhone DNS

So as you’ve no doubt noticed if you’ve tried to port conventional DNS resolving code like ares to the iPhone, your desktop Mac OS code to get DNS servers like this

SCDynamicStoreContext context = {0, NULL, NULL, NULL, NULL};
SCDynamicStoreRef store = SCDynamicStoreCreate(NULL, CFSTR("init_by_defaults_systemconfiguration"), NULL, &context);
CFStringRef key = CFSTR("State:/Network/Global/DNS");
CFDictionaryRef dnsDict = SCDynamicStoreCopyValue(store, key);
CFArrayRef addresses = (CFArrayRef) CFDictionaryGetValue(dnsDict, kSCPropNetDNSServerAddresses);

doesn’t work so hot, as SCDynamicStore APIs aren’t available. What to do? What to do? Well, when we first encountered this problem, after asking around the developer forums, and StackOverflow, and macnetworkprog, we didn’t get any good advice besides “rewrite using Bonjour”, essentially. Luckily, in our particular application we could put in hardcoded server addresses and pretend the problem didn’t exist.

But even more luckily, there are people out there better informed and/or more tenacious than trolls; so here is a solution using resolv.h that some bright spark who stumbled across our begging on the dev forums came up with, which you could try should you find yourself in this situation. As a patch to ares_init.c, it looks like

if ((_res.options & RES_INIT) == 0) res_init();
channel->nservers = _res.nscount;
channel->servers = malloc(channel->nservers * sizeof(struct server_state));
memset(channel->servers, '\0', channel->nservers * sizeof(struct server_state));

int i;
for (i = 0; i < channel->nservers; i++)
    memcpy(&channel->servers[i].addr, &_res.nsaddr_list[i].sin_addr, sizeof(struct in_addr));

Excellent, excellent. It’s so nice to have competent people around to sort you out, isn’t it?


Push Notification Faceoff

You might recall our roundup a while back of middleware push notification services underway or in the works; well, here’s a head to head matchup of the two biggest, iLime and Urban Airship, from a fellow who actually implemented both. And what did he end up with? Why, his own!

… I ended up hijacking the Urban Airship client for my own purposes and modified it to interface with my own home grown implementation. Most of my time was fiddling with the iPhone client app, but once I had things working so that I could run the app and have my server send it notifications. I didn’t feel that the implementation of the server side of sending notifications to APNS was complicated, but I come from a background where I work with this sort of integration quite often. It would likely be pretty daunting to the uninitiated.

And why would one go to that trouble?

I’ve come to realize that the code that does the actual communication of the notifications to the APNS is actually only a relatively small part of what needs to be built. Neither of these services can figure out how often, how much or what you want to notify your users with. Nor can they design your app to consume the notifications in a way that’s uniquely meaningful to your users. From looking at their APIs, they seem to have built some additional functionalities that would be nice (like usage reporting and broadcast notifications) but even those could be built without that much extra effort. I can imagine an app that needs only occasional notifications to be manually sent or, if the developer just didn’t want to have to set up their own server to support push notifications then middleware services such as these have their place. Urban Airship provides a much easier service to use and I give them the thumb’s up. However, there is so much more to integrating push notifications than just the transport of the messages, and I believe it’s worth the effort to not have to a man-in-the-middle between you and your customers (or your revenue stream).

A cogent perspective, yes. However, our standards of “worth the effort” are very very high indeed, so we’re pretty confident that at least for initial implementation soon as we get around to starting that push notification using project we’re supposed to be working on … for a while now, actually … we’re going to go with the middleware people. The best code is code you don’t write, and all that. And apparently we have an informed vote here in favor of Urban Airship!


Snippet: UILabelWrap

So you ever thought to yourself “Now wouldn’t it be convenient if UILabel would wrap on its own so it would be as convenient as UITextView but still have convenient shadows?” but never quite got around to bothering to write a replacement yourself? Yep, we’re there.

So here is your dropin replacement: UILabelWrap.

Nothing particularly tricky, but hey, code that you don’t write is the best kind!


Prioritized image loading

And for today’s entry in the annals of niftiness, here’s a background image loading class that does loading and caching of images in a table with a placeholder and all that stuff you’ve probably done before, but what makes it nifty is that it’ll automagically adjust loading priority based on visibiility.

We created EGOImageLoading to be as easy to use as HTML. EGOImageLoading is a few classes to make life easier on the developer, and to give the end user a much smoother result, easily.

Here’s what EGOImageLoading does:

  • It loads the image in the background
  • It caches the image to the disk for you
  • It allows you to set a placeholder image while it’s loading

And here’s where it gets even more awesome: It changes loading priorities on the fly. If the user scrolls a bit in the table view, it’ll decrease the priority of those images, and load the ones they’re looking at right now, first.

And how does it do that, you wonder? Well, your cell gets notified when it moves to a new superview; so if the new superview is null, then decrease priority:

- (void)willMoveToSuperview:(UIView *)newSuperview {
   [super willMoveToSuperview:newSuperview];
      [imageView decreaseImageLoadPriority];

Code can be found on github, enjoy!


Roundup: UI Design

So it’s been a couple months since we dragged our posts on various artistic bits into UI Design For Artists, and yep, we see in this vancouver-iphone-developers thread that things just keep moving along. Let’s take a look at what’s new in the non-programmer UI design world, shall we?


MockApp — This Keynote (or PowerPoint, if you’re stuck with really hopeless designers) template claims to be the most comprehensive vector iPhone tool out there, and we see no reason to question that. So if you’re currently using the Photoshop, OmniGraffle, or whatever templates linked through the post above, might want to check this one out.

Demo Framework:

Briefs — “is a framework for packaging concept screens & control schemes that run live on the iPhone and iPod Touch. This allows you to experience the feel of your concept without the expense of development.” Personally, if we were going to as much trouble as it would take to put something together with this, we think we’d just slap together a real application shell … but hey, no doubt it has its place, and we do like to be exhaustive in our roundups, yes.

Sketch paper:

OK, we thought that a steel UI stencil was pretty neat a few months back — and there’s an acrylic one available now too — but it seems the latest trend is actual preprinted dead tree products for offline UI design:

And for actual books, courtesy of TUAW’s shootout we learn about

  • iPhone Application Sketch Book– 150 pages, 1 template at 150% size and lots of room for notes on each page. Now published by Apress — an update since the TUAW article, apparently — and from the same fellow who did the acrylic stencil mentioned above, so presumably they would work together well.
  • App Sketchbook — “Designing iPhone® Apps? There’s a sketchbook for that.” How cute. Wire-bound, 50 double-sided pages perforated or not, 3 templates a page.
  • The Developer Sketchbook for iPhone Apps was TUAW’s favorite, the most elaborate by far of the bunch by far. As advertised:

    • 100 Pages of 320 x 480 Grids for Portrait User Interface Design
    • 100 Pages of 480 x 320 Grids for Landscape User Interface Design
    • 200 Pages of Flowcharts for Outlining an App’s Navigation
    • 100 Pages of Square Grids for App Icon Design
    • Dedicated Space on Every Page for Detailed Notes
    • 518 Pages Total = Great Value!

So there you go. And if that sounds like just the kind of fun you’re looking for, here’s your handy ordering link, go wild!