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!

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.

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.

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:

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.).

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

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:

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

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

And what it does:

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.

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.

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:

You can also use the barStyle property if you like:

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:

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:

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

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.

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:

Drawing the shadow:

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:

After trying hard to change my UINavigationBar colour, and mostly giving up, I found out you have to set its tintColor to nil.