Uproar Blog

Tonight I started work on an iPhone project for a client.  As with all iPhone projects, it is important to determine what version of the iPhone OS SDK you will be targeting.  Thus, I need to pick my base and deployment SDK targets.

The base SDK is defined in Xcode as:

The name or path of the base SDK being used during the build. The product will be built against the headers and libraries located inside the indicated SDK.

Simply put, the base SDK is the maximum version of the iPhone OS that your code uses.

The deployment SDK is defined in Xcode as:

Code will load on this and later versions of iPhone OS.  Framework APIs that are unavailable in earlier versions will be weak-linked; your code should check for null function pointers or specific system versions before calling newer APIs.

Simply put, the deployment SDK is the minimum version of the iPhone OS that your app requires.

Let’s say you’re creating an iPhone game and you want this app to be available to users still on iPhone OS 2.0.  However, you’d really like to be able to take advantage of the GameKit API which was added in iPhone OS 3.0.  In this case, you would set your SDK targets as follows:

• Base SDK: iPhone OS 3.0
• Deployment SDK: iPhone OS 2.0

The base SDK is indicating that your game is compiled against the iPhone OS 3.0.  Thus, your app can only use APIs available in the iPhone OS 3.0 and earlier.  The deployment SDK is indicating that your game can be used on any device running at least iPhone OS 2.0.  Thus, your app can be used on a device running a later OS (eg, iPhone OS 2.1, 3.0, 3.0.1, 4.0, etc) — anything iPhone OS 2.0 or greater is fine.  Take a look at this Apple example showing  how you can optionally use a later API from your base SDK while still being compatible with your earlier deployment SDK version.

You set the base and deployment SDKs on the your app target.  This is accessed by highlighting your app target and clicking the Info button in Xcode. The screenshots below show where you can find the configuration for the base and deployment SDKs.

We built Gratuitous in order to learn about developing and selling iPhone applications. We’re always looking for ways to improve our visibility in the App Store. Recently, though, we’ve been looking for ways to increase our visibility from outside the App Store into the App Store.

AdWords to the rescue! Right? Maybe not. AdWords didn’t work out for Gratuitous, so we quickly changed course and moved on. But I’d like to share our findings with you

Keyword Pricing

We didn’t know anything about AdWords when we started, so we kicked it off with default settings. We typed up our ad title and body, and hit “go.” The default setting in AdWords is to optimize for impressions (how many times an ad is displayed) by automatically bidding on clicks. For our keywords (iphone tip calculator), the bid went to $2-3 per click. While that may not be bad for a lot of products, it doesn’t make sense for an iPhone app that sells for $1-2. Even if you were able to get the cost per click down to $0.50 – $1, remember that an ad click doesn’t guarantee a purchase – far from it.

So, we switched over to manual pricing. We figured if we could get some clicks for $0.10 – $0.15, then they might be worth it. At that price, we didn’t see enough ad impressions to be worth our time. When bidding high we saw 3 clicks for 10,000 impressions. At 10 cents, the impressions went down to just a few per day. There is no way we’re going to see enough clicks to make that worth our while. If you’re selling a $10 app, then AdWords might be worth looking at.

Copyright and “Limited” Distribution

When we first submitted our ad, it went into review by the AdWords team because it included the word “iPhone.” It’s kind of hard to sell an iPhone app without saying “iPhone,” so we trusted that Google would see that our use of the term “iPhone” was an instance of fair use. After a few days, our ad was approved, but was marked as “Approved (limited).” Limited, to Google, means US-only. That was good enough for us, so we left it as is. If you need ad distribution outside the U.S. you can email Apple and ask them to approve your use in AdWords. Email lwidup@apple.com with your AdWords account number and a nice, friendly note.

Moving on

It’s pretty obvious that AdWords isn’t going to work out for Gratuitous, but apps are only part of our business. “Apps for your life. Consulting for your business.” Instead of advertising Gratuitous, we’re now trying AdWords as a way to generate leads for our consulting service. This is agile business. We tried something, quickly evaluated the results, and adjusted strategy decisively.

I resisted the temptation to spend a bunch of time becoming an expert in AdWords and going in 100%. There may be a way to make AdWords increase Gratuitous sales a bit, but it’s not worth our time. It’s clear that AdWords will not sell thousands of dollars worth of Gratuitous, so the experiment is concluded and we move on and adjust strategy. As a small business owner, I knew I needed to be quick and just test the waters. You’re going to do a lot of new things as a small business owner. Having a good sense for what to spend time on and what to do “just good enough” will be very valuable.

In case you haven’t heard, Gratuitous 1.2 was approved and is now available in the App Store.  Go grab it!

Right now, if you take a look at the Finance category of the App Store, you’ll see Gratuitous front and center.  If all goes well, we should remain on the Finance category home page for the next few days.  Perhaps due to this increased visibility, we had a significant increase in sales during our first day on the home page.  We understand that correlation is not causation, but we’re still hopeful this significant uptick in sales continues.

8/13/2009 update: Uptick continues! Day 2 sales were 18% higher than day 1.

How’d we pull this one off?

It’s a simple trick involving manipulation of your application’s availability date in iTunes Connect.  When set to the current date, your app will appear in your respective category sorted to the front of the list as by default, iTunes displays apps by release date.

The availability date is intended for developers who want a deterministic release date for their application in order to coordinate press and advertising around a known date.  This is common in the video game, music, and film industries where companies coordinate a media blitz around a specific date.  However, with the uncertainty of the App Store review process, developers do not know when their app will be approved.  Thus, companies can use the availability date to set a future date (after their app has been approved) so they can then coordinate press around this known release date.

However, most iPhone developers don’t coordinate media around applications, instead allowing the application to be made available immediately after it is approved by Apple.  Here’s how to set the availability date to maximize the exposure of your app each time you release an update.  These steps must be taken on the day your app is approved by Apple.

1. iTunes Connect > Manage Your Applications
2. Click Edit Information under your respective app
3. Click the Pricing tab
4. Set the Availability Date field to today’s date.  If this is set to a future date, your app will be pulled from the App Store and won’t be made available until this date.
5. Click Save Changes

This change will take a few minutes to propagate throughout the various App Store servers, after which your app will be shown on front page of its respective category.  Depending on the frequency of app releases in your category, your app could be on the front page for anywhere from less than a day to several days.  Being in the relatively quiet Finance category, Gratuitous should remain on the front page for around 5 days.

You might ask yourself why you shouldn’t just constantly adjust the availability date so that your app is permanently displayed on the category home page.  Well, Apple has this scenario covered by using either the lesser of the date your app was approved or the availability date set in iTunes Connect.  For example:

8/10/2009 – App or update approved by Apple
8/11/2009 – Availability date in iTunes Connect

In this case, Apple will use 8/10/2009 (the lesser date) for your application in the App Store.  This is why you should set the availability date to the same date your app was approved.  Additionally, setting the availability date past the approval date will simply cause Apple to withhold your app from the App Store until the availability date, after which your app will be listed with the earlier approval date.

Know of any other tips for fellow iPhone developers?  Leave a comment below!

After submitting the 1.2 enhancement to Gratuitous, we noticed some changes in iTunes Connect around the meta data you specify for your app and thought we’d share for the benefit of other iPhone developers.

Yesterday, TUAW ran a story about how Apple has recently allowed developers to add keywords to their application to help the search algorithm within the App Store.  The keywords, specified in iTunes Connect for each version of your application, are a comma delimited list of keywords in which the total length of this string cannot exceed 100 characters (note: after this article was published Apple reduced the limit from 255 to 100).  We haven’t been too impressed by the search algorithm within the App Store so it is encouraging to know that Apple is trying to improve the relevancy of the search results.

App Store Keywords for Gratuitous

On the left you can see the keywords we used for Gratuitous.  Should the keywords be organized by most relevant/important to least?  Are the relevancy of your keywords diluted with the more keywords you apply?  Unfortunately, we don’t know.  Other than a small blurb in iTunes Connect announcing the change, there is no additional information on this new field.

After finishing the submission for the upcoming Gratuitous 1.2, we noticed something interesting.  The new keywords field above was dithered and couldn’t be edited.  Looking further, the application name was also now dithered and couldn’t be edited.

Previously, you were able to update your application name display within the App Store at any time.  We took advantage of this when Gratuitous was initially released when we realized it wasn’t being returned for the search term tip calculator.  Updating the display name within the App Store to “Tip Calculator – Gratuitous” had an immediate positive effect to our search result ranking.

