Applications may register custom URL schemes for third party applications to communicate with them. Although this is a simple IPC channel, it may expose your application to "URL Scheme Hijacking". Since any application can register a URL scheme as long as it is not reserved by Apple, a malicious application may register the same scheme used by your application which results in an undefined behavior. According to Apple's documentation: "If more than one third party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme". If the malicious application is installed before your application, it may register the scheme and prevent your application from installing successfully. Alternatively, if the malicious application is installed after your application and it succeeds in the scheme registration, it may hijack it from your application.

Android's backup service allows the application to save persistent data to a remote cloud storage in order to provide a restore point for the application data in the future.

Android applications can be configured with this backup service by setting the allowBackup attribute to true (the default value) and defining the backupAgent attribute on the <application> tag.

Android however, does not guarantee the security of your data while using backup, as the cloud storage and transport vary from device to device.

Files saved to the external storage are world-readable and can be modified by the user when they enable USB mass storage to transfer files on a computer. Also, files on the external storage card will remain there even after the application that wrote the files is uninstalled. These limitations can compromise sensitive information written out to storage or allow attackers to inject malicious data into the program by modifying an external file it relies on.

Example 1: In the following code, Environment.getExternalStorageDirectory() returns a reference to the Android device's external storage.

 private void WriteToFile(String what_to_write) {
        try{
            File root = Environment.getExternalStorageDirectory();
            if(root.canWrite()) {
                File dir = new File(root + "write_to_the_SDcard");
                File datafile = new File(dir, number + ".extension");
                FileWriter datawriter = new FileWriter(datafile);
                BufferedWriter out = new BufferedWriter(datawriter);
                out.write(what_to_write);
                out.close();
             }
        }
   }

Data stored on the Android internal storage using the MODE_WORLD_READBLE or MODE_WORLD_WRITEABLE is accessible to all applications on the device. This not only denies protection against data corruption but in case of sensitive information violates user privacy and security concerns.

When storing data into the Keychain, an accessibility level needs to be set up which defines when it will be possible to access the item. The possible accessibility levels include:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
The data in the Keychain item cannot be accessed after a restart until the device has been unlocked once by the user.
After the first unlock, the data remains accessible until the next restart. This is recommended for items that need to be accessed by background applications. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleAlways:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute migrate to a new device when using encrypted backups.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
The data in the Keychain can only be accessed when the device is unlocked. Only available if a passcode is set on the device.
This is recommended for items that only need to be accessible while the application is in the foreground. Items with this attribute never migrate to a new device. After a backup is restored to a new device, these items are missing. No items can be stored in this class on devices without a passcode. Disabling the device passcode causes all items in this class to be deleted.
Available in iOS 8.0 and later.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlocked:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute migrate to a new device when using encrypted backups.
This is the default value for Keychain items added without explicitly setting an accessibility constant.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

The accessibility levels which do not contain the ThisDeviceOnly will be backed up to iCloud and backed up to iTunes even if using unencrypted backups which can be restored to any device. Depending on how sensitive and private the stored data is, this may raise a privacy concern.

Example 1: In the following example the Keychain item is protected at all times, except when the device is powered on and unlocked but the Keychain item will be backed up to iCloud and to unencrypted iTunes backups:

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlocked forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

The HTTP(S) responses may contain sensitive data such as session cookies and API tokens. The URL loading system will cache all the HTTP(S) responses for performance reasons, storing them unencrypted in an insecure shared storage.

Example 1: The following code installs the HTTP(S) response cache in shared storage space:

    protected void onCreate(Bundle savedInstanceState) {
       ...

       try {
           File httpCacheDir = new File(context.getExternalCacheDir(), "http");
           long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
           HttpResponseCache.install(httpCacheDir, httpCacheSize);
       } catch (IOException e) {
           Log.i(TAG, "HTTP response cache installation failed:" + e);
       }
    }

    protected void onStop() {
       ...

       HttpResponseCache cache = HttpResponseCache.getInstalled();
       if (cache != null) {
           cache.flush();
       }
   }

The HTTP(S) responses may contain sensitive data such as session cookies and API tokens. The URL loading system will cache all the HTTP(S) responses for performance reasons, storing them unencrypted in the {app ID}/Library/Caches/com.mycompany.myapp/Cache.db* files.
Developers may think that by setting the diskCapacity or memoryCapacity properties of the URLCache class to 0, they may be effectively disabling the HTTP(S) response cache system. However, the NSURLCache documentation states that both the on-disk and in-memory caches will be truncated to the configured sizes only if the device runs low on memory or disk space. Both settings are meant to be used by the system to free system resources and improve performance, not as a security control.