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).
With Adobe AIR 3.3, support for native iOS simulator would be available for application development.
Prior to this feature, the only way to test AIR applications on iOS was to have an actual device along with a developer certificate from Apple. With simulator support now available however, there is no need to obtain a developer certificate (which is a time consuming process) or to create a provisioning profile before starting to develop an AIR application. A p12 certificate, which can be created by the developer himself would be sufficient.
Native simulator for iOS is very helpful in testing and debugging AIR applications. Because support for this enhancement is currently not available in Flash tooling, one could use the following adt commands below to use this feature .
Simulator for iOS is based on x86 architecture and therefore two new targets have been added in ADT to support the same. Continue reading…
On iOS, an application in the foreground moves to background when user presses the home button, or presses sleep/wake button, or the system launches another application. Most applications get suspended on transition to background. Applications that have requested for background execution (such as playing music, location updates, file upload/download) may continue to run for a while longer. In order to improve the device battery life and user’s experience with the foreground application, iOS limits what an application can do in the background.
Default Behavior of AIR application on iOS
By default, an AIR application on iOS gets suspended on entering background, primarily to preserve application’s in-memory state. Thus allowing the application to be quickly re-activated when it is brought to the foreground. When a low-memory condition occurs, the system may purge suspended applications without notice to make more space for the foreground application. Continue reading…
Update in AIR 3.6: PreventBackup Property introduced for File Objects. More Details here.
AIR applications targeted for iOS may get rejected in the application review process with the reason “Rejection: 2.23 Apps must follow the iOS Data Storage Guidelines or they will be rejected“. Usage of File.applicationStorageDirectory or Local Shared Objects (LSOs) in the application might be the reason. Recently, Apple has updated the Data Storage Guidelines with the release of iOS 5. Since the guidelines are accessible only to registered iOS developers, let me summarize the key points below:-
- The entire home directory is backed up to iCloud by default, except the Application bundle itself, Caches directory and the tmp directory.
- In order to minimize the data that needs to be backed up, Apple expects the developer to adhere to the following guidelines:
- Only user generated data, which other wise cannot be recreated like an image capture or voice recording should be stored in Documents directory.
- Application Support Directory must be used to store only application specific data files. For example:- application configuration files or game levels. Data stored here is not vulnerable to be purged under low memory conditions. Continue reading…