Last week, we changed our application name within the App Store back to simply “Gratuitous”.  We were curious if this would affect our search result ranking and frankly, it is the name we’d really like use.  Prepending the name “Tip Calculator” just doesn’t look good to us.  However, changing the name back to “Gratuitous” had an immediate negative effect on our search result ranking (so much so that Gratuitous isn’t returned in the first 150 results for the search term tip calculator).  Now that the application name can only be set once per version, we’re forced to wait until the 1.2 update is approved before our name reverts back to “Tip Calculator – Gratuitous”.

Thankfully, we already had 1.2 in the pipeline when these changes occurred.  Some developers have initially set the keywords field wrong (like not comma delimiting the terms) or want to modify it only to realize they will need to release a new version of the application in order to do so.  Releasing a new version of your application just to modify these two fields is a high burden for developers and introduces noise (in the form of a new app version) to your consumers.

In a perfect world, your application name should be set just once and set to your actual application name, not something to improve the search juju.  Additionally, keywords wouldn’t be necessary and the App Store search algorithm would return relevant results regardless of special terms developers set to try and improve their ranking.  Unfortunately, this isn’t the App Store we currently live in so remember to choose your keywords and application name carefully.

Update: 8/1/2009: Apple just updated the developer program portal news with information on keywords and app names that matches what we found and reported earlier in this blog post.

If you haven’t heard already, an update to Gratuitous was approved and made available in the app store.  With each update to an iPhone application, Apple allows the developer to provide information on what’s changed since the last version.  Here are the release notes for the changes to Gratuitous:

The feedback on Gratuitous has been overwhelmingly positive. Usability and design are very important to us at Uproar and judging by our reviews, our customers agree that we’ve hit the mark.

Two things, however, needed improvement. In 1.1 we improved the user experience of the common tips area by allowing you to touch and drag anywhere to make your selection. This is more consistent with other experiences on the iPhone. We also redesigned the icon to be more representative of the app.

We are in the process of developing and launching an improved brand for Uproar as well, so we took this opportunity to include our new logo in Gratuitous. Gratuitous is the only place you can sneak a peek at our new branding until our new website goes live in a few weeks!

This release also brings the code up to spec with iPhone OS 3.0.

However, here is how most apps would phrase this same update:

v1.1 changes:

• Common tips area is easier to use
• New icon
• New Uproar logo
• Updated to work with the new iPhone OS 3.0

Notice the difference?  The latter reads more like an engineer’s changelog rather than something your user would be interested in reading.  As developers, we tend to gravitate towards the terse changelog format as that is what we’re used to.  However, put yourself in the user’s position and frame the update text in something that is relevant to them.  Doing so will help you look at the update from the user’s point of view, something that they will certainly appreciate.

During the beta testing of Gratuitous, nearly every user reported the same problem.  Sometimes, it would take them several touches before the text field would register their touch and bring up the keyboard.  Digging into this more revealed that on the first touch of a text field, there would be a noticeable 1-2 second delay before the keyboard appeared.  All subsequent touches of any text field resulted in the keyboard appearing immediately.

I examined other apps and confirmed this issue was present there too.  Doing some digging online I found others’ apps had the same problem, but no one had a solution.  Some worked around the issue by immediately bringing up the keyboard on app load (a la the mint.com app).  This is acceptable provided it makes sense to immediately show the keyboard when the app starts.  Not so for Gratuitous.

To me, this initial delay during the keyboard load was a completely unacceptable user experience that we had to fix.  Left as-is, Gratuitous appeared very sluggish and initially unresponsive.  Ick.

Not deterred, I decided to try a little slight of hand with a hidden dummy UITextField and hiding the keyboard on initial load.  It turns out this slight of hand works pretty darn good.  So good in fact that when you touch a text field in Gratuitous, the keyboard appears immediately; even the very first touch.

First, add a dummy UITextField to your root view controller.  We need to make it the first responder on load which will invoke the keyboard.  Note that we’re hiding our dummy UITextField and disabling any user interaction with it.

- (void)viewDidLoad {
    [super viewDidLoad];
 
    dummyKeyboardLoading = YES;
    dummyTextField.hidden = YES;
    dummyTextField.userInteractionEnabled = NO;
    [dummyTextField becomeFirstResponder];
}

Now that our dummy UITextField is loading the keyboard, we need to make the keyboard invisible and disable any user interaction with it before it appears so the user isn’t aware of this initial keyboard load.  It is important to note that we maintain a boolean variable, dummyKeyboardLoading, so that we only hide and disable the keyboard on the initial load (and not subsequent loads).

- (void) keyboardWillShow:(NSNotification *) notification {
    UIWindow *window = nil;
    UIView *keyboardView = nil;
 
    NSArray *windows = [[UIApplication sharedApplication] windows];
 
    for (int i = 0; i < [windows count]; ++i) {
        window = [windows objectAtIndex:i];
 
        for (int j = 0; j < [window.subviews count]; ++j) {
            keyboardView = [window.subviews objectAtIndex:j];
 
            if ([[keyboardView description] hasPrefix:@"<UIKeyboard"] == YES) {
                if (dummyKeyboardLoading) {
                    keyboardView.hidden = YES;
                    keyboardView.userInteractionEnabled = NO;
                } else {
                    keyboardView.hidden = NO;
                    keyboardView.userInteractionEnabled = YES;
                }
                return;
            }
        }
    }
}

Finally, once our dummy keyboard has loaded, we need to make it go away by resigning first responder status on the dummy UITextField.

- (void) keyboardDidShow:(NSNotification *) notification {
    if (dummyKeyboardLoading) {
        dummyKeyboardLoading = NO;
        [dummyTextField resignFirstResponder];
    }
}

And that’s it.  In Gratuitous, this hidden preloading of the UIKeyboard is done while the paper is animating up onto the wood grain table when the app starts up.  This animation was the perfect spot to conceal the hidden cost of preloading the keyboard as the user is completely unaware.  The end result is a very responsive app and a very happy developer.

During the beta testing of Gratuitous, nearly all of the testers reported problems with the responsiveness of the app.  This included anything from difficulty registering a touch to sluggish UI elements.  How many apps have you seen that use the stock info (i) button where, try as you might, it takes a miracle just to register a touch on that button?  Or, apps that use the default slider control and its difficult to control blue dot?

If a user feels your app isn’t responsive, they’re not going to use it.  Here are a few lessons we learned during the development of Gratuitous that maximized the responsiveness of the app.

Don’t rely on the iPhone Simulator for usability testing
Within the first minute of testing Gratuitous on an actual iPhone, we quickly realized fields or buttons that we had no problem accessing in the Simulator, were now difficult using our fingers.  The mouse is a far more precise input trigger than your finger and can hide difficult to register hit areas.  This led us to the next lesson…

Don’t make touchable UI elements too small
The smaller the UI element, the smaller the hit area needed to touch the element.  Sorry guys, in this case bigger is definitely better.

Don’t make touchable UI elements too close together
Bunching up touchable UI elements just increases the risk that the user will accidentally touch a different element than they were intending.  When at all possible, give touchable elements their distance.

Provide a visual indication that the touch was registered
When the user touches an object, let them know their action was received via some sort of visual indication.  Take a look at Apple’s Calculator app, the behavior of the keyboard, or when you launch an app from your device.  By following Apple’s lead and providing a visual indication, your app will feel more tactile and responsive.

Beta test your app using someone who has never used a touch screen input device
We had a few people who had never used a touch device take the app for a spin.  Their input was great as it provided us a way to see our user interface through the eyes of someone who didn’t know what they could or couldn’t do (“I can touch that?”).

UX on a touch interface mobile device is different than traditional computer software.  Developers, we’d love to hear what you’ve learned in the course of developing your apps.

The curious case of the missing decimal point button on the Number Pad keyboard type is discussed in quite a few places on the interwebs.  The discussion around Apple’s decision to not include a decimal point button usually goes something like this…

Newbie: “Nice one Apple.  Where’s the decimal point button in the number pad?  The user can’t enter any decimal numbers using the number pad!”

AcidBurnDev: “You have to use the Numbers & Punctuation keyboard type instead.”

1337_Dev: “Or you could be 1337 and add a custom decimal point button to the Number Pad.”

CrashOverrideDev: “Log an enhancement to Apple about this.  I can’t believe they forgot this vital button!”

Newbie: “Great, thanks!”

For Gratuitous, we explicitly choose not to include a decimal point button on the Number Pad.  Didn’t we see all those examples and forum posts telling us how to add that button? (yep)  Are we just lazy? (yep…er, nope)

Let’s take a currency value of $1.23.  Every other tip calculator requires the user to tap the following:

1. User taps 1
2. User taps a custom decimal point button
3. User taps 2
4. User taps 3

Count ‘em.  That’s four taps and it turns out, it is one tap too many because you can simply infer it from the user’s input.  Going back to this example, here’s what Gratuitous does when the user taps those same values:

1. User taps 1, Gratuitous displays $0.01
2. User taps 2, Gratuitous displays $0.12
3. User taps 3, Gratuitous displays $1.23

Count ‘em.  That’s three taps and we’ve just saved the user time.  At this point everyone should be slapping their forehead and saying “of course that’s how currency input should be handled”.  In fact, that’s what we said too when we saw all of the other tip calculators sticking a custom decimal point button on the number pad.  Hopefully, this isn’t new to anyone (used an ATM recently?).

The above example was using USD currency locale.  Now let’s imagine a currency value of ¥123 (that’s Japanese yen).  Did you know that yen is only represented in whole amounts?  Thus, there is no decimal value for yen.  Including one in this situation does not present a very good user experience because a decimal point is unnecessary is some situations.  Aside from currency, number pads can be used for various types of input (credit card numbers, social security numbers, etc) that do not require a decimal point.

At Uproar, this is part of what keeps us up at night in our goal of designing applications with an excellent user experience.  Let us know how we’re doing.

(For those of you that frequent stackoverflow.com, portions of this post came from my answer to a question on this topic.)

With the release of Gratuitous, an obvious question is why another tip calculator?

At the time of this writing, there are around 23,000 applications in the App Store.  With that number, there are very few unique applications.  Indeed, there are several tip calculator apps on the market.  We knew this prior to starting work on Gratuitous yet it did not deter us.  Why didn’t we write an app that’s completely unique and new?

Design

We had been discussing writing software together as Uproar for quite some time.  Regardless of the platform our ideas were intended to live in, there was always a common mantra: design is king.  We both wanted our software, whatever it may be, to be driven by beautiful design.  Of the apps that we use, admire, and strive to be as good as, the common thread is an incredible attention to design.

Gratuitous went through several design iterations (including a complete re-write of the UI) before we both were happy with the final result.  We discussed and debated each and every tap, UI animation, and feature.  Yes, we knew there were several tip calculators already out on the App Store but we wanted ours to stand above the rest in terms of look, feel, and usability.  We wanted the design of Gratuitous to separate us from the pack.

Just What You Need

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. –Antoine de Saint-Exupéry

When we discussed the functionality of Gratuitous, we came up with every scenario we could think of.  Then, we began culling that list down to the scenarios that are used around 95% of the time and focused on doing those really well.  Some examples of features we purposely left out (many of these will get their own blog post later):

• Lots of intricate rounding options
• Complex tip calculation rules (eg, pre-tax, checksum)
• Complex bill splitting (eg, drinks, meal percentages)
• Settings for micro-customizations

For instance, we know some people really insist on tipping based on the pre-tax value of the bill.  To each his own, but Gratuitous is not written for these people.  Such oft-used features tend to complicate the design at the expense of the majority of users.  As programmers, we try and include every option to satisfy all scenarios.  As designers, we only include the options necessary to satisfy the most common scenarios.

Start Small

While both of us are experienced developers, Gratuitous still presented a lot of firsts for us.  Our first time working together on a business venture.  Our first foray into programming in Objective-C and the Mac development environment.  Our first iPhone and iPod Touch application.  As such, we felt it important to start small.

A tip calculator was therefore a great first application.  Its purpose is fairly well defined, calculating a tip is something we’ve all done, and if done well, the application will provide value to those using it.  Rather than try and swing out of the park, we stepped up to make a solid base hit.

How did we do?  We’re pretty proud of our work and we hope others think we did well too.  Let us know what you think of Gratuitous, we’d love to hear from you.