Live iOS app upgrades from 32-bit to 64-bit

Apple officially will not allow the submission of arm64 applications on February 1, 2015, which is a Damocles sword for those of us who develop mobile applications. I wrote an article in front of how apps on iOS are compatible with 32-bit systems and 64-bit systems, but that's still an armchair stage, not in combat. By January 2015, I finally started the arm64 upgrade of the app after the app submitted a new stable version.

1. Preparation

Our application is multimedia player, involving the famous open source third party such as FFMPEG/SDL. Because the project does not directly introduce the source code of these projects, but is used by the way the library links to the project, all third-party libraries need to use libraries that support arm64.

If you are not sure if the library supports ARM64, you can use the file command in CMD mode to check the library file.

Test the real machine, including 32-bit devices and 64-bit devices.

2. Increase the architecture of arm64

This is nothing to say, under the Project Build Settings page architectures and valid architectures two settings are set to ${archs_standard}.

Here is a detail to mention, in Xcode5,${archs_standard} refers to armv7,armv7s and arm64, while in Xcode6, ${archs_standard} refers to Armv7,arm64, One of the armv7s was abandoned by Apple.

This is detailed in the article "Xcode 6 drops armv7s".

3. Several areas to be aware of in practice

I) Assembly code

If you have the assembly language of the source code, then it is a more annoying thing. Because 32-bit architectures and 64-bit architectures have huge differences, there is no way to mix code. And the general use of assembly language is a very important part of the core, this situation can only be specific analysis of the problem.

II) sizeof

I prefer the use of sizeof in the code, because the feeling will be relatively easy to transplant, the system will automatically help us calculate the size of the specific, instead of manually one by one calculation. But this time the sizeof has brought a certain problem.

The scenario I met is that my application needs to have some data interaction with a hardware device and send commands to each other. This hardware device is independent of the application, obviously, I need to ensure that the command content of the hardware and the receiving, sending and processing are strictly in accordance with the previous agreement to work. However, 32-bit and 64-bit are different for some types of interpretation lengths, which can lead to problems. The most typical type is long,size_t and pointers, and finally the compatibility really took some effort.

In fact, there is also a scenario where the problem is obvious-the content on the cloud, because the content on the cloud cannot determine whether the next access is 32-bit or 64-bit, so it is also difficult to meet.

To summarize, it is necessary to be careful about the scenarios where data structures are required to be interpreted in 32-bit and 64-bit situations, especially the use of malloc (sizeof (x)).

III) exchange of pointers and integers

This bad precedent was first opened by Microsoft, the official code under the Win32 is full of such pointers and int transformation, then the logic is because all are 4 bytes, so content without any loss, this practice is safe.

The time has come, such code will now bear the consequences, if you have the code in the writing of this technique, then you curse the Microsoft side to modify it yourself, ^_^

IV) harsh and random code

For example: int and nsinteger do not distinguish, unsigned int and nsuinteger do not distinguish, and so on, some write code less rigorous programmer, really is flooded with such code, these two examples run in 32 bit is no problem, so really is not difficult to see, but, The 64-bit is not the case, the previously very random code, now have to pay the price.

There are still some issues, such as format, where functions have to be declared and so on, which does not cause much trouble in the actual upgrade process (which is, of course, related to the type of my application). The biggest trouble I've encountered is the 4 points listed above.

Finally, this upgrade will require sufficient testing, including 32-bit real and 64-bit real machines, which must be tested for stress.

Live iOS app upgrades from 32-bit to 64-bit