One of the main reasons beta versions of an OS are made available is to find bugs in the OS. Apps can crash because the OS isn't doing what it's supposed to. Which is why we're up to iOS Beta 5. [edit: didn't see your FWIW - was that an edit?]

I'm afraid this reads like a hacker rant who is angry that lesser mortals get to write code too. I'm a bit disappointed this comes from someone as influential as yourself.

[edit] It is a great luxury to have a standardised platform to write for and it cuts development costs. Any Android devs want to comment on their experience of writing code for diverse hardware and setups vs iOS? Or indeed Android users wanting to comment on the quality of software being written?

[edit] D) Further, I believe that a response like mine is the only serious response that can be given to someone (kogir) who actually just suggested, "with a straight face", that a full 10% of the people using the App Store should be /banned from leaving reviews/ because he doesn't want to deal with /fonts being changed/. Are you telling me here that you actually agree with him?

Considering that that "full 10%" of the people you speak of have broken their terms of service and are running a non-sanctioned OS, why should Apple be obligated to publish their reviews? I understand the anger at Apple bricking jail-broken phones, but I really don't see how they should be obligated to accommodate them.

While you shouldn't ever make assumptions about CPU or memory specifics (which is why apple doesn't release that information, even to developers) you absolutely can make assumptions about screen size and aspect ratio. Sure, Apple changing the system font shouldn't cripple your app. But having to code for every possible hardware configuration? What is this, Android?

On other platforms different screen sizes aren't a problem since that's been the norm from the very beginning. But why shouldn't we be able to make assumptions on iOS? It's an entirely different environment, one where, among other things, screen size and aspect ratio are fixed.

And yes, I don't think you should hardcode every last pixel in your iOS app either, but it's perfectly acceptable for your graphics to rely on the documented sizes. How should e.g. GarageBand account for a suddenly different aspect ratio?

Also, on other platforms, there was at some point "the one monitor" that came with the system: the fact that so far we've only had two different aspect ratios on iOS devices (3:2 and 4:3) is no reason to believe that the next device won't be something more like 16:9. There is no reason that most applications couldn't be designed to be ready for such a seemingly minor change.

Also, if you are not using standard controls and you have a designer make a couple of images for you, you will now have to split those up into parts to render your UI. It seems that you would argue that this is the only way to go but surely we can agree that it is more expensive for the developer?

In one of our games, certain jailbroken phones broke the shadows under a character. How do we even begin to debug that? Especially when the only bug reports are 1-star reviews with no way to contact the user?

One of the beauties of the iOS platform is that there is very little variation, and any changes are well-documented and you have plenty of time to test for them in advance. It's one reason it's so popular to develop for and the apps are so high-quality.

That said, I am very curious what this bug was that caused "broken shadows". There are an insane number of heavily varied modifications available in Cydia, and I don't even claim to know what even most of them are, but I'm seriously dying to know what kind of change would have caused behavior like that.

In my experience (yes: I sometimes reverse engineer the developer's app, find the bug in their code, and send them a "pseudo-patch" when they get uppity enough ;P), almost every single case of a developer making claims about bugs specific to jailbroken devices actually had a "root cause" of "memory allocation bug in original application triggered by slightly different malloc order".

To further explain what this kind of bug is, this is where the application ends up having a corrupted or obsolete pointer to some other object due to some very serious issue.

A very simple example is just "released an object, but did not clear the pointer to it, and ended up continuing to use the object later". In this situation, the pointer usually ends up not just pointing to garbage: a later object allocation reuses that memory, and due to alignment often ends up at the exact same address.

Of course, the cause can be more indirect: once in this scenario, you might accidentally run the release logic again, only now the release message (or call to free) ends up affecting the /new/ object, causing pointers to /that/ object to become stale, which in turn causes them to point to a further new object. ;P

In this scenario, testing the application may simply "work": the objects may not be used all that often, and the ramifications may be something mostly benign (new also mostly useless objects are always created anew within enough time to make the pointers keep sort of working).

Yet, there is still a bug here, and it may be triggered at any time: if the order of memory allocation and deallocation in other parts of the codebase change slightly, then these stale pointers may end up pointing at something "less benign": maybe you end up freeing the entire shadow of the character, for example, rather than just the word balloons that are constantly being reallocated at different positions anyway.

This kind of thing makes you feel safe if you only test on a single system: you tell yourself that the user's device is going to work the same as yours, and that there is no way you are going to have plenty of time to fix these errors in production if they ever occur.

...of course, unless those bastard jailbreakers do something stupid to your process, breaking your app.

In reality, however, you don't, for a very important reason: deep library code is also using the same memory heap, and you do not get ahead warning of these changes, as Apple (rightfully) does not believe you need to know about them.

When new devices come out, which to date have been heavily correlated with new versions of iOS, they are not running "the gold master" build of the OS: instead they have random changes strewn throughout, and usually have a different build number (despite having the same firmware version).

Sometimes the difference is quite dramatic, though, like with the Verizon iPhone, which came out with a bang: complete access to the App Store with a massively different version of AppSupport (or whatever the moral equivalent is these days), a key library used by UIKit.

You can get really subtle changes like this, however: when 4.3.5 came out, the SSL routines for verifying certificates had to become more complex, and this was released with no notice to developers and only a week of testing even internally at Apple. There is no reason why a change like this couldn't cause changes in dynamic memory ordering.

Now, you might ask "how do we debug stuff like this"? You could wait for your app to crash in the field, but preferably you are debugging this as you write the code. Clang is trying to help, as are specific new features of Xcode 4 built on it, but static analysis can only catch so much.

At the Objective-C level, there is a feature called NSZombie you can use to help debug stale pointer references (no memory is deallocated: it is simply replaced with an NSZombie; a class that is not allowed to receive any messages without terminating the program and logging a stack trace), but at the C level you are on your own.

However, one great way to test stuff like this, is to get a jailbroken device, install a bunch of sketchy hacks on it (preferably the ones that I personally claim are "dangerous and should be used by no one", bonus points if you can find one where "the developer should be ashamed of himself" ;P), and then see if your app keeps working.

If you aren't doing this, you are going to get burned one day by a normal upgrade: you are taking a risk, and to save something that probably will just take an hour of your time, and will improve your codebase because of it.

(Also, I am reasonably certain that the issues you are eluding to with Cydia not working correctly on iOS 4.0b* were, as usual, WebKit issues, which I specifically admitted in my post: and, in fact, during 4.x is when I came up with a much simpler way to handle that specific implementation detail. That said, looking through my git repository, the only changes I seem to have made for 4.0 seem to be to things that fundamentally are not public APIs: restarting SpringBoard being the major one.)

Some assumptions are valid, not lazy or bad. It's simply not possible to account for every possible scenario when all bets are off.

[Edit] Note: In this particular case the label flowed over a button on a non-scrollable pop-over dialog. Not being able to click that button in the registration flow kept people from using the app at all. This was ages ago so I can't point you to the reviews, but there were enough of them that it mattered. It was also in the days before we added in-app reminders to leave good reviews, so basically the only reviews were from font-breakers.