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.

When you port your App to the iPad, one of the first choices you get is whether to create a separate product, or a fat (i.e. “universal”) binary.

It seems that many folks on the App store, including several apps in the GPS/travel space have gone done the separate-product route.

Perhaps I understand why they did this. After all, it is not trivial to port an App to the iPad (basically your UI needs a complete re-think). For some apps, they have gone so far as to offer a totally new UI, using real life metaphors like “pages” and “books”.

I still think it’s a bad idea. Why? For two main reasons:
1) customers don’t like paying for the same product twice
2) how many people will actually buy both versions anyway?

Yes the iPad version costs you money to make. BUT, it will hopefully get you more customers. New customers who buy it for their iPad.

Historically I know of several products that used to ship with multiple targets. Warcraft 3 is one, and Adobe’s suite is another, both supported both Mac and Windows. Many steam games now support Mac as well (and don’t require re-purchasing).

So my theory is most users won’t buy the App twice. Some will buy it for the iPhone, some will buy it for the iPad. If you have the one binary to support both, a few will run it on both, and find that useful. If you sell it separately, I doubt most people would buy the counterpart, simply because they would use one device more than the other. Furthermore, users that have already bought the iPhone version get that installed to their iPad anyway, which may be enough.

So rather than trying to milk your existing customers to pay for the port, think of it this way: You get new customers (those who have never used your app, and want to use your App on the iPad), you add value to your product (by allowing use of both devices) which may give you an edge. And you’re doing the right thing (ask yourself, do you like paying for the same thing twice?).

I think so few customers will buy the app TWICE, that you actually de-value your product. I suspect that the number of additional people who buy your App because it supports both, will outweigh the number of people who would have bought a second copy, and that both categories of users represent only a small percentage anyway.

And please, don’t try to claim “but the iPad version is different”. I don’t care if it has a fancy book UI, a re-arranged layout, or up-res’d textures. If it performs the same function, it’s the same App.

GPS Log for iPad. Coming soon. Free for existing users.

Will

NSZombies is great for finding references to deallocated objects (a common crash issue). But it is less useful when trying to debug a crash in autorelease, especially if the object in question is very common.

For that, you can enable malloc logging (in the simulator) and really trace where the object in question was allocated.

As stated in this excellent post, with NSZombieEnabled, MallocStackLogging and MallocStackLoggingNoCompact enabled, you can get the PID of the simulator from your debug console, and then run shell malloc_history from the debugger to get the stack trace.

More great articles:
iPhone Memory Management & Debugging
Debugging Autorelease (not iPhone specific)
More on this topic
not directly related, but a favourite on the topic of objc_msgSend bugs

I’ve been learning more about Android recently. I like what I see. Seems like cool hardware, some cool Apps, and a good philosophy behind the whole thing (open source OS, “democratic” app approval process).

However as far as making money is concerned, I’m really not convinced this is the place to do it.

I’m not sure just how much is being bought and sold on the App store, but there appears to be a really big deficiency. And that is you can only sell your apps to 13 countries. Not only that, but the rate at which countries are added seems very slow (no additional ones in over a year).

Here is a bit of a deal breaker for Australian developers, they cannot legally sell Android Apps.

Compared to Apple, which can sell to many countries. As one person puts it “Apple is running out of map” when trying to find new countries to sell in. They recently launched support for Botswana, amongst others.

There is a big discussion here

Interestingly anyway can view how much money an App has made (as a range). This is public information! And is used as a shit-filter (like Apple failed to do with star-ratings). As a user, that is cool, I’m interested to see what Apps have done well. As a developer this is terrible! It means a rival developer is able to make a very accurate cost-benefit analysis of whether copying my App would be profitable!! Not so good…

My thoughts for now are: Android is a fine place to create a freely distributed app (which you possibly make money off another way, a.l.a drop-box, or via ads), but as for paid-Apps, it seems that Apple is not only king, but it is a much bigger king with heaps more moolah.

On the iPad you must support all device orientations as the device has no “natural” orientation.

Be ware that UIViewController by default only returns “Portrait” when asked. You should change it to:
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
return YES;
}

This is obvious stuff… but what threw me is that in 1 place in my code I use UIViewController *without* subcalssing it. So it wasn’t caught with my find/replace for that method. Anyway… lesson to be learnt, search for any UIViewController alloc’s. Easier approach just subclass UIViewController once, add that method and use it in any such cases.

Without doing this your iPad will refuse to rotate for the views in question resulting in several visual glitches. Even if you just flash it for a second, it will go haywire.

Just had one of those afternoons, where you waste 2 hours trying to debug some really strange crash in fairly simple code only to find that the API is at fault.

I have a UIDatePicker which I present in a (custom) UIAlertView used on the iPhone.   On the iPad it makes sense to use a UIPopoverController.

However on use, it would crash about 20% of the time on the first showing, and 100% of the time on the second with various errors like:

*** -[_UIPickerViewSelectionBar lastClickRow]: unrecognized selector sent to instance 0x5570c80

and

*** -[_UIOnePartImageView lastClickRow]: unrecognized selector sent to instance 0x5576b70

and

*** -[NSCFString lastClickRow]: unrecognized selector sent to instance 0×6081770
Basically it’s just sending “lastClickRow” to junk…
And now… what cost me 2 hours but you get for free (hey why not check out GPS Log ;)

The workaround:  Set the UIViewController’s .view (to the view containing the UIDatePicker) AFTER you call presentPopoverFromRect on the UIPopoverController.

No visual glitches with the workaround.

Thanks A  ._.

I could file a bug report… but I can’t stand that the iPhone bug reports are hidden, i.e. I have no idea if 100s of others haven’t already filed the same one and I may just waste my time.  Already kinda regretting the waste of time on this issue.

Some useful resources for the task:

• iPad Programming Guide
• Thanks to Ray Wenderlitch for his excellent iPad porting tutorial
• Info from Apple on how to configure the universal binary:

Follow these steps to build a universal application that will run on both iPad and iPhone:

• Set the Base SDK build setting (in the Architectures section) to iPhone SDK 3.2.
• Set the iPhone OS Deployment Target build setting to iPhone OS 3.1.3 or earlier.
• Set the Targeted Device Family build option to iPhone/iPad.
• Make sure that your Architectures build setting uses both armv6 and armv7
• Set the Active SDK to iPhone Device 3.2, select your Distribution configuration, build (select the Build button) your application, and submit it for App review.

• Weak-linking the UIKit Framework
• setting the frame of a UIPopoverView

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

Thanks to samwize for the tip.

FBConnect for iPhone is a cool way to interact your App with Facebook. The FBDialog.h class is also a pretty cool way to display a HTML page to the user in a modal way.

Yeah it’s open source too (Apache 2.0) so no problem with appropriating it for other uses :D

However it’s not totally modal. You can still interact with the underlying view on the edges.

Fixing this fortunately is easy:

Under – (void)show, replace:

[window addSubview:self];

with:

_modalView.frame = window.frame;
[_modalView addSubview:self];
[window addSubview:_modalView];

And in – (void)postDismissCleanup, replace

[self removeFromSuperview];

with

[_modalView removeFromSuperview];

Just add a member UIView* _modalView, init and release in the classes init and dealloc respectively :)

Easy.

Thanks @facebook for the useful code!

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