Ability to Downgrade iPhones
There are many legitimate reasons to downgrade iPhones. As a user, perhaps you just don’t like the new OS.
As a developer, I have a need to test my App on all OS versions my users may reasonably use. I even have a spare iPhone I use just for testing. Alas, Apple only allow the very latest OS to be installed, even if you are a developer.
Apple also don’t ship old OS versions on the iPhone Simulator anymore, so that can’t be used to verify that you’re not calling any new methods either.
For a recent release, this meant I actually could not test it properly. I did the best I could by using the iPad 3.2 * simulator* (a very poor man’s substitute), crossed my fingers, and released. It was a nail-biting day…
Not all users upgrade immediately. Upgrading requires iTunes, yet normal day to day usage of an iPhone does not (you can do everything, buy/upgrade apps, buy music, etc). Actually I believe this is a pretty common use-case, especially for a key audience of mine: travellers. In fact, with my App, at least 10% of my active users (ones using the export server) are not yet on iOS4! That also means 10% of my potential customers. No way am I going to ignore them.
A bug has been reported to Apple on this issue.
To summarise, there are many legitimate reasons why people are on old OS’s, and why (especially developers) have a need to downgrade to old OS’s.
Fortunately there is a solution. And it doesn’t require doing anything illicit to your iPhone either.
Download The Firmware Umbrella. Plug in your iPhone to USB, and press a button.
What the Firmware Umbrella does is cache the iTunes server OK response to your firmware installation request, allowing you to fake this response in the future (to allow the downgrade). Only catch: you can only cache responses for the latest firmware, so do it today!
Important TIP: tick “Advanced Options” and change the “Request From” option to “Apple” (Cydia is for jailbreaking). Optionally, you can do both.
Caching the response is easy. Using it a bit harder – but do yourself a favour, cache the response now, and if you need it in the future, you’ll thank yourself.
Auto resize the Default.png when in a call & tethering
The iPhone can automatically resize the Default.png to take into account the status bar, even when the status bar is double in size.
It even crops out a bit in the middle so your top and bottom toolbars still line up!
To take advantage of this, make your Default.png 320×460, not 320×480. Simple :)
Encode what cannot be NSCoded
Isn’t it annoying that UIImage can’t be serialized (as evident with the error “UIImage unrecognized encodeWithCoder”). Really throws a spanner in the works when trying to serialise your UI (or applying this hack) given that images are everywhere…
Well this can easily be fixed with a monkey-patch, and a pretty safe one at that.
Here it is (just throw this in a “.m” file, and include it in your project):
@implementation UIImage (NSCoder)
- (id) initWithCoder:(NSCoder *)coder {
self = [self initWithData:[coder decodeObjectForKey:@"PNGdata"]];
return self;
}
- (void) encodeWithCoder:(NSCoder *)encoder {
// if space is a concern, replace with UIImageJPEGRepresentation
[encoder encodeObject:UIImagePNGRepresentation(self) forKey:@"PNGdata"];
}
@end
So there you go! This hack was brought to you by the people behind GPS Log for iPhone (please check it out, it’s free to try!).
Why do I claim that this monkey-patch is safe? Well it encodes and decodes your image. The method is doing what it is contracted to do. *If* UIImage were to implement this method, then you would have issues, but *only* if you serialized with one implementation, and deserialized with another (which wouldn’t normally happen, and it’s a pretty big *if* anyway…).
Why is it a “monkey patch”? Well you’re throwing your own code into UIImage implementing standard methods… pretty much the text-book definition.
Be aware… serialising images to PNG format will consume a decent amount of memory and disk space, and can be slow, especially if those images are big. So if you already have these images on disk somewhere else, then you probably should be loading them from disk rather than doing this (I have a feeling this is why Apple did not implement this method, to force people to load from disk).
So why is this method useful? Well for one, you can use it to Copy what cannot be NSCopied :)
Copy what cannot be NSCopied
Sometimes you need to deep-copy an object in Objective-C. Normally you just go newObject = [oldObject copy]. But what if oldObject does not support NSCopying (typified by the error “copyWithZone: unrecognized selector”)?
Well.. if your object supports NSCoding, then you can simply serialize it, and deserialize it! Saves you having to monkey-patch the copyWithZone method (though may be a tiny bit less efficient at runtime).
How can do you perform this voodoo magic? just one line of code…
newObject = [NSKeyedUnarchiver unarchiveObjectWithData:[NSKeyedArchiver archivedDataWithRootObject:oldObject]];
NB. (for iPhone programmers) ‘newObject’ is autoreleased, so make sure you retain it somewhere!
There you go. This hack was brought to you by the people behind GPS Log for iPhone (please check it out, it’s free to try!).
Where do I use this? Well I have some UITableViewCell objects that I defined in an XIB file, but I need lots of copies (this is a pretty common use-case, which the SDK does not handle very well at all). Instead of sticking the object in it’s own XIB file, and loading it from the XIB each time (as is one workaround), I use the trick above :) And it’s more more efficient (object is copied in memory, rather than loaded from flash-storage).
In fact, many UI elements don’t support copying, but they do support serializing, so this can be pretty useful. For UI elements, you may need to add this monkey-patch to get UIImage to play nice.
