IntelliJ, Flex/AIR, and iOS packaging: two improvements

IntelliJ 11 has a much better GUI for Flex (Mobile) build settings than previous versions, but there is one issue and one opportunity for improvement.

1. Defaults to insufficiently editable auto-generated application descriptor (Project Structure > Modules > [Your Flex Module] > iOS).

Problem
Building, debugging and submitting iOS apps using IntelliJ is now confirmed to work fine. Literally follow the codesigning explanation from [http://www.adobe.com/devnet/air/articles/packaging-air-apps-ios.html]. One difference with Flash Builder though is where the explanation talks about changing the app descriptor XML file, in which you have to put a few things that ensure debugging or submitting the app will work. IntelliJ defaults to a generated app descriptor, which is placed in the output path (i.e. not editable). There is no GUI, unlike in Flash Builder, to edit elements of this generated app descriptor. As a result, stuff like the Bundle ID and app icons may be (in fact, usually are) not correctly set in the app descriptor. You may then have surprise failures to debug on an iOS device or upload to the App Store. The only solution is to make a custom descriptor and edit it manually. In other words, a very incomplete and confusing implementation.

Solution
Either change 'Generated' to an option that generates an application descriptor ONCE and places it with the sources, so it can be edited, or provide a GUI to specify the elements of the generated descriptor.

2. A typical app requires multiple signing options.

Problem
For iOS, developers can have up to three different profiles (signing options) per app, for (1) development and debugging on a device, (2) ad-hoc distribution, and (3) App Store submission. A profile (signing option) is a combination of a key file and a provisioning file, for instance steven_developer_id.p12 and app_on_ipad_steven.mobileprovision. Whenever a developer switches build targets (i.e. going from debugging on iPad to debugging on iPhone or uploading to App Store), s/he has to browse for the two corresponding profile files in the iOS tab and then build the appilcation. This is cumbersome. Moreover, previously, profile information was provided in the Package AIR Application dialog. Now it is located under Project Structure (same window as under 1.). This makes the process even more cumbersome; making a mistake means lots of navigation in IntelliJ. Probably the same goes for Android, but I have no experience with it.

Solution
My improvement is as follows. First, in the iOS tab, allow me to specify multiple profiles (p12 and mobileprovision file for iOS). By the way, why provide options as to which keystore format to use if AIR on iOS uses p12? Second, in the Package... dialog, provide a combo box allowing me to choose the profile I want, as well as a button that brings me to the iOS tab where I can edit them. Alternatively, and I may be in favor of this, move the whole profile and bundled files stuff back to the Package... dialog, and include the idea of a combo box there.

2 comments
Comment actions Permalink

Small addition.
"There is no GUI, unlike in Flash Builder, to edit elements of this generated app descriptor."

I made a test project today for more precision. Some findings.

1. Indeed, the auto-generated app descriptor is not useful except for the simulator. Debugging on devices or App Store submission requires a custom app descriptor. This raises the question why not to do it right immediately. A very user-friendly option would be to have a GUI to edit the settings of the auto-generated descriptor. This can also check for validity (e.g. are icons correctly defined, et cetera), and for instance, if the user specifies a target of iPad, warn in the simulator for running on anything but iPad.

2. There is a GUI allowing you to generate a custom app descriptor and then edit some elements of the enerated app descriptor once (not the icons though, and they are necessary for successful app submission). However, if you click Generate, you have to save the file in the proposed path, i.e., the output path. Trying to save it anywhere by browsing else disables the [OK] button in the browse window because that window is meant to look for an existing file, and the file does not exist yet because we're generating it. Also, the GUI to generate it is meant for single use, I think.

Personally, I don't want my custom app descriptor to appear in the output path. In general, I have my sources somewhere completely different (i.e. on Dropbox) than my output path (i.e. somewhere local). I don't include the build path in my project structure. Maybe this is a rather idiosyncratic way of working with IntelliJ, but to me it makes perfect sense to split sources and build output, and not to include the output path in my module. An example is attached. I add the build output content and the Dropbox content.



Attachment(s):
IdeaProjectsContent.zip
DropboxContent.zip
0
Comment actions Permalink
There is no GUI, unlike in Flash Builder, to edit elements of this generated app descriptor

What GUI in FB do you mean?

Either change 'Generated' to an option that generates an application descriptor ONCE and places it with the sources, so it can be edited, or provide a GUI to specify the elements of the generated descriptor.

Yes, generated app descriptor can't guess desired app ID, icons and all other stuff. It is convenient only for quick start, and afterwards all need to switch to the custorm descriptor template.
There is 'Create...' button to create custom descriptor template with some basic options. Others can be edited manually in the xml file. I can't imagine convenient GUI giving full control on all the options of the descriptor file.

2. A typical app requires multiple signing options. ... ...

I've opened corresponding issue an suggested a workaround in its comments.

0

Please sign in to leave a comment.