Backward compatibility 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 operating system - fix bugs and introduce new ones. And sometimes it is the fix of bugs that everyone is used to living with that adds new difficulties - in iOS 3, you do not hesitate to add 20 pixels where iOS 4 adds them yourself, and as a result, your modal view goes 20 extra pixels up.



But this is not the worst kind of incompatibilities - they can be patched, fixed and released a new build. It is also easily eliminated, for example, the change of the standard control for video playback that has already become traditional - in each new iOS, Apple adds something, modifies it, and completely slaughters the old interface without any deprecated there for 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 debager; 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 “Fixed iOS 5 issues” line - the average user of the iPad finds about 10 application updates every day. Below I will talk about the unobvious backward compatibility problem of iOS 4 and iOS 5, which I had to face the hard way and completely sip grief.



Problem



Somehow at the end of October, my customers began to receive messages from users of the application that one of the minor but rather important views suddenly stopped working. The application did not crash, the navigation remained available, but instead of the data they contemplated the white screen of Malevich.

Neither the customers, nor my team, nor more than two hundred other users had this bug reproduced. Moreover, the application has been in the AppStore for 2 months and no one has complained before. The view was built on exactly the same principle as dozens of neighbors - 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 to do nothing - wait until the bug reproduced at least in one of the vast fleets 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. It must be admitted that it was far from key and, judging by Google Analytics statistics, was used by every tenth user once a week. But let us remember about the psychology of Americans - they themselves, unaware of it, in any way, are trying to knock out a discount on any service - it seems that this is in their blood like the Slavs to ... cheat.

The idea that the paid program does not fulfill 100% of its functions, although it performs 99.9%, excites the brain of the bourgeois, deprives it of sleep and taste for life.

In the letters, he describes the feeling of unimaginable frustrating for a long time when he sees a white screen instead of data for which his company paid $ 0.099, drawing inspiration from Hemingway. Please don’t fix this ASAP !!! - and this is just the beginning of the list of emails courtesy of customers for my email. To top it all, the bug began to be played back on the third (namely, the third, not all!) Devices of my customers. To the angry letters of the final customers, 5-7 letters per day were added from the customers themselves, written by the upper register asking for the help of ASAP.

Needless to say, they began to put the manual in a copy, which in turn also began to require fix.



We did everything we could, even did more. Testing debiles for all builds in recent months, including production and production of Release Candidate. They put 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 reproduce the bug!



Our QA shrugged helplessly, we are in a day (because you still need to sleep and sometimes leave work on time) debugging the TeamViewer customer’s devices — everything worked perfectly under the debager. But as soon as I collected them another Ad-Hoc, everything went on again. My mail has lost order. My skype lost peace and comfort. I lost peace for several weeks, realizing my own powerlessness. 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 go - I tried everything that I could think of and what the guys could think of.



Decision



So, I repeat again - everything worked under the debager. This was the first clue. It should be noted that xCode 3.2.6 with SDK 4.3 was on my poppy, whereas my team’s poppies were 4.2 with SDK 5. I was still too lazy to switch to a new one for me, and so unlike the previous version, xCode 4.

I, as a tmlid, always collected the AppStore and Ad-Hoc builds on my Mac. When it was necessary to upgrade, we debugged iPads from iOS 4.X on my Mac (you can debug on a Mac with iOS SDK 5, but you need to download a large image of iOS 4.3), and iPads from iOS 5 - on their macs (debug such on Poppy with previous iOS SDK 4 is impossible). I must say that Objective-C itself is in some places incompatible in SDK 4 and SDK 5 (the same @autorelease {}), and the guys love newfangled chips, so when transferring versions from the new xCode to the old one had to link some just edit the code. This last circumstance brought me to the final thought.



We checked it quickly - I finally set myself SDK 5 and xCode 4 and sent an ipa file (similar to old Ad-Hoc builds) to customers - as expected, it all worked.

You probably already guessed what the problem is. It does not matter what code was compiled - it is important where it was compiled. The same code, which had been working properly on the AppStore for many months, was compiled for iOS 4 in the iOS 4 SDK even before the release of iOS 5. Then it began to work incorrectly when users updated to iOS 5.



This problem is solved by simply reassembling the same code on the iOS SDK 5. What exactly Apple has changed remains a mystery, since You cannot debug a device with SDK 5 from xCode with SDK 4, and no one will pay us for the time to load the code with assertions. It remains only to release a new build and wait for Apple's apruva. What I advise all habrauser is to update your applications by simply rebuilding the iOS SDK and, following Apple's best practices, add a couple of graphical goodies to let the average user in the vacuumless space understand what he is pumping a new build for.



After written



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



In addition, Apple provides an excellent mechanism for updating operating systems, 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 another improvement in the UI of the mail manager, more ringtones for the alarm clock or other simple and understandable nishtyaki. A farmer from Kansas is unaware that by updating her iPhone with the release of each new OS, she gives hours of restful sleep to programmers on the other side of the ocean :)