You're viewing help content for version:

The Manage App Tile on the AEM Mobile Dashboard provides the ability to modify details about the Application.

To open the Details page click on the Manage App tile's details link.  From within the Manage App page you can edit the PhoneGap Application Configuration (config.xml) settings and prepare your application for submission to the various application stores.


Platform support

Each mobile application platform is represented with a button beneath the application icon that will change what data is collected, targeting each application store specifically.

Platforms displayed is driven by the PhoneGap config.xml content:

  <gap:platform name="ios"/>
  <gap:platform name="android"/>

Each vendor application store, such as appStore or Google Play for example, requires one or more screenshots of your mobile application in order to display your application details to customers.  These screenshots can have strict requirements around dimensions and content (basically they must truly represent the application). AEM Apps provides support for selecting and managing these screenshots for the supported platforms and view port dimensions as required by each vendor's application store.


Every Application should have associated metadata that aids in configuring different aspects of the application.  The Manage App page is separated into two different areas related to metadata collection.  Platform specific metadata and common metadata. 

Platform Metadata

Every platform that's defined in the PhoneGap config.xml can contain custom platform properties. An AEM developer must contribute the content structure to capture these properties.  A provided example of platform specific properties can be found for iOS.  

When the iOS platform is selected a new metadata section 'iOS Metadata' is displayed along with the 'Common Metadata'.  


The platform metadata sections are not used by PhoneGap during a CLI or Remote PhoneGap build, but rather AEM attempts to capture metadata for platforms such that they can be used later on when submitting to the targeted vendor's application store.  

For platforms which are not understood by AEM, it is still possible for a AEM developer to extend the UI to capture this metadata which later on can be exported and used during the application submission process.

iOS Metadata

The Apple AppStore requires additional metadata in order to submit your application for distribution. The iOS metadata section attempts to collect the required information that can be used by Apple's iTMSTransporter tool to publish the metadata to the associated Apple developer's account.

To obtain the Apple specific metadata you first need to create your application on  Upon creating your application Apple will generate metadata which is required by the iOS metadata section if you wish to use the Apple iTMSTransporter tool to validate and upload the metadata to   If you just want to obtain the metadata to collect you don't necessarily need to fill out the iOS specific metadata.  You can still export the metadata that will merge the iOS and common metadata and collect all the screenshots into a zip file that can be downloaded at any time.

The downloaded zip file contains an itmsp file which can be inspected for the metadata.xml.  The itmsp file contains the exported metadata (within the metadata.xml file), along with all the associated screenshots.

The export functionality is used to provide a convenient way of collecting the screenshots and metadata that can be passed along to the application publisher for input into the vendor specific application store.

Android Metadata

When selecting the Android platform, there is no custom metadata at this point that can be set.  When clicking on the download button as zip file will be generated with a properties file that contains all the metadata and associated screenshots.  

The export functionality is used to provide a convenient way of collecting the screenshots and metadata that can be passed along to the application publisher for input into the vendor specific application store.

Common Metadata

There is common configuration and metadata to all platforms. This information is listed under the Common Metadata section.

In order to edit this data, you must be in edit mode (pencil icon at the top of the page) and have permission to do so. Note, this section may appear empty unless there is data populating the fields.

Within this section you define the Content Update Server URL, landing page for your mobile application, PhoneGap version for compilation, your application version, name, description and more.

Application Version is the working version of your application. Common best practice is to use a 3-decimal notation and start below 1.0.0 prior to your first release.

PhoneGap Version is the version in which you wish to compile your application with PhoneGap. Best practice is to keep up with the current version in order to ensure you get the latest and greatest features and bug fixes.

Content Update Server URL is the URL which your application will use to call for ContentSync updates. It must be set to your dispatcher URL or, if not using a dispatcher, to one of your publish instances that will be used to serve ContentSync updates to your application.


At the top of the details view, you'll see Application Version, PhoneGap Version and Update URL, each of these values can be set within Common Metadata section. However, the Application ID cannot be edited.

Content Update Server URL

One of the key features of AEM Apps is the ability to have a mobile application request new content through ContentSync, where content can be html resources, pages, video, images, text and more. Once a content author has updated content and then publishes that content the server makes the content update available for the mobile application to download.

The Content Update Server URL property is the URL that must point to a publish instance; either directly or through the dispatcher or CDN. The format of the URL is simply:




If your Author server instance is replicating to multiple publish server instances (common architecture for AEM), each publish server will have the same update content because the update is built on the author and replicated to all publish instances.  Basically, load balancing and failover is fully supported.