Novice developers: the history of one bug, or for what you can not like the new version of iOS

More recently, Apple introduced a beta of the new version of iOS, which, as usual, contains many "tasty" features. But along with the pleasant question arises: how the already released applications will work on the new version of iOS? In general, the theme of the work of old applications on the new version of the mobile OS is mentioned infrequently. Here, on Habré, I met only one article "Backward compatibility in iOS SDK" . I would like to add her own story.



In the text under the cut - a brief description of the "rake", which I had to step on when preparing a new version of the Parallels Mobile product with support for iOS 5, and how to get around this rake. We will also see an example of Apple’s “special” attitude towards backward compatibility in the iOS SDK, and a couple of tips on how to minimize problems when switching to new versions of the mobile OS.

')





The study of a bug often begins with its localization in time, that is, with an understanding of when (and also by whom and why) it was admitted. For this, a search is made for recent changes related to the problem area. Usually it quickly becomes clear who is to blame, and there it’s not far to an understanding of what to do. But what if the error occurs in the old code that no one has touched since the last released version, in which, of course, everything works?



The situation is not simple, and there is no one solution. Therefore, let us consider an example of a real problem that we encountered when releasing Parallels Mobile update: when the application starts (and when it returns from the background mode), the state of the UISegmentedControl element does not match the page content. The situation is shown in the figure below:







If you switch UISegmentedControl's tabs with your hands, and not programmatically set the right one, everything works correctly.



The study of all the components that can somehow affect the UISegmentedControl and the content of the page ended in nothing: it turned out that no changes to the project are related to the code that allows the content of the page to change depending on the state of UISegmentedControl. Further experiments have shown that the version compiled from the same sources as the app in the App Store also contains the mentioned bug. But how can a program compiled from the same source code work differently on the same version of iOS? (For completeness, the tests of the application: the old version from the App Store and the new reassembled version were conducted on the same iOS device).



We will begin the study of the global problem with a specific task: consider the UISegmentedControl in more detail. To track tab switching, you need to register a handler for the UIControlEventValueChanged event as follows:

[self addTarget:self action:@selector(didValueChanged:) forControlEvents:UIControlEventValueChanged]; 

In the didValueChanged handler function, the page content changes according to the state of UISegmentedControl.



Further study of this UI Control in the Apple documentation showed that, starting with iOS 5.0, a software state change no longer generates a UIControlEventValueChanged event. This means that in new versions of iOS, to change the page content, you must explicitly generate this event, if segment allocation is not made by the user, but in the application code.



An event can be generated immediately after setting the number of the selected segment and it is better to pre-check the iOS version, otherwise, on older versions of the operating system, the UIControlEventValueChanged event will be generated twice:

 [self setSelectedSegmentIndex:ind]; if (SYSTEM_VERSION >= 5.0) [self sendActionsForControlEvents: UIControlEventValueChanged]; 

The presented code solves the problem, but leaves a very important question open: why does the version from the App Store work in the old way on the new iOS 5.1?



Answer from Apple’s documentation : “As a backward-compatibility mechanism, it’s possible to modify the SDK’s rule of thumb. This is where the Apple predicts or discovers compatibility problems. ”



Like this! Attempting to guess whether Apple will make the appropriate changes in the new iOS version like this,

for your applications to work in the same way, it is very similar to Russian roulette. Therefore, to avoid mysterious problems, follow three simple rules:

1. carefully study the changes in the iOS API , especially if there is a major update of the operating system;
2. complete regression testing when upgrading to the new iOS SDK;
3. extend the regression test suite. This will detect the problem when switching to a new version of iOS, which means it will narrow the search for a solution and shorten the time to solve the problem.

Well, in conclusion, I must say that Apple is one of the few vendors who allow themselves to change the behavior of platform elements (UI Controls, functions, etc.) between platform versions. Usually, the functionality of existing components expands: new parameters appear for more flexible control of the element. Either new items appear with different “default” behavior, and old components are deprecated and removed in new versions of the platform. Why Apple sometimes chooses the path of revolution, not evolution, is unclear, but all we have to do is switch to Android to minimize its problems when switching to the new iOS.