According to the Apple guidelines, data that can be downloaded again or regenerated shall be stored in the <APPLICATION_HOME>/Library/Caches directory. So, with AIR 3.6, a new static property, File.cacheDirectory has been introduced, which points to this directory. Files stored in this directory are not backed up on the iCloud. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications. On Mac OSX and Android, File.cacheDirectory points to the Caches directory ( <APPLICATION_HOME>/Library/Caches on Mac and <APPLICATION_HOME>/caches directory on Android). While on Windows, it points to the parent directory being used by File.createTempDirectory.
var myCacheFile: File = File.cacheDirectory.resolvePath("cacheFile.txt");
Up to AIR 3.3, it was not possible to handle exceptions inside the Cocoatouch Static Library in an ANE. AIR 3.4 onwards, it is possible to use the Objective C @try-@catch-@finally syntax inside one’s native library. The native developer can now also use C++ try-catch blocks successfully. The only thing to keep in mind while using exceptions in native code on iOS is that the exceptions should be handled inside the ANE itself. The AIR runtime will not catch the exceptions thrown by extensions.
You can download the latest AIR SDK with support for handling exceptions in a Native Extension from http://labs.adobe.com/technologies/flashplatformruntimes/
If you are using iOS Native Extensions with AIR 3.3, you may find that your application does not get packaged when using Flash Builder/Flash Pro. This is because, when using native extensions, linker warnings are not suppressed, and Flash Builder/Flash Pro are not able to handle such large number of warnings, specifically on Windows. This issue will be fixed in the upcoming release of Flash Builder and Flash Pro.
In order to overcome this issue, you can include the platform descriptor file (platform.xml) in your ANE, which contains the following linker option:
A sample platform descriptor file will look like this:
Then, at the time of packaging the ANE, include the ADT switch –platformoptions, providing the path to the platform descriptor file. For example,
Developing ‘Native Extensions for iOS’ requires knowledge of both native iOS code (C/C++/Objective C, XCode, static libraries etc) and AS3 code. So, it’s not unusual for developers to face issues. I have tried to list some of the most common roadblocks for native extension developers on this page.
An extension is recognized by its extensionID. Thus, one should try to keep it as unique as possible, as an application developer might want to use more than 1 native extension in his application. Having the same name will create conflicts and the application won’t get packaged or work as expected.
a. Same extensionID should be used in the extension.xml, application.xml and the AS3 Class where ExtensionContext.createExtensionContext() function is called.
b. Using “nativeExtension” as the extensionID isn’t really a good idea. Prefixing the extensionID with com.developerName is probably the way to go.
With AIR 3.3, it is possible to use platformsdk switch for iOS on a Windows machine too. For using this feature, one needs to copy the desired iOS SDK (iPhoneOS.x.y.sdk) on their Windows machine and use the platformsdk switch of the ADT:
-provisioning-profile <path to .mobileprovision>
<output IPA file>
<application.xml> <SWF> <assets> -extdir <path to extensions folder>
-platformsdk <path to the iOS SDK folder>
Now, this seems fairly simple, the only difficulty which may arise is while copying the SDK from Mac to Windows machine(as symbolic links are present on Mac, which need to be copied as actual files on Windows, else packaging would fail).