Skip to Content

Apple iOS Version 7.0 Backward Compatibility Issue with SUP

Issue

Historically when Apple releases new version of iOS, applications built with existing in-market versions of SUP iOS SDKs will continue to function properly under the iOS backward-compatibility mechanism. However the introduction of the iOS 7 has deviated from that because of the UDID.

Apple has deprecated [[UIDevice currentDevice] uniqueIdentifier] API since iOS5. Even though it has deprecated the API, the call returns the same value, UDID. However, beginning with iOS7*, this API has been removed from the UIDevice header definition. At runtime on iOS7 devices, it returns a completely different value.  Thus a functional SUP based application, which internally uses the UDID call, will fail to make connection to SUP server after the device has been upgraded to iOS7 because the device ID sent by the client no longer matches the value saved on the server obtained during the original registration done before the iOS upgrade.

AFFECTED SUP RELEASES

These SUP versions are affected by this issue: 

SUP SDK VersionsThis build or earlier builds
2.0 ESD# 12.0.1.508
2.12.1.0.503
2.1 ESD# 12.1.1.380


Releases having the API usage, but not affected in re-connection, but affected in application re-submission to App Store

SUP SDK VersionsThis build or earlier builds
2.1 ESD# 22.1.2.310
2.1 ESD# 32.1.3.741
2.2 SP002.2.0.200
2.2 SP012.2.1.336

These builds have the same [[UIDevice currentDevice] uniqueIdentifier] API usage, but it is not affected in reconnecting to the SUP server after iOS 7 upgrade on the device.  That is because the UDID in these releases persist the id in the keychain.  The library in these releases always looks up the keychain first.  Only if the value is not found in the keychain, the library tries to get the value from the API and stores it to the keychain.  For this reason, connection is not an issue after iOS7 upgrade since the library gets the same id from the keychain instead of using the API can return a different value.

Note: Starting May 1, 2013, SAP has released patches against the SDK versions that have removed the UDID dependency. If you have already updated the application with the patched SDKs, you would not encounter this iOS 7 backward compatibility issue and re-submission of the application to App Store is not an issue either

How to check if your application has this issue

You cannot reproduce this problem using a simulator; you must test this on an actual device.

To check to see if your application has this issue, use any of these methods:

·  

  1. Check your SMP/SUP Client version.
  2. Compare your device’s UDID and the registered user’s device ID in SCC.
  3. Search for the word, “uniqueIdentifier” in the Libraries/Debug-iphoneos/libMo.a file, using any text editor.
  4. Print the value of this call [MessagingClientLib getInstance] getDeviceID] in your application.

SOLUTIONS

Solution 1:  Using Subscriptions and Registrations

Requires existing user to unsubscribe and un-register before the iOS upgrade.

After the upgrade, the user will need to re-register and re-subscribe. The existing user registered on the server becomes useless.  For manual registration, the server Administrator must manually register a new user from SAP Control Center (SCC), and not simply reregister the existing user.

For versions of SUP earlier than 2.1 EBF 2, the unregister API is not available on the client, so the following additional steps must be taken:

1)      The app must be removed from the device and reinstalled.

2)      The app needs to run the following code at launch time (in the application:didFinishLaunchingWithOptions: method).  This ensures that old data vault items used by the previous version are correctly removed.

    if(![SUPEngine isMessagingDBExist])

    {

        @try

        { 

            [SUPDataVault deleteVault:kMessagingDataVaultID];

        }

        @catch(NSException *e)

        { 

            // Ignore any exception

        }

    }

Solution 2:  Applying Patches

If re-subscribe is not desirable, apply required patches on both the client and server.  See How to Apply Patches for details.

You must apply patches before upgrading device to iOS7.

Note: * This UDID issue exists in iOS 7 Beta 6 and is not expected to be fixed by their GA version.

                        

These are the latest patches available as of August 23 2013:

SUP Client versions

Patch location

  1. 2.0 ESD# 1

PATCH-10219

  1. 2.1.0

PATCH-10231

  1. 2.1 ESD# 1

PATCH-10247

  1. 2.1 ESD# 2

PATCH-10248

  1. 2.1 ESD# 3

PATCH-10195

  1. 2.2.0

PATCH-10249

  1. 2.2 ESD#1

PATCH-10249

Note:  Also refer to the readme in the patch folder for instructions.

To apply a patch:

