Backward compatible in iOS SDK

Apple has never officially declared incompatibilities between different versions of its OS. And yet, every major release they change something in the kernel of the OS - fix bugs and bring in new ones. And sometimes it’s the fix of bugs that everyone is used to living with that adds new difficulties - in iOS 3 you added 20 pixels without hesitation where iOS 4 adds them yourself, and as a result, your modal view leaves 20 extra pixels up.

But this is not the worst kind of incompatibilities - they can be sold, fixed and released a new build. It is also easily eliminated, for example, the change in the standard control for playing video that has already become traditional - in each new iOS, Apple adds, modifies, and completely clogs to the old interface without any deprecated there a couple of versions before sawing - for example, in iOS 3 it was a normal view from UIView, and in iOS 4 it became a sharp view controller, and the old MPMoviePlayerView disappeared.

But this is also subject to the debugger, on the forums in 10 seconds you can find a ready-made hybrid fix code such that the code will work everywhere.

But the relatively new iOS 5 brought even more surprises. This is evidenced by at least the fact that in the latest releases of popular iPhone applications there is always a line “Fixed iOS 5 issues” - the average user of the iPad finds about 10 application updates every day. Below I will talk about the non-obvious issue of backward compatibility between iOS 4 and iOS 5, which I had to face in my own skin and take full pain.

Problem

Somehow, at the end of October, my customers began to receive messages from users of the application that suddenly one of the secondary, but rather important views suddenly stopped working. The application did not crash, navigation remained available, but instead of data, they contemplated Malevich’s white screen.
Neither the customers, nor my team, nor more than two hundred other users reproduced this bug. Moreover, the application has been in the AppStore for 2 months now and no one has complained before. The view was built on exactly the same principle as dozens of neighboring ones - the data was taken from the database, processed in a specific way and put on a rather custom UI.
It was decided for the time being not to do anything - to wait until the bug is reproduced at least on one of the vast park of our devices, and calmly fix it.

Nightmare

However, the problem was not localized - every day more and more users began to complain about the lack of a view. I must admit that it was far from the key and, judging by the statistics of Google Analytics, was used by every tenth user once a week. But let us recall the psychology of Americans - they themselves, without realizing it, by any means, try to get a discount on any service - it seems that they have in their blood like the Slavs to ... deceive.
The idea that a paid program does not perform 100% of its functions, although it performs 99.9%, excites the brain bourgeois, deprives it of sleep and taste for life.
In the letters, he describes for a long time the feeling of the unimaginable frustrating when he sees a white screen instead of the data for which his company paid $ 0.099, drawing inspiration from Hemingway. Please fix this ASAP !!!, we don’t know what we are paying for !!!, I don’t want to pay for something that does not work properly !!! - and this is just the beginning of the list of emails kindly forwarded by customers to my email. To top it all off, the bug began to play on a third (namely a third, not all!) Of my customers' devices. 5-7 letters per day from customers themselves began to be added to the angry letters of end customers, written in upper case and praying for ASAP help.
Needless to say, they began to copy the manual, which in turn also began to require fixation.

We did everything we could, even did more. We tested all builds in recent months under debug, including production and release Candidate production. They set different times and different locales. Everything worked for us, there was not a single configuration (iOS 4.2.1, iOS 4.3, iOS 5.0) on which we could generally reproduce the bug!

Our QA shrugged helplessly, every other day (because you still need to sleep and sometimes leave work on time) we debuted customer devices on TeamViewer - everything worked perfectly under the debugger. But as soon as I collected another Ad-Hoc for them, everything continued in a new way. My mail is out of order. My skype has lost peace and comfort. I lost peace for several weeks, realizing my own impotence. It was the first bug in my career (I have been working in different areas of IT for about 5 years), to which I could not find a way to even approach - I tried everything that I could think of and what the guys could think of.

Decision

So, I repeat again - under the debugger everything worked. This was the first clue. It should be noted that on my poppy there was xCode 3.2.6 with SDK 4.3, while on the poppies of my team - 4.2 with SDK 5. I was just too lazy to switch to a new one for me, and so unlike the previous version, xCode 4.
As a team leader, I always collected AppStore and Ad-Hoc builds on my poppy. When it was necessary to make a deal, we debited iPads with iOS 4.X on my poppy (debiting on a poppy with iOS SDK 5 is possible, but you need to download a large iOS 4.3 image), and iPads with iOS 5 are on their poppies (debiting such on Mac with previous iOS SDK 4 is not possible). I must say that Objective-C itself is incompatible in some places in SDK 4 and SDK 5 (the same @autorelease {}), and the guys like new-fangled chips, so when transferring versions from the new xCode to the old one had to re-link some or edit the code a bit. This last circumstance led me to a final thought.

We checked it quickly - I finally installed SDK 5 and xCode 4 and sent an ipa file (an analogue of the old Ad-Hoc builds) to customers - as expected, it worked.
You have probably guessed what the problem is. It doesn’t matter which code is compiled - it is important where it compiled. The same code, which had been working properly on the AppStore for many months, was compiled for iOS 4 in iOS 4 SDK even before the release of iOS 5. Then it began to work incorrectly when users upgraded to iOS 5.

This problem is solved by simply reassembling the same code on iOS SDK 5. What exactly Apple changed remained a mystery, because It is impossible to debug a device with SDK 5 from xCode with SDK 4, and no one will pay us the time to weight the code with assertions. It remains only to release a new build and wait for Apple to upgrade. Which I advise all habrayuzers - update your applications by simply rebuilding them for iOS SDK and, following Apple’s best practices, add a couple of graphical sweets so that the average user in the airless space understands why he is downloading a new build.

After written

Nevertheless, I believe that Apple is doing the right thing, scoring every new release with all the old versions - this helps the OS always smell good, keeps the kernel from fouling with hard code and hard fixes. After all, it is precisely because of the need to support backward compatibility that Symbian and the Windows mobile branch died. Yes, and large Windows, until recently, was built on an old death-like kernel.

In addition, Apple provides an excellent mechanism for updating OSes, familiar to all users of the company's products. They do not just ask users to upgrade - users themselves want to upgrade to new versions, because for this they are promised yet another improvement in the UI of the mail manager, more ringtones for the alarm clock, or other simple and clear nishtyaki. A farmer from Kansas is not aware that, updating her iPhone with the release of each new OS, she gives hours of restful sleep to programmers across the ocean :)