How updating apps could multiply sales

This will be my first #idevblogaday post, so I’ll just briefly introduce myself and then get on with my post. Follow me on Twitter: @runmad, by the way :)

I’m writing this on a flight from Toronto to Copenhagen on an iPad so hopefully it’ll turn out alright. I was afraid my turn for #idevblogaday was going to be exactly when I was going away on vacation, and sure enough @mysterycoconut tweeted @ me the day I was leaving that I’m up, so here we go.

I’ve done development for about 1.5 years now, Objective-C is the only programming language I know. I have a degree in marketing and management communication and years of experience in graphic design. I love experience marketing and sensory branding. I got into iOS development because I loved how (then) iPhone OS brought to life an amazing UX through great hardware, UI and functionality. A great iPhone app is a mix of marketing, design, experiences, sensory triggers and of course, code. So I started learning the coding part and have found that knowing all the rest really does help and benefit you!

I work for online retailer and I have built an iPhone app that allows you to browse our products, purchase them, check orders, etc. You can check it out here.

They’re not “users,” they’re your customers
In developing apps (games included) for iOS devices there’s always a question of doing updates. You’ve released a rock solid 1.0 and then comes the mandatory point update(s) with nasty bug fixes.

Your app sold a few hundred copies (or thousands, congrats) after first releasing it and has since then steadily not sold very well. Should you care to do actively pursue further development and thereby bring more features and goodness to your customers who already paid for your app? Let me try and convince you to do just that.

I’ve read a bunch of posts on IAP and how this has revitalized sales for a game. Noel Llopis’ (@snappytouch) Games From Within blog to read a few posts on his experiences with using IAP to boost sales for his game Flower Garden. IAPs are definitely awesome, and I guess this post will be more of a idea that would compliment IAP in certain instances (depending on what kind of app you have).

I had no Internet connection while writing this, so I have no links for facts and figures but go by general knowledge and my perception of scenarios. Trust me, it’ll be awesome anyway, facts are hugely overrated, right?! You might not agree with me, but feel free to leave a comment and we’ll talk ;)

Joking aside, let’s have a look at why I think you should create and submit meaningful app updates, somewhat regularly.

We all know that App Store customers are greedy. You give them a free app, they want an arm. You sell your game for less than a buck and they complain about there only being 150 levels which meant they finished it in a day because it’s so good (telling you they’ll reward the last, fifth star when you release an update with a billion levels).

Let’s stick with that dollar. How much are you as a developer, as the seller, willing to put into your work after it’s out of the door and the first point updates are released to fix those nasty bugs? I know developers generally hate when customers complain about a one dollar app in a review, but look it this way: They paid you money. They bought something from with their money. They feel entitled as your customers. I bet many indie developers didn’t expect to have to deal with customers when they started iOS development, and are unfortunately surprised by it. It might just be a buck, but this dollar can lead to much more money if you take care of your customers. Give them more than what they came for and they’ll help your sales grow by spreading the love through word of mouth.

The dilemma you have is whether, once a customer has paid for an app, should they receive more? Sure, you can sell level bundles or other objects related to a game with IAP, but perhaps you could also just give this to your customers for free… Or if you have a non-game app, it’s not easy to sell app features as IAP, and I’ve never personally been a fan of apps that have a “Pro” version.

Spreading the love
When was the last time you told your friends not to miss out on a dinner at that restaurant where the waiter treated you like shit? And how many times have you been back to that awesome bar where they tend to free-pour rather generously?

Let’s look at free-pouring. Angry Birds. I would say it’s probably the most popular app ever. It rival sales numbers (not profits mind you) of major console franchises and why wouldn’t it, it’s a buck! Buying this game is a no-brainer for most people, even the greedy ones. You get so many levels it’ll take you days if not weeks to finish. Once you’ve finished they throw more free levels at you in a free update for that one dollar you spent two months ago. They’re clearly insane, right?!

In my opinion (even if this isn’t their intention) it’s a quite clever marketing move. Every single time Rovio releases an update to Angry Birds you’ll tap open that game while riding the subway with hundreds of other people seeing you play this game. You’ll remember how much you love that game and be sure to tell your friends with iPhones (and now other platforms) to download it. You haven’t left a review yet, but feel that now is the time to do so. You’ve had so much fun playing this game – and still do with new levels! – that they deserve that quick 5 star review.

App update sales multiplier
Let’s say Angry Birds has sold 1,000,000 copies (it’s sold a lot more but let’s stick with a nice, huge, round number). Of this 1m downloads, 95% still have it installed and have played it within the last two months. (It’s my belief that a paid app actually stays on a users home screen way more permanently than a free app. It’s like throwing out a dollar and it doesn’t take up any physical space in your life even if you don’t use it. Apps that stay on the device (not just iTunes) are way more likely to receive attention when updated in the App Store.) Angry Birds gets an update with fixes but, more importantly, a new world and 30 new levels or so. Of these 950,000 active customers, let’s say most will update at some point. 10% of these people will tell their friends. On average these 10% tell two friends about the game. Of these 190k people who now know about Angry Birds, just over half will go to the App Store and download Angry Birds for a dollar (it’s a no-brainer price).

So now, from a free update, Angry Birds just made another $100,000 (before a 30% cut) on top of that 1 million copies already sold. Of course I was using the highest grossing game, but I still believe it this ripple effect holds true for your apps. If you reward your customers and exceed their expectations, trust me, they will reward you back by word of mouth, which lead to more sales.

You’ll always have those vocal, annoying customers with horrible reviews and ridiculous expectations, but don’t forget the people who often are the least vocal to you are often really vocal about your app/game to their friends. Who do you trust most for advice on awesome apps, people who are clearly idiots from app reviews or your real life friends or people you follow on Twitter? My guess is the latter two. Just like the restaurant example earlier. You’re probably more likely to visit a restaurant based on a great review from a friend who recently went there compared to a review in a newspaper.

Active development
You may not be selling millions of copies of your app like above, but it doesn’t mean you shouldn’t pursue active development if your app has something going for it. Updates will remind your customers about your app. They’ll revisit the app and it’ll be first in their mind been their friends asks what new stuff they’re using on their iPhone, or which apps they should get within X category.

I know this comparison may sound insane, but it’s rather valid: Coca-Cola technically doesn’t need to advertise. It’s not like we don’t know what it is, where to buy, how it tastes and how it makes you feel, right? True, but when Coca-Cola spends millions and millions of dollars to advertise, they’re reminding you of the brand over and over and over. If you hadn’t just read the first part of this paragraph, I would bet money that you would have said “Coca-Cola” if I asked you to name a soda brand. This is because you have seen so many Coca-Cola advertisements and heard the brand name so many times over the years that it’s imprinted in your brain!

Same goes for your app. Remind customers about your app and be the first thing to come to mind when they think of awesome apps within your apps category/core functionality.

With all this said, don’t just release meaningless “bug fix” updates. People will see straight through this after several of seemingly pointless updates and only get annoyed that your app apparently is full of bugs. As @Jury said in a tweet the other day:

“… Compiled software is not the web. Don’t push every minor issue you fix immediately to your users. Plan discrete releases.”

Obviously, if you have a severe bug in your app, get it fixed asap, so your customers won’t grow resentful of the fact your app doesn’t work as expected.

So in review:
– Free updates help increase awareness about app.
– Awareness leads to re-discovery which helps keep your app “immediate” for users.
– Think of users as customers. You’re not doing them a favour by releasing an app. They’re doing you one by giving you money in return.
– Give your customers more than they expect and they’ll return the favour with a review or other kinds of word of mouth.
– Updates help provide value and helps your app exceed your customers expectations, regardless of the cost of your app.

Note:
– “Bug fixes” are not directly seen as value for your customers. Sure you fixed bugs, but what value does this bring other than just fix something that should have been working in the first place?
– In my opinion, too many “bug fix”-only updates that talk about “improvements,” etc. just become annoying and doesn’t show customers that you (the developer; or seller) is focused on building new features.

I hope you enjoyed my first #idevblogaday post. I hope it was insightful and invoked some thoughts as to what you could do with your app, even if I didn’t provide a single line of code :)

I do hope I surprised some people with how marketing blends in with being an iOS developer and provided some insight into what kind of relationship you have with the users of your apps.

Thanks for reading, sharing and please do leave a comment!

Have a wonderful Monday!

Quick guide to updating your app’s UI for iPhone 4

iPhone 4 will make your UI look stunning. Everything in UIKit has been scaled up already so it will require only a bit of work on your end to make the rest of your app look amazing on iPhone 4. If you only code and don’t touch Photoshop, you’re in luck. However, if you’re a UI designer or have the skills to do your own UI, hopefully you did your original artwork in a nice high resolution – if not, you have a bit of work cut out for you with updating all the UI elements to 2x the resolution.

Updating your app’s UI to be compatible with iPhone 4’s Retina Display is amazingly simple. Since the scale works in points, not pixels, you will have to do very little work on the layout itself. Apple Engineers have made it really simple to use new graphics for all your UI on iPhone 4, at the same time as being compatible (and not using 2x memory) on older, lower resolution, lower memory devices.

All you have to do is add the same image file at 2x the pixels to your app’s resources and name it the same it’s lower resolutions sibling with the following suffix: “@2x”.

For example, in your Resources folder, you will now need to have two image files, one for older devices called myImage.png and one for iPhone 4 called myImage@2x.png, which is twice the resolution.

This way, when you call [UIImage imageNamed:@”myImage.png”]; (or contentsOfFile:) iPhone 4 will automatically grab the filename with a @2x suffix, and lower resolution images will grab the lower resolution copy. You don’t have to check for the device loading the image and write any additional code to grab the correct image. Genius!

If you have seen an iPhone app on the iPad in 2x scale, that’s pretty much how your app is going to look on the iPhone 4. Perhaps not so drastic, but there will be a noticeable difference from app not optimized for iPhone 4 and “Retina Apps” as Apple calls them.

Thoughts on @2x on iPad…
I didn’t hear anything at WWDC regarding this, but my thought is that they’ll integrate this into the iPad for the next major OS release. Basically, it will be able to do the same and grab the higher resolution image appropriately for iPhone apps running at 2x scale.

Happy Photoshopping to UI designers and happy relaxing programmers!

UPDATE JULY 7, 2010:

I have discovered a bug in Apple’s code that deals with grabbing the correct image on iPhone 4. If you are using imageWithContentsOfFile: the code will in fact not automatically grab the @2x if running on iPhone 4. I have submitted a bug report to Apple, and they’ve informed me they are now aware of the issue and the Engineers are currently working to fix the bug. So for now, stick with imageNamed: for all your images.

Debugging Executables for Push Notifications

I am implementing Push Notifications in one of my apps. Doing so may be a bit tricky in terms of debugging since you cannot actually debug incoming Push Notifications appropriately while the app is running, so I wanted to share this tip. Also, I am writing this post on my iPad on an airplane, so pretty excited about that :)

Xcode allows you to debug applications that are running locally on your device. You can even set breakpoints in your code and print out any information you may need from the console in order to debug your app and fix whatever issue you’re experiencing, should you not be able to fix it via “live” debugging.

This feature is especially useful if you’re doing Push Notifications (a great way to easily communicate information to your user with their permission, such as notifications, reminders, marketing (be careful with this one), etc.).

With Push Notifications, your app receives data from Apple Push Notification servers in a dictionary in the UIApplication delegate application:didFinishLaunchingWithOptions: that you’ll need to parse and do in your app whatever is appropriate for the implementation you’ve chosen (launching with specific views in front, etc.). Since your app cannot be running while receiving Push Notifications (it actually does receive notifications while running, but you’re required to deal with that through another delegate method), you’ll need to use the “debug executables” with “Wait for next launch/push notifications” ticked. Once you run the debugger and launch your app (for example directly via a Push Notifications UIAlertView) you can set breakpoints anywhere in your code and use the console to print out (po) any objects you may wish to inspect.

As your app launches immediately when you debug, it’s a problem if you’re debugging Push Notification (which, by the way, does not work in Simulator). So here’s the hidden treasure in Xcode: In the Groups & Folder pane, find Executables, expand and select your app executable. Hit command+option+i to “Get Info” and select the Debugging tab. From here, tick “Wait for next launch/push notification”.

Now, when you Run & Debug your app it will not launch, but instead wait until you tap the app icon to launch it or the app is launched via a Push Notification UIAlertView (this of course requires you have not set the “action-loc-key” to null in your Push Notification JSON dictionary).

Once your app launches via a Push Notification, it will stop at the breakpoint you set and you can now print out any information you need to debug your app, such as the NSDictionary your app receives, whether the appropriate view will be displayed and any other issue you may have.

Some notes on UIView animation

UIView animation is a simple and nice way to add to your user experience. I just wanted to point out a few suggestions when using UIView animations.

Duration (speed):
If you choose to use animation to compliment some of the stuff already happening in UIKit, either at the same time or before/after, it makes a big difference how fast your animations are. Pretty much all the UIKit animations I have come across have a duration of 0.3f and so should yours. Of course, it’s doesn’t always work 100% but for the most part, 0.3f is what you should aim for. It’s quick so your user don’t wait for something to finish animating before continuing with the next input action, and it’s not too fast so that the user doesn’t have a chance to see where the object came from or what happened.

If you have an animation happening while the keyboard animates up or down, use an animationDuration of 0.3f. Same with pushing and popping the navigationController. Annotations in MKMapView also drop at a duration of 0.3f.

0.3f is the way to go.

A simple UIView animation can be added with the following code:

[UIView beginAnimations:nil context:nil];
[UIView setAnimationDuration:0.3f];
self.segmentControl.alpha = 1.0f;
[UIView commitAnimations];

The above example is from an app I’m doing, where the segmentControl is enabled and I increase its visibility in the toolBar at the same rate as a pin drops in the map within the same screen.

When to use animation:
A few objects come with free animation (also at a duration of 0.3f, of course). For example, when adding a UIBarButton to your UINavigationBar, consider setting these with animation. If you replace a UIBarButton with another, they’ll even animate in and out nicely during the change. When adding a pin to a map, why not drop it onto the map with an animation, instead of it suddenly appearing on a map from nowhere?

Another good advice is to do animation (whether your own or with objects that include animations) to bring attention to an object. For example, if you have a pushed view, consider what you can “add” after the view has appeared through animating your objects in viewDidAppear.

Create a better UX with animation
Consider all the ways you can use UIView animation blocks in your app to enhance the user experience. It’s a great way to create a more fluid and pleasant experience for your users. A user’s inputs and actions will feel less rough and more smooth and soft to the touch. Don’t go overboard with animations. Too many will become annoying and it’s important to use animations only where appropriate.

The best advice is probably to have a look at many of the built in apps designed by Apple as well as the many free animations that a part of UIKit objects (how UIBarButtons animate in and out when you push a UIViewController stack, how a modal view appears from the bottom, etc.).

Why the whole world can’t have iPad now

I was chatting with a friend today regarding the possible release of iPhone HD on the day of this year’s WWDC June 7th keynote. This lead us to talk about previous year’s release dates and whether the iPhone HD will be available worldwide on the same day (or at least not a US-only release).

We all know the first iPhone was released a full year before becoming available anywhere else and that recently, the iPad was released in the US prior to becoming available in other countries, including Canada. The iPad’s international premiere was even pushed back another month due to the incredibly high sales in the US.

You may already know the reasoning behind the spread in release dates or perhaps you never thought of it, but just felt annoyed by not being able to buy awesome product at the same time as the Americans. Here are my three thoughts on why iPhone and iPad have been released with spread-out released dates.

1. Test the waters
The first iPhone was a huge step for Apple. Last time they released a similar product it flopped. Diving face first into a packed market place with so much competition and going head-to-head with companies such as RIM, Motorola and Nokia was a huge step. You can argue that Apple was more fit this time around, but it’s still a big step, even for a company like Apple. It’s simply too risky to go ahead and release a new product in an entirely new product category (one can argue that Apple extended the mobile computing category and/or mobile phone category with the iPhone) without knowing how the product will be received in reality (one thing is hype (read: geeks) another thing is public reception).

Obviously the iPhone was a huge success and there was a big demand from international markets as well. Following the first iPhone, new models have generally been released more or less at the same time.

Remember the first PlayStation? Yeah, same thing… It was an entirely (though less saturated) market for Sony, which meant a late ’94 release in Japan and late ’95 release for the rest of the world. With the PlayStation 2 and PlayStation 3, release dates have been considerably less time apart (6 months and 6 days, respectively) from Japan to US/Europe.

iPad is perhaps not an entirely product for Apple (Mac + iPhone = iPad), but the spread out release dates still gives Apple a chance to test the waters and adjust their strategy for the worldwide market as needed.

2. Supply and demand
Why was the iPad delayed internationally? Well, Apple actually said so themselves. The US demand has simply been too high to keep up with production. Nintendo saw the same issue with the Wii being sold out consistently for years (however, it was simply getting ridiculous after two years. That should be enough time to sort out the manufacturing bottleneck).

From previous experiences, Apple was wise enough to contain the release to one market first and once they can keep up with demand in that market, open up for more markets, doubling the possible demand for iPads. Some people would argue that it’s great for buzz and hype if there’s so much demand for your product you can’t keep up with production. This was maybe true for Nintendo (I can’t imagine how stressful some parents must have been, trying to find their kids a Wii for Christmas), but Apple has a pretty clean history of being able to keep up with demand. Both the iPhone and iPad have been easily available since launch. Sure, there have been a few times and a few places where it has been hard to obtain one, but generally, anyone, not only hardcore release-day-campers or those who pre-order a month in advance, have been able to get their hands on an iPhone or iPad. The iPad has already found it’s way into the hands of a diverse group of consumers – not only the early adapters.

3. Manufacturing strength
With any new product comes new manufacturing methods and requirements. This was true for the iPhone and is true for the iPad as well. Over the years, Apple has expanded it’s manufacturing facilities and collection of suppliers to accommodate high sales volumes.

I can’t imagine the cost of setting up a new facility to output an unproven piece of hardware and at the same time making sure enough products are initially manufactured to keep up with an expected high demand. Just the fact that they’ve been able to produce enough iPads to sell 1 million iPads in 28 days is incredible considering they’re also starting production on iPads for other markets.

The next iPad will probably be released in all the markets where the current iPad is already available (at that time), because Apple will simply have been able to ramp up their manufacturing to accommodate the demand.

That’s my take on why the whole world can’t have iPad at the same time as the US. Feel free to add anything in the comments below :)

UITabBarController and UIActionSheet – 65% less hit point!

Ever noticed an app where the UIActionSheet’s bottom button doesn’t want to respond to your taps, unless you hit exactly in the top of the button? If you have a UITabBarController and want to display a UIActionSheet, you have to be careful with what view you show the UIActionSheet in.

If a UIActionSheet is shown in “self” or “self.view” and you got a UITabBarController behind it less than half of the last button will respond to taps:

UIActionSheet *actionSheet = [[UIActionSheet alloc] initWithTitle:@"UIActionSheet Title" delegate:nil cancelButtonTitle:@"Cancel" destructiveButtonTitle:nil otherButtonTitles:@"Option 1", @"Option 2", nil];
actionSheet.actionSheetStyle = UIActionSheetStyleBlackTranslucent;
[actionSheet showInView:self];
[actionSheet release];

Here’s how much of the button will actually respond to taps:

Here’s what you need to do to fix it:

[actionSheet showInView:[[[UIApplication sharedApplication] windows] objectAtIndex:0]];

And what it does:

Linking *directly* into your app’s reviews in the App Store [UPDATED]

UPDATED 10/3:

I have received some feedback regarding this post that I thought I would share:

One developer implemented this feature in a UIAlertView pop-up, asking users nicely if they’re enjoying the app and whether they would like to be taken to the App Store to review the app. This UIAlertView happens after the 10th app launch, so you’re already dealing with people who have used your app enough that they must be liking it. It’s a $0.99 app by the way.

In just two short hours after implementing this, he had received 6 new app store reviews, all with positive feedback along with 4 or 5 stars, nothing less!

What can we learn from this?

1. People are, by nature, lazy. Consider the steps required to actually reviews an app that you like: You have to actively find it again in the App Store, scroll down and go to the review page. Then tap the button to submit your own review, login, etc. Unless someone’s super excited or very pissed off about your app, you will only see a small percentage of people taking their time to go through all those steps to review and rate your app. By asking users, who’ve been using your app more than just a few times nicely for a review, then linking *directly* to the App Store, they’re already skipping many of the above steps and rating and reviewing your app becomes a quick activity related to an app they’re enjoying.

2. Reviews are generally positive. Ratings on the other hand tend to be more black and white. Either people hate your app, delete it and quickly give it 1 star. I doubt a lot of people give apps 4-5 stars when they delete an app. They’re deleting it for a reason; either they didn’t like it, or it just wasn’t what they needed/expected. If they like the app, chances are they’d never delete it, and you wouldn’t be getting those great 4-5 star ratings (refer to #1). I have seen reviews that have pointed out several wrongs about apps, but they’re still adding a 4-5 star rating with the review. It may seem there’s a difference in people’s mind about a review and a rating. I think a lot of users think of reviews as a way of communicating to the developer that there’s an issue with the app, or they want this or that added, but they still use and love the app regardless (giving it a high rating).

3. You’re asking the right users. When deleting an app, Apple has implemented a horrible UIAlertView asking the same people who just got rid of your app to rate it. I think we all agree this is ridiculous (refer to #2). With a UIAlertView inside your app for 10+ launches linking into the reviews of your app in the App Store, you can pretty much assume these people are enjoying the app, especially if they agree to review it. If they’re don’t like it that much or don’t have time, it’s just a simple tap to dismiss the UIAlertView.

ORIGINAL:

Today @coffeeandiphone we briefly discussed ratings/reviews for apps, and one person mentioned he’d like to show some of the users who have used his app more than X amount of times an alert where he’d ask them to review his app in the app store.

So here’s a link that will take people directly to the review section of your app in the App Store. Note, though, they won’t be able to go “Back” to the actual page for your app in the App Store (when on a device), so they can’t really see that they’re on the review page for your app. Therefore, you probably want to make it veryclear where your linking to and before sending them out of your app, into the App Store.

http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewContentsUserReviews?id=341136260&pageNumber=0&sortOrdering=1&type=Purple+Software&mt=8

See where is says “?id=341136260” ? That’s the only thing you need to change. Just insert your own app ID there and you’re good to go. Don’t get confused by “type=Purple+Software&mt=8”, because if you change that, it won’t work for some reason. I am not quite sure why it has to say Purple Software, but I don’t really care as long as it works :)

Combine it with something like this (“Fighting Back Against The App Store’s Negative Rating Bias”) and you’re good to go!

Edit: I can’t remember where I got this info from, but credit goes to whoever/wherever, of course.

Colouring fun with moreNavigationController

When adding more than 5 view controllers to your UITabBarController, a “More” tab is automatically setup for you, which includes a view controller and even a modal view for letting the user edit the app’s tabs in the order they want.

By default, the navigation bars for both the moreNavigationController and the modal view (edit) are the Default blue, but changing these colours isn’t exactly straightforward.

Here’s an example of what we want to achieve:

I use an orange colour in one of my apps for the navigation bars and it just looks wrong when the more tab’s navigation bars are blue.

Changing the colour of the moreNavigationController is quite easy. After you alloc the UITabBarController, set the colour of the moreNavigationController:

tabBarController.moreNavigationController.navigationBar.tintColor = [UIColor orangeColor];

You can also use the barStyle property if you like:

tabBarController.moreNavigationController.navigationBar.barStyle = UIBarStyleBlackOpaque;

That wasn’t so hard. But the navigation bar for the modal view that pops up when the user taps “Edit” is still the default blue. So let’s change that as well:

First, if you haven’t already, make sure your AppDelegate implements the UITabBarControllerDelegate. Then add the optional delegate method willBeginCustomizingViewControllers: in your AppDelegate’s implementation file, and add the following lines of code:

– (void)tabBarController:(UITabBarController *)controller willBeginCustomizingViewControllers:(NSArray *)viewControllers {
    UIView *editView = [controller.view.subviews objectAtIndex:1];
    UINavigationBar *modalNavBar = [editView.subviews objectAtIndex:0];
    modalNavBar.tintColor = [UIColor orangeColor];
}

Again, it’s possible to set the barStyle property instead of the tintColor, but barStyle won’t give you all the colour options, of course.

Now that you have gained control of the modal view, you change more properties. By default, the navigation bar title says “Configure”, but you can change that as well, or how about the background colour? Here’s how:

– (void)tabBarController:(UITabBarController *)controller willBeginCustomizingViewControllers:(NSArray *)viewControllers {
    UIView *editView = [controller.view.subviews objectAtIndex:1];
    editView.backgroundColor = [UIColor grayColor];
    UINavigationBar *modalNavBar = [editView.subviews objectAtIndex:0];
    modalNavBar.tintColor = [UIColor orangeColor];
    modalNavBar.topItem.title = @"Edit Tabs";
}

Regarding the HIG… I am not sure if all this is allowed. I will be submitting an update with an orange coloured navigation bar for both those views, and I believe other apps have it (NY Times) so I don’t think it goes against the HIG.

However, I don’t think it’s a good idea to change the backgroundColor property of the “editView”. I tried with a grey colour and it doesn’t look right. It might also get your app rejected, because it’s such a big change. That your navigation bars are the same colour throughout your app only makes it look better in my opinion, rather than having a blue navigation bar clash with the rest of your beautifully designed app :)

Dedicated Static Analyzer Debug Configuration in Xcode

I went to iPhone Tech Talk in Toronto yesterday, and among the many sessions, I attended Michael Jurewitz’ (@jurewitz) session, “Testing and Debugging Your iPhone Application.” He covered a lot of the basics for using Instruments (very similar to last year’s session on that), how to setup provisioning, etc. for Ad-Hoc Beta testing, etc.

He also covered Xcode’s new built in Static Analyzer (Clang), which is incredibly useful and powerful now that it’s a part of Xcode. However, I haven’t been using it that much (he said to use it at least once a week), but he briefly showed that there’s actually a setting in the project’s build settings called “Run Static Analyzer,” which is a checkbox and checking this will run the Static Analyzer every time you build your project. Jurewitz mentioned you could make a duplicate Debug build configuration that is dedicated to running the Static Analyzer.

He went over this very fast, so I think a lot of people missed the benefit of this great tip!

So here’s how you do it:

Open your project settings and go to the Configurations pane. Pick your Debug configuration (or whichever build configuration you want to dedicate to running the Static Analyzer) and hit Duplicate in the bottom of the window. I called mine “Debug with Clang,” so I know it’s my Debug build configuration.

Next, hop into the Build pane and find “Build Options”. Within those options you’ll find the “Run Static Analyzer” option. Check the checkbox and you’re good to go!

Now, every time you build your project using your new “Debug with Clang” it’ll automatically analyze your project. Personally it’ll probably help me remember to run the Static Analyzer way more often on my project, instead of just once in a while.

Keep in mind that running the Static Analyzer increases the time it takes to build your project, so don’t choose that build setting if you’re just testing new code, etc. Also, I find it’s a good idea to “Clean All Targets” once in while, as it seems to ‘reset’ the Static Analyzer, because otherwise I am finding that it tends to miss certain errors on the second, third, fourth, etc. time you build with the “Run Static Analyzer” option on.

Shadow offset in custom UITableViewCells (for the inner OCD in you)

Apple has a great example code for drawing fast UITableView using custom, complex UITableViewCells called AdvancedTableViewCells. In the example code, you get three versions and I prefer the one named CompositeSubviewBasedApplicationCell, because it draws your cell as one view, just like Loren Brichter’s Fast Scrolling example.

However, Apple’s example code goes a bit further than Loren’s code and adds example for drawing images, different coloured backgrounds and also has better code for handling highlighted cells in my opinion.

As great as the code is, they left out one small detail that really adds a bit extra to the look of your UITableView, plus I find it makes the text less blurry and easier to read. It only requires a few lines of code for each piece of text you’re drawing. The example code provided is actually from the App Store, which, if you look on your device has the nice white shadow y offset.

Here are the before and after pictures:

BEFORE

AFTER

Original code:

_highlighted ? [[UIColor whiteColor] set] : [[UIColor blackColor] set];
[_cell.name drawAtPoint:CGPointMake(81.0, 22.0) withFont:[UIFont boldSystemFontOfSize:17.0]];

Drawing the shadow:

CGPoint point = CGPointMake(81.0, 23.0);
_highlighted ? [[UIColor clearColor] set] : [[UIColor colorWithWhite:1.0 alpha:0.3] set];
[_cell.name drawAtPoint:point withFont:[UIFont boldSystemFontOfSize:17.0]];
point.y -= 1;
_highlighted ? [[UIColor whiteColor] set] : [[UIColor blackColor] set];
[_cell.name drawAtPoint:point withFont:[UIFont boldSystemFontOfSize:17.0]];

There are a couple of things to note in the above code. Firstly, I made a CGPoint from the original code and made the Y location one pixel lower. This is because we’re drawing the shadow first, underneath the original text. After the shadow has been drawn, we just tell the point to move up one pixel and the text will be drawn in the original location from the original code.

Second, you’ll need to set the text colours twice. Note that for the shadow, we need to use [UIColor clearColor] so it doesn’t look weird when highlighted. Also, set the alpha low (you need to check with your cell’s background colour), but make sure it’s not too white. It’ll be really subtle, yet noticeable to anyone who appreciate nice UI design.

Of course it doesn’t work with white cells, but if you’re doing any kind of custom UITableViewCell drawing it’s a nice touch. Here’s how I use it in my app: