There are two main components that you need to provide, in order to make an ANE for iOS:
- an AIR library, compiled as a .swf file;
- a native C, C++ or Objective-C library, compiled as an .a file.
A third component that enables the communication between the AIR and the native library is provided for you:
- the AIR C API.
These three, together with a couple of descriptor files that, simplistically put, help the two libraries find one another, are packaged in an .ane file – the actual AIR Native Extension.
The AIR library
The AIR library component of an ANE is like any other AIR library (Flex library project) with one exception: it has to contain an instance of flash.external.ExtensionContext. It’s through this class that the ActionScript side of your ANE will communicate with the AIR C API.
The AIR C API
Think of the AIR C API as the layer that sits between your ActionScript code and the native code you’ll have to write. Being in C, rather than ActionScript, this layer is compiled into your native code and has the task of ‘translating’ ActionScript calls and data structures to C and vice-versa.
The native library
You will typically have to write your native library in C, C++ or Objective-C and compile it into an .a file. Xcode is the tool normally used for that. Your native library will include FlashRuntimeExtensions.h – a header file that comes with the AIR C API and provides the interface to it.
The ANE package
In order to be used as a native extension, your AIR and your native libraries need to be packed in an .ANE file. Adobe’s ADT command line tool does that for you. We will see how in Recipe for packaging an ANE.
- What goes into an ANE for Android?
- What goes into an ANE for Mac OS?
- What goes into an ANE for Windows?
- Prepare your ANE to be used in an app
Over to you
What problems have you run into on iOS that require native extensions? Share in the comments below.