There are several common types of problems that developers of iOS apps can encounter. These problems range from minor annoyances with plug-ins to major security threats for leaking sensitive personal information stored on a device. Here’s a list of some common problems and solutions to these problems.
One of the most common mistakes application developers make is merging the SWC into the application code while using native extensions. When you’re using Flash Builder for all of the native extension SWCs, make sure that you have selected the “external” link type and not “merged into code” when specifying the SWC linkage.
Using release SWF in Flash Builder
Use the release SWF of the application when you’re creating the IPA to submit to the Apple App store. The release SWF can be found in Flash Builder by selecting “Project>Export Release Build”.
ID Errors and Warnings
The “unable to find named traits” warning likely means that you did not include the extension in your application.xml, which can you fix by adding the extensionID of your application in your application descriptor.
“ID Warning” usually means that a native extension compiled with an iOS SDK is actually greater than the extension compiled in the AIR SDK. When packaging the application, try using “–platformsdk”.
If the ID warnings take up the whole error screen but no actual errors are visible, it probably means that your IPA didn’t get compiled. To see the actual errors, package the IPA with the ADT command line.
An extensionID needs to be unique because extensions are recognized by their extensionIDs—having the same name on multiple extensions can create conflicts or keep the application from working properly. Use the same extensionID in the extension.xml, application.xml, and the “ExtensionContext.createExtensionContext()” function. Use the developer’s name in the prefix of the extensionID, and use the extension ID as a prefix to all of the resources that will be used by the extension.
Sensitive Information Disclosure
iOS apps have the potential to leak all types of sensitive data. The device contains each app’s compiled binary code, which can easily be reverse-engineered by a skilled and determined person. Avoid putting any truly private information on the device and instead store it on the server. If private information must absolutely be stored on the device, keep it in process memory and never leave it unprotected. Strip all binaries before shipping the device. Avoid hard coding or storing trivially passwords, session tokens, and other sensitive data. Remember that all compiled executable files can be reverse-engineered.
Side Channel Data Leakage
Side channels are data used for administrative purposes, such as keystroke logs and web caches. If data leaks from one of the side channels, it is easily available to someone who has found or stolen the device. All app designs should be created with the assumption that the device might be lost or stolen. Identified side channel data on a device, include all third party libraries, avoid including sensitive data in system logs, and disable keystroke logging and the cut-and-paste buffer for sensitive data. Test the app dynamically to ensure that the device is not inappropriately transmitting or storing any sensitive data.