With the introduction of iOS 5 the gods that are the iOS framework engineers have given us the wonderful gift of UIAppearence. The new appearance proxies allow us developers to customise the look and feel of our applications, such as Navigation Bars, Toolbars and Tab Bars without swizzling or naughty categories.

The following is a REALLY brief overview of what @ctp went into in his WWDC’11 talk which you can watch online here (if you’re an apple developer and logged into developer.apple.com)

The new appearance proxies let us call methods such as setBackgroundImage: forBarMetrics: on our bars and bar button items so we can really give our apps a good polishing up. Normally we’d call these methods as follows:

[myToolbar setBackgroundImage:myUIImage forBarMetrics:UIBarMetricsDefault];

So very simple, and all these methods are now fully documented. There are very slight variations in the appearance methods per control so it it worth referring to the documentation to save a headache or two when things don’t go right.

Not only can you set appearance properties for instances of classes, you can set them for a class in general. Think how your categories worked. You can change the appearance of UINavigationBar across you entire app in one swoop:

[[UINavigationBar apperence] setBackgroundImage:… forBarMetrics:…];

Many UIKit classes now have an appearance property. This passes back the appearance proxy for that class, and once you’ve made changes any instance of that class from the point of you modified the appearance will look sexy. If you create an instance of a control before you modify the appearance proxy you must re-initialise/redraw that instance for modifications to take effect.

One more thing. So you know how to modify the appearance of a single instance as well as the appearance for all instances of that class. But you can also define specific appearance properties depending on what the control is contained in. For example, if I wanted to change a navigation bar’s appearance solely when it’s present in MyViewController I would do so like this:

[[UINavigationBar apperenceWhenContainedIn:[MyViewController class], nil] …];

Really simple eh? Instead of calling appearance you simple specify a nil terminated list of containers for which these changes should take effect in.

This new addition to iOS now means you shouldn’t have to write another swizzle or category for simply prettify your bars and buttons.

Recently I’ve been speaking to a handful of developer types who have started to bring their apps to iOS, but when I go all fanboy on them and try to stir up convosation about how amazing Objective-C is as a langauge, and how lucky we are to have well written and documented API’s such as UIKit their eyes glaze over. “Objective what now?”, “UIKit?”.

Turns out many, many developers are using thrid party compilers to create iPhone apps now. Some writing in Java (wasn’t there a JS-Cocoa at one point?), others making games in flash and building them out to iOS using some bastardized Adobe tools. While I’m sure this is enabling them to build games and utilites in a language with which they are familiar, I have a strong suspicion that all it actually does is hurt the end user and the platform.

So you go to make your epic-new-awesome-rpg type game, but you engineer it all in flash and these choose to compile it for iPhone. This may seem very attractive to the developer. Releasing your new game in the popular AppStore. Think of the dollars. The problems come as soon as there is a bug. It was working fine as flash, but when a third party is required to bridge between the APIs you’re sure to encounter a problem at some point, and the people this will affect directly is your customers. Customers love to complain. It’s their right, they paid for your app, yet you can’t fix the issue until Adobe releases the fix in its own tools. The customer has to wait. Now you’re just making the platform look bad.

My advice to anyone who wants to write apps for a specific platform is learn the language. Ofcourse as with everything its going to be tricky at first, but you’ll learn how to do more than your third party crap ever let you do, and you’ll even know how to go about fixing your own bugs.

This isn’t a post about a lack-of-love for cross platform languages. I’m all for using them, but only where the platform directly allows for it. Andriod apps should be written in Java, its the phones first language, Obj-c for iPhone, its what is knows best.

I’m sure you’ve been in a situation speaking to someone in a second langauge, its just not the same is it?

Development on Novus (@getnovus) is coming along nicely. Since we last spoke Google Reader has been fully implemented, however I’m debating wether or not supporting both Google Reader and Standalone functionality is viable at this point as the way Google Reader stores feeds is very different as to how you would in a stand alone application. However I may build Google Account sign up into Novus as its proving great for cloud backup.

I have also implemented a new way in which a user scrolls through an articles content replacing the default iOS scroll bar functionality with a new paradigm I thought up whilst having a bath. This new paradigm focuses on navigating an article you’re reading showing your progress through the article and allowing you to touch a position to start reading from.

The user interface and all other graphic goodness for Novus is being produced by the wonderful Robbie Pearce (@heartofpixels) however the initial beta releases of Novus will be typical iOS UI as I want to nail the functionality before applying the lipstick.

Just before I sign off, we’re still allowing you fine ladies and gentle men to register you interest in helping us test Novus. Please only apply if you’re actually interested in reading articles from feeds. If you’re applying to simply brag about an app only you and 40 others have then you’re doing it wrong. If you want to play with my buggy pre-release software at some point in the near future then apply to be a beta tester.