Denis Papathanasiou

Friends have been asking why NYC*Fun isn’t in the list of NYC BigApps entries anymore.

The reason?

I decided to charge a modest fee ($1.99) for it in the AppStore.

The contest rules are not clear on that point, since they talk about being allowed to sell the app “elsewhere”, even during the contest period.

So I interpreted the AppStore as elsewhere, and I was planning to issue promotion codes for the judges so they could get the app for free, to evaluate for the contest.

Charging for it was primarily a hedge against not winning, and secondarily as a way of recouping some of the time and effort that went into making NYC*Fun (though on both counts, I wasn’t expecting to make a profit).

But, alas, the contest organizers felt that was unfair to “all New Yorkers, whose tax payer dollars were used [to make the NYC.gov Data Mine available]“.

That logic seems odd when it comes to iPhone apps in this contest.

If I am a tax-paying New Yorker without an iPhone, all I would have are contest videos of all the iPhone apps.

That’s hardly a way of providing me benefits in return for my tax dollars.

But beyond this single app in this single contest (and perhaps legally, the contest rep was correct in that I could not charge for it in the AppStore and still be eligible), the experience struck a chord because of another phenomenon I’ve been witnessing on a broader scale recently: the devaluation of software as a paid profession.

The undercurrent of my conversation with the contest rep was this: the City’s effort (i.e., time and money spent to provide the data) was more important than mine, even though most of information in the Data Mine is unusable without significant rework (reformatting, normalizing, and the like).

That’s a rant for a different day, though.

This episode did remind of my days in design engineering, and why contests in that world generate little enthusiasm.

The principals of the firm I worked for scoffed at the idea of entering contests, dismissing them as run by cheapskate clients who wanted free work.

The subsequent leverage those clients had with the contest “winners” was also significant, since the tacit threat of bringing in the runner-up firm was always there for the length of the engagement.

Perhaps the smartest people in all this are those who run Challenge Post, the private company hired by the City of New York to run the contest.

NYC*Fun (“nice fun“), my entry in the NYC BigApps Contest, has passed review and is now available in the AppStore.

Ad-Hoc Distribution, for letting beta testers get copies of iPhone apps before they’re available in the AppStore, has been around for a while now, and there are several guides on preparing and installing them.

Beta testers who use Windows Vista face a significant gotcha when they try to install the Application.zip file: the default “Extract All” action does not unzip the app correctly, and it won’t install on iTunes.

WinZip or WinRar can do the decompression without creating a problem for iTunes.

Even better, if you know which beta testers are using Vista, you can just create an .ipa file for them, which can be installed directly in iTunes without having to do any unzipping.

Once the beta test is over, all beta testers (whether they use Vista, XP, or Mac OS X) need to go into their filesystem to remove the ad-hoc profiles, otherwise iTunes will keep re-adding them to the iPhone with every sync.

This guide notes the exact folder for the different operating systems.

In a follow-up to the Apple dictionary censorship post which also affected Nihongo, the Daring Fireball blog got Phil Schiller, an Apple V.P., to comment on the matter.

Nihongo was mentioned in the list of “other dictionary apps which had the same review experience”.

Nihongo is an English-to-Japanese dictionary app for the Apple iPhone.

People who try to buy it in the App Store, however, get greeted with this rather unusual warning:

You must be at least 17 years old to download this application

• Infrequent/Mild Realistic Violence
• Frequent/Intense Mature/Suggestive Themes
• Frequent/Intense Profanity or Crude Humor
• Infrequent/Mild Alcohol, Tobacco, or Drug Use or References
• Infrequent/Mild Cartoon or Fantasy Violence
• Frequent/Intense Sexual Content or Nudity

When Nihongo was first submitted for review, I chose the most benign rating (4+), thinking that a simple dictionary would not be offensive.

That submission was rejected, because Apple’s reviewers cited the four letter words they were able to lookup.

So I re-submitted, this time ticking off “Infrequent/Mild” in most categories, which pushed the rating up to 12+.

That submission was also rejected because “it is not appropriately rated“.

So I contacted the reviewers by email (unfortunately, there is no telephone access) and asked:

I’m not sure how to respond to your comment that the rating is inappropriate.

“Nihongo” is a Japanese dictionary.

As such, it contains some profanity, sexual content, etc. but the bulk of the content is not in that category.

That is why I rated it “Infrequent/Mild” for those content types.

Are you suggesting I need to go back and use “Frequent/Intense”?

It seems incorrect.

How are other dictionary apps rated?

Apple did not send me a reply.

So in my final submission (remember that neither the content nor the functionality of the app had changed in all this time), I changed some rating categories to “Frequent/Intense”.

That got Nihongo accepted, a mere six weeks after the initial submission.

Today I found out my experience with Nihongo was not unique, as NinjaWords had the same problems in review, and also had to accept a 17+ rating before their app could be sold in the App Store.

The default list of color settings in UIColor is fairly limited: black, darkGray, lightGray, white, gray, red, green, blue, cyan, yellow, magenta, orange, purple, brown, and clear are the choices.

Other than limited choice, a problem with the default palette is that there’s no control over how each specific color is defined (e.g., the green might be too light or too dark for a given application, etc.).

Following this suggestion (thanks ooo27), here’s how to set UIColor to any html hex color code.

Create a macro within the class implementation (.m) file:

#define HEXCOLOR(c) [UIColor colorWithRed:((c>>24)&0xFF)/255.0 \
                                    green:((c>>16)&0xFF)/255.0 \
                                     blue:((c>>8)&0xFF)/255.0 \
                                    alpha:((c)&0xFF)/255.0];

And then use it when initializing any UIColor class.

For example, try:

UIColor* c = HEXCOLOR(0x006600ff);


instead of:

UIColor* c = [UIColor greenColor];