A few weeks ago Apple developers had received an email from the Apple Developer Technical Support reminding us that beginning in February 1, 2015 all the new applications uploaded to the App Store must be compatible with 64-bit runtime environments. This restriction will take effect for app updates beginning in June 1, 2015.
- On one hand, in the 64-bit runtime, several data types used by Objective-C have increased its size in memory or its memory alignment has change.
- On the other hand, the 64-bit runtime environment requires using function prototypes when calling functions.
The 32-bit runtime environment uses a convention whose name is ILP32. This name comes from the fact that Integers, Long integers, and Pointers are 32-bit quantities. Now, the 64-bit runtime environment uses the convention called LP64, which means that integers remain being 32-bit quantities while Long integers and Pointers are 64-bit quantities.
This change implies the following:
- Pointers’ size and alignment in memory has increased from 4 bytes to 8 bytes.
- Long integers’ size and alignment in memory has increased from 4 bytes to 8 bytes.
- Types such as size_t, CFIndex, and NSInteger have increased its size and alignment in memory from 4-bytes to 8-bytes.
- Long long integers, fpos_t, and off_t data types have increased its alignment in memory from 4-bytes to 8-bytes.
These changes will impact in some ways to our applications when compiling them for both 32 and 64-bit runtime environments. Depending on the runtime environment, the app could face performance or compatibility issues so you should take into account the below points:
- Memory increasing: Due to the LP64 convention, the apps will take more memory than the 32-bit runtime environment so we will need to dedicate more effort to increase the performance on 64-bit runtime environments.
- Sharing data between 32 and 64-bit runtimes: In case we submit both 32 and 64-bit versions we need to make sure that all the data uses a common memory layout (the sizes and offsets are identical). We need to keep it in mind while consuming information from 32 to 64-bits or viceversa.
- Data calculations: Due to the LP64 convention, data types such as integer supports a bigger range of possible values in 64-bit than 32-bit runtimes. That’s why we need to take care when working with these data types as the result may vary in each version of the app.
- Truncated values. When developing our app we could have assumed that data types such as NSInteger and int are similar, and they are so in 32-bit runtimes. But when developing for 64-bit runtime environments and trying convert values between them can cause data loss.
When we make a function call in our app this is transformed in a set of registers in memory containing the parameters being passed from the caller to the called. In 64-bit runtime we need to take care when calling functions that accept a variable number of input arguments.
- Every function has to count with a prototype.
- When casting a function, we need to be sure that the casted version of the function uses the same signature as the original.
As you can see there are few things to take into account but they are critical. Don’t worry and stay tuned with Chupamobile, as we are going to publish a guide that will help you convert your 32-bit apps into 64-bit soon.
If you are a Chupamobile author, you can update your apps here.
Did you like this post? Like it!
Got something to say? Comment!
Think someone else should see it? Share it!