1.     Contact SAP Support to obtain the appropriate patch for your version of SUP.

2.     Before upgrading the device to iOS7, run the migration tool on the server.  This sets the UDID to the device connection setting property, which allows the server to push the UDID back to the client.

Use the migration tool in the appropriate .zip file:

· For SUP 2.2.x servers, use the tool in MigrationToolForSUPServer22.zip.

· For SUP 2.1.x and SUP 2.0.x servers, use the tool in MigrationToolForSUPServer20or21.zip.

  · To apply the patch for a single user, run:

  1. MigrationTool.exe SetDeviceID <userName>

Where <userName> is the “User” in SCC -> Application Connection

   ·To apply the patch for all users, run:

  1. MigrationTool.exe SetDeviceID

The tool prints the output that lists all affected users and their device IDs.


           

After the tool completes setting the UDID to the connection property, the UDID is pushed to the client immediately if the client is connected to the server.

If there is no connection between the client and server, the SCC display of the pending items count increments by 1, which refers to the pending push of the UDID to the client.

(Before running the tool, Pending Items is 0.  After running the tool, the count is 1.  You may need to “Refresh” the view to see the change.)

3.     If the server is not connected, connect the client to the server to allow the server to push the pending message to the client.

The client connects until the pending item count in SCC is 0.  This ensures that the UDID is sent to the client.

4.     Verify that the UDID has been pushed to the client.  Open the mocaLog.txt and search for “CMocaSettingsExchange::Run, iPropId = 2000”.  “deviceId=” should contain the UDID value. For example:

      23T120657.626299, T4, CMocaSettingsExchange::Run, iPropId = 2000,       val=deviceId=86a2bbd067ee00ed697f15ad7e7e92eef3af8ba0, folder=

5.     Upgrade the application with the client patch to the device.

After application upgrade, the client should be able to successfully connect to the server.

6.     Upgrade the device(s) to iOS7.0.

Although you can upgrade the application and iOS 7 in any order, if you want to verify the client patch, upgrade the application and test it first, then upgrade to iOS 7.

Note: To determine if the client still sends the UDID when connecting the server, add the [MessagingClientLib getInstance] getDeviceID] API call in the application code.  The API call returns "<Application Connection ID>", which is "<Device ID>" + "__" + "<Application ID>".  Remove "__<Application ID>" at the end of the string value to get the device id.

BACKGROUND

Prior to SUP SDK 2.2 SP02, iOS SUP clients, using the released SDKs from the support packages, depended on the [[UIDevice currentDevice] uniqueIdentifier] API to obtain an ID for registering with and connecting to the server.  This API always returned the device’s UDID until iOS 7.
The following screenshot illustrates how to find your device UDID using iTunes:

        

The above example shows the UDID as 86a2bbd067ee00ed697f15ad7e7e92eef3af8ba0.

After completing registration, the server stores the UDID as the device ID. The following screenshot illustrates how to find the device ID using SCC.

        

The above example shows the server has recorded the same Device ID, “86a2bbd067ee00ed697f15ad7e7e92eef3af8ba0”.

If you shut down and re-launch the application to connect to the server, the same [[UIDevice currentDevice] uniqueIdentifier] API call in the client returns to same UDID until the device is upgraded to iOS 7, at which time this API returns a different id.  In this example, it is no longer “86a2bbd067ee00ed697f15ad7e7e92eef3af8ba0”, instead, it returns
“FFFFFFFF03F4AD01531047C3B99C9C50E33CEE87”.

Starting May 1, 2013, Apple disallowed applications that rely on the [[UIDevice currentDevice] uniqueIdentifier] API to be posted on the AppStore. Existing applications already on the AppStore can remain on the AppStore.

Security Note from Apple:

iOS SDK Release Notes for iOS 7

https://developer.apple.com/library/ios/releasenotes/General/RN-iOSSDK-7.0/index.html

Security

Notes

·         -[UIDevice uniqueIdentifier] is no longer accepted in submissions to the App Store. In iOS 7, apps that are already on the store or on users’ devices that call this removed API will no longer be returned the UDID. Instead, -[UIDevice uniqueIdentifier] will return a 40-character string starting with FFFFFFFF, followed by the hex value of -[UIDevice identifierForVendor]. It is important to consider how this will affect existing apps. Consider submitting updates that no longer access the UDID.

Tags: