Aug 31

If you are considering attending the 360|iDev conference in Denver, September 27-30, and you have not yet purchased your tickets, then today would be a good time to do so. The conference organizers tell me that starting tomorrow, the price will going up every week.

Check out the great line-up of speakers here: 360|iDev

written by Nick \\ tags:

Aug 25

Recently I’ve been seeing many apps where the name of the app that appears under the app icon is truncated. Before I even launch the app, I know that the developer doesn’t care about the appearance of their app. Sad.

The solution is trivial.

The 5 second alternative is to edit the project’s Info.plist file. Change the value of Bundle Display Name from ${PRODUCT_NAME} to the name of your app.

The 60 second option is to create an InfoPlist.strings file in each of your language directories (e.g. en.lproj). Add this line to the file: ”CFBundleDisplayName” = “YourNewAppName”;

The benefit of the latter approach is that you can specify localized names for your app. You are translating your apps to other languages than English, right?

written by Nick

Aug 21

Apple posts their answers to the FCC’s questions.

One of the more interesting items posted was the statistic that “more than 40 full-time trained reviewers” review 8,500 new applications and updates per week, and at least two reviewers study each application. Some quick math reveals that each reviewer spends on average 5 minutes testing an application. That explains a lot.

People are questioning if the 40 full-time reviewers is the entire review staff, or if there is an additional group of front-line reviewers. (Would these people be part-time and/or untrained?) Also, how can 40 reviewers (or really 40 / 2) handle all the languages stemming from 77 country specific App Stores?

Now that I got my frustrations with the App Store out of my system, I promise that this will be the last post on this subject for a while. Now back to the regularly scheduled programming.

written by Nick \\ tags:

Aug 17

Yesterday I told you about Bikini Blast which was held up in Apple’s approval calamity for four months. Today I’m going to top this by a wide margin. Here’s the story, in the words of my client:

It seemed like a good idea: Build a fun, flirty iPhone app that generates millions of custom pick-up lines on the fly, simply by tapping in specifics of a situation: A user enters the place, time of day and characteristics of his intended date, hits a button and chooses a line ranging from clever to clumsy. And just to keep things under control, the user can choose between lines that are either Safe or Sexy.

The app is called LittleWingman (www.LittleWingman.com) and it tested through the roof. It’s an equal-opportunity app, generating pick-up lines regardless of gender or orientation. And because it contains no graphics, no profanity and no abusive language of any kind, we knew it was a cinch to gain approval from Apple’s iTunes Store. And it did. Eventually.

Nine gruelling months after it was originally submitted.

Why was LittleWingman constantly rejected? As it turns out, not for any specific objectionable words or graphics — it doesn’t have any. In fact, LittleWingman may be the first and only app ever rejected purely for the sexual ideas it stimulates in users’ minds.

Are phrases like “tight-fitting jeans” and “legs” objectionable? Not to most people. But when LittleWingman composed them into the following line, iTunes had a big problem with it:

“I’m tonight’s official legs inspector. I’m going to have to ask you to remove those tight-fitting jeans.”

At first, we thought iTunes objected to words like “breasts” and “ass” — two commonly used words in many other apps. So we replaced those with “casabas” and “tush,” only to be rejected again. Within a week or two, the same canned message came back with the same canned rejection:

At 5:51 PM -0800 3/5/09, xxx@apple.com wrote:
Thank you for submitting LittleWingman to the App Store. We’ve reviewed LittleWingman again and determined that we still cannot post this version of your iPhone application to the App Store because it contains inappropriate sexual content and is in violation of Section 3.3.12 from the iPhone SDK Agreement which states:

“Applications must not contain any obscene, pornographic, offensive or defamatory content or materials of any kind (text, graphics, images, photographs, etc.), or other content or materials that in Apple’s reasonable judgement may be found objectionable by iPhone or iPod touch users.”

If you believe that you can make the necessary changes so that LittleWingman does not violate the iPhone SDK Agreement we encourage you to do so and resubmit it for review.

We combed through the content again, looking for any profanity or objectionable content. But we could find any, because there wasn’t any. It was the app that was writing the content by itself, based on what the user had chosen.

For example, LittleWingman generated this line for a user who finds herself at a wedding: “Think any of the rabbis at this ceremony can lend us some personal lubricants?” Random? Funny? Hardly as objectionable as a flushing toilet, upskirt shots or jiggling breasts, yet Apple rejected that generated line flat out.

The correspondence flew back and forth, with LittleWingman getting rejected for combining innocent phrases like “kiss” with innocent body parts like “lips” into pick-up lines that resulted wonderfully appealing ideas as to what things people might actually kiss with their lips. Each time, the App Store returned the same canned response, with no guidance as to fixing the problem, mainly because there was no problem there to fix. Unlike the “baby shaker” app, LittleWingman was pure, positive pick-up lines — and healthy ones, at that.

At six months, we thought we had a breakthrough: iPhone 3.0’s 17+ rating was just the ticket to get us past our non-existent objectionable content. We re-submitted and got rejected. Again.

The maddening, automated responses were finally disrupted when, after seven months, a breathing App Store human being actually left a voicemail at our offices. We began the dialogue which, two months later, resulted in LittleWingman being approved — with only two word changes from its original submission. And that, as it turns out, is the main problem with technology: it lacks human judgment, which cost us time, energy — and nine months’ of sales.

It’s been nine months of nuttiness. But at least now the world doesn’t have to struggle with how to approach that blonde at the end of the bar.

NINE MONTHS! Insane. That has to be a world record. And for the sanity of all iPhone developers out there, I sincerely hope so. Maybe I can submit it to Guinness Book of World Records?

You can find LittleWingman in the App Store here. You won’t find it anywhere on the What’s new pages in iTunes, because the date of the app is Jan 21, 2009. Another not so nice side-effect of the App Store approval process.

written by Nick \\ tags:

Aug 15

This is the second part in a series about iPhone application being rejected by the App Store. You can read the previous part here: 57 Ways To Get Your iPhone Application Rejected From The App Store and the accompanying App Store Rejection Reasons list.

I always inform my clients about the “objectionable content” clause in Apple’s iPhone developer agreement to let them know that there is always a risk that Apple will reject the app and their development investment may be lost. Some clients find this level of risk to be unacceptable, and they walk away from the platform. This self censorship is not good for my business, and in most cases it’s not good for Apple either.

When I was approached by the publishers of this book I didn’t imagine that it would get caught up in the objectionable content morass. The book is political satire and in my opinion hilarious. Each page has a real photo of a famous politician to which Mr. Lee has added his own cartoon style talk bubbles. With the limited amount of text on each page, I thought this would make a great iPhone app. Apple unfortunately thought otherwise. After five weeks in review, the app was rejected because it was “defamatory”.

Steve Jobs famously replied to a developer who had developed an app that counted down the number days remaining of the Bush administration. Steve’s defense of that rejection was to ask why should Apple risk offending half their customer base. I don’t know if that put the kibosh on all apps that could raise some political ire. I didn’t tally the jabs in Election Daze to see if one side came out ahead, but it seemed pretty evenhanded to me.

In the end my client decided to drop the fight with Apple. The presidential election was quickly approaching and their carefully timed promotional campaign was not going to be able to ride the tide of political interest.

My second example is an app that we knew from the beginning was going to be a tough battle with Apple. The client was prepared for this and had the patience and resources to ride it out. The application is Bikini Blast which is a wallpaper download type app with photos of, you guessed it, women in bikinis. (I want to point out that we also developed iWallpaper for this client and that app has a category called “Hunks”. So this is not a gender issue.)

Our client sells wallpapers and applications for many other phones, so he has experience dealing with all the major carriers and their content rules and he used that experience when selecting content for Bikini Blast.

Note to Apple: All the major carries have published very clear guidelines on what is acceptable content and what is not. Furthermore they have outsourced the approval of such content to a few companies that specialize in this. I think this is a great way to establish a policy and then take a step back from the daily headaches of deciding what to approve and what to reject.

Bikini Blast was submitted to the App Store in October 2008. Then we heard nothing. This was before Apple started sending out the “this app is going to take longer to approve emails”. So no email. No phone call. No smoke signals. Just complete silence for FOUR MONTHS. Then suddenly out of the blue in January 2009 the client received the approval email.

I said in the first part of this series that these spectacular rejections and wait times are exceptions. However, the point is that they do happen often enough to give businesses pause before diving into iPhone application development. It is difficult to build a business around a platform when the rules are not known, the wait times are indeterminate, the communication is nonexistent, and there is no way to appeal decisions or even have a discussion with anyone responsible for the process.

If you thought four months was a long time to put your business on hold, that’s nothing compared to the next story. And all you have to do is wait until Monday for the next installment of this series.

written by Nick \\ tags:

Aug 12

App Store rejections is a part of life for us iPhone Developers. Recently there have been several high profile rejection cases that have garnered the attention and response from Apple’s top level management. This is most welcome news!

I genuinely believe that Apple does not have evil intentions when it comes to approving iPhone applications for the App Store. I think the problems that we are seeing are the bumbling results of a process that was hastily put in place and which is still trying to catch up with the flood of new applications and the many intricate policy decisions required. Apple’s self-imposed cone of silence doesn’t help their cause and it frustrates developers to the point of giving up.

This is the first post in a series where I want to constructively add to the discussion.

The meat of this post is on a regular web page that you can reach from the main navigation on this blog. I want to maintain this page as a comprehensive resource for all the technical things you need to think about and comply with before you submit your application to the App Store. I welcome your feedback and additions to the list.

It is my own experience that most App Store rejections are valid and they make sense, at least when they are explained to us. I also think Apple’s recent moves to pay more attention to copyright infringements is good.

However it’s the few cases where the App Store reviewers seem to have gone off the deep end, that we love to talk about. I’ve had my share of these too, and I’m going to dish out the details in the following posts:

  • The story of a mainstream book that was too funny to be accepted. I’m sure you will recognize the name of the author.
  • The inside story of an app that broke new ground in the App Store and paved the way for a whole new category of apps. For better or worse, depending on your perspective. That app sat in the queue for four months.
  • If you think four months was a long time to wait for an app to be approved, wait until you hear about my own personal record.

But before we get to the juicy stuff, please head over to App Store Rejection Reasons.

written by Nick \\ tags:

Aug 11

In Interface Builder there are several places where you can seemingly set the style of the status bar. In a drop down you can select between None, Gray, Black and Translucent Black. The status bar on the screen in Interface Builder immediately changes to match your selection. But when you run your application you will notice that the status bar is back to the default gray color. What gives?

If you look closely at the Attributes Inspector Window in Interface Builder you will notice that it says “Simulated Interface Elements” above the drop down for the status bar, and a few other settings. This discrete headline is Apple’s way of telling you that the changes you make here only apply to Interface Builder, and the purpose is to help you visually design your screens. But to actually implement these settings you have to do something else. It took me a while to understand this “hidden” meaning too…

Setting the style of the status bar in code is easy enough. In applicationDidFinishLaunching you can add this line of code:

[application setStatusBarStyle:UIStatusBarStyleBlackOpaque];

When you run the app, the status bar will be a pleasing black color. However, if you look closely at the status bar while the app is launching, you will notice that it briefly turns gray. That is of course not acceptable.

So take out the line of code you just added to your application delegate. And instead add this to your Info.plist file:

<key>UIStatusBarStyle</key>
<string>UIStatusBarStyleBlackOpaque</string>

If you prefer to edit/view Info.plist as an XML Property List, it should look like this:
Status bar style = Opaque black style

written by Nick \\ tags: ,

Aug 07

In the Build Results window of Xcode, the list of errors is not a plain text view so you can’t highlight and copy text from it like you might expect. However you can drag a whole row as a text clipping.

If you drag the error line and drop it onto Safari in the Dock, Safari will open and automagically do a search for the error text. Even though you can only drag a single line, which may not contain the whole error message, it’s usually enough as a search criteria.

I recently encountered the somewhat cryptic error message “___restore_vfp_d8_d15_regs, referenced from:” and after a quick drag-drop-click I had the solution. Nice!

written by Nick

Jul 30

Lately there is no shortage of rumors surrounding a new tablet device supposedly in development at Apple. Besides satisfying our lust for new shiny gadgets from Cupertino, what does an iTablet mean for us iPhone developers?

Operating System

Given the theme at WWDC ’09 of there being one operating system for Macs and iPhones, it seems obvious that an iTablet would run OS X.

The real question is what type of UI would they layer on top of an OS X core? My guess is an extended version of UIKit. Apple has spent a lot of time thinking about how to build user interfaces for non-desktop devices, and unlike other competitors’ offerings, UIKit is very well designed.

On a small screen like the iPhone’s you are by necessity focused on a single task, and therefore it does not make sense to have a windowing system. On a 10” screen the situation is different, and I hope that Apple doesn’t lock us into a single task metaphor. At a coding level I don’t see why an application couldn’t manage multiple UIWindows instead of the single one you’re used to on the iPhone.

Processor

AppleInsider had a great story about the iTablet, going into a lot of detail regarding the choice of the processor: ARM. Besides being good news for battery life, that is also good news for iPhone developers since that presumably means that the iTablet would be able to run iPhone binaries natively.

iPhone Compatibility

Apple acknowledges that a large part of the iPhone’s success is due to the App Store and the >65k applications available just a tap away. So consider the jump start an iTablet would get if it could run all those apps out of the gate.

Imagine that the iTablet had an iPhone simulator similar to what we’re used to in Xcode. If Apple spent some time on polishing the simulator app and integrating it better with the hardware (e.g. accelerometer, full OpenGL graphics support, camera, GPS) there’s no reason why it could not run a majority of the iPhone apps available on the App Store.

Even if the processor was not an ARM processor, running iPhone apps on the iTablet could be possible just like the Xcode iPhone simulator currently runs code compiled for i386. All iPhone app developers would have to do is recompile their iPhone apps into universal binary style bundles.

Going Beyond the iPhone

Apple has done an excellent job of keeping compatibility between the various iPhone/iPod Touch devices. New hardware features are add-ons that an application can take advantage of, while still working on older devices.

The main challenge of a tablet style devices is of course the screen size. UIKit is not locked in to 320 x 480, but there are no features that make resolution independent graphics easy. You could argue that moving between portrait and landscape modes on the iPhone is a taste of what is to come. If your application can adapt its screen layouts between 320 and 480, then going to other resolutions would not be a quantum leap.

Say that by default the iPhone simulator on the iTablet launches into 320 x 480 mode, but you have the familiar OS X red, yellow, green buttons in the top left corner of the window that could change the size of the window. If the iPhone application is capable of rendering on a larger screen then it just shifts into that mode. (Much like the OS X Calculator changes modes when you click the green button.)

Start Planning Now

While a tablet device is likely to be a smaller market than a phone, it doesn’t hurt to have another outlet for your apps. Start thinking about how your current iPhone apps could make best use of a much larger screen, while keeping the UI simplicity of the iPhone.

Disclaimer

I have no insider knowledge of Apple’s plans. If I did, I couldn’t be writing this post. The above speculations are purely my own, and as such they make sense to me. Please let me know what you think in the comments.

written by Nick \\ tags:

Jul 07

I just got accepted to speak at the 360|iDev conference in Denver at the end of September. Unfortunately I missed the first 360|iDev conference in San Jose this past spring, but I heard that it was very good. Given the long list of distinguished speakers at the Denver conference, I’m fully expecting this one to be just as good. Check out the details here: 360idev.com

Note: The similarities between our company names, 360mind and 360iDev, and our location in Colorado, are purely coincidental.

The topic of my talk is UIWebView – The most versatile class in UIKit

Here are some of the tips and tricks you will learn in the session:

  • Load images, CSS and JavaScript from your app bundle.
  • Display more versatile result lists than UITableView.
  • Use dynamic CSS to resize text in response to gestures.
  • Receive touch events that are normally hidden by UIWebView.
  • Use JavaScript to interact with UIWebView content.

If you have other questions or subtopics related to UIWebView, please let me know in the comments below. I’ll try to work in as many as I can into the presentation.

written by Nick \\ tags: ,