Export (0) Print
Expand All

Creating a manifest for a mail app to activate in a read or compose form in Outlook (schema v1.1)

apps for Office

Walk through the four basic steps to create a manifest for a mail app using version 1.1 of the apps for Office schema. The manifest allows the mail app to be activated in a read form or compose form in Outlook.

If you are looking for information about using schema v1.0, see Creating a manifest for a mail app to activate in a read form in Outlook (schema v1.0).

Last modified: April 01, 2014

Applies to: Exchange Online | Exchange Server 2013 SP1 | Outlook 2013 RT | Outlook 2013 SP1 | Outlook Web App | OWA for Devices

   Office.js: v1.1

   Apps for Office manifests schema: v1.1

Note Note

"Outlook" in this article refers to the Outlook rich client, Outlook RT, Outlook Web App, and OWA for Devices.

In this article
Anatomy of a typical manifest
Step 1: Specifying the root element
Step 2: Identifying the app
Step 3: Specifying the scope of support of the app
Step 4: Specifying information for app operations
Appendix A: sample XML manifest
Additional resources

Figure 1 shows the four steps to create an example manifest for a fictitious mail app, Templates, that manages templates in Outlook. The rest of this article describes each of the four steps. Appendix A: sample XML manifest lists the complete sample manifest.

Figure 1. Anatomy of a typical manifest for a mail app

Steps to create manifest for a read or compose app

  

4 basic steps of creating a manifest for a mail app

Applying the four steps to other types of apps for Office

In the four-step process, steps 1 and 2 are generally applicable to all types of Office apps—content, mail, and task pane apps. Some elements in steps 3 and 4 are relevant only to mail apps. For a complete set of elements supported by the app schema, please refer to Schema reference for apps for Office manifests (v1.1).

Note that this topic does not assume any specific XML editor. In general you can use any development tool to create an app manifest. If you’re using Visual Studio to develop your app for Office, you can use the Visual Studio manifest designer to change manifest settings, rather than manually changing the underlying XML markup. By default, when you open an app manifest file in Visual Studio, it opens in the manifest designer. The designer organizes the fields in the manifest, making them easier to find. Some fields have drop-down list boxes that contain valid field values, helping reduce data entry errors.

Specify OfficeApp as the root element in the manifest and place all other elements in the manifest within its open and close tags. Figure 2 is an example for the Templates mail app.

Figure 2. Specifying the root element for a mail app

Step 1, specify namespace and schema version

Specifying a version of the schema as the default namespace

The OfficeApp element specifies version 1.1 of the schema as the default namespace as shown below:

xmlns="http://schemas.microsoft.com/office/appforoffice/1.1

One schema, different app types

The Templates sample manifest uses the xsi:type attribute of the OfficeApp element to specify that the manifest is for a mail app:

xsi:type="MailApp"

As the root element, the OfficeApp element supports child elements most of which apply to all types of apps for Office. We’ll talk about these common child elements in steps 2 and 3. To support the specificity of each type of app, however, the schema defines the OfficeApp element as an abstract type. You can use the xsi:type attribute to extend this abstract type as a ContentApp, MailApp, or TaskPaneApp complex type. Specificity includes the target hosts, the version of office.js, and the permissions that the app requires, and how the app is displayed in the host application. Make sure you follow the order that these child elements are defined under OfficeApp or the extended parent type.

You will see in steps 2, 3 and 4 the use of elements that are specific to mail apps.

In this step, you provide identification information for the app. Figure 3 shows the elements that the example Templates mail app uses to provide such information in the manifest, and where such information is surfaced in the Exchange Admin Center (EAC).

Figure 3. Identifying the mail app

Step 2-Identifying the mail app

Identifying elements occurring in sequence

The elements used for identification in the Templates example are listed in Table 1. These elements share the root element OfficeApp as their parent, and follow a sequence as defined in the OfficeApp complex type. They are all mandatory and apply to all apps for Office, except for IconUrl and HighResolutionIconUrl which are optional.

Table 1. Elements for identification

Id

A UUID unique string for programmatic identification; required. The Templates example uses a GUID as a value.

Version *

A string that specifies the current version of the app; required. The Templates example specifies a version number of 1.0.

ProviderName *

The name of the individual or company that is offering the app; required. The Templates example specifies Contoso as its provider.

DisplayName *

The label string that represents the app in the host UI; required. For a compose app, the name is displayed in the Outlook app selection pane. For a read app, the name appears in the app bar if Outlook activates the mail app. The Templates example uses Templates as the label.

Note that the DisplayName element supports a DefaultValue attribute that corresponds to the locale specified by the DefaultLocale element. See step 3 for more information about DefaultLocale.

If you are submitting the app in the Office Store, you should keep the name consistent in the manifest and in the Seller Dashboard app submission form. For more information, see the section Name your app appropriately in How to: Create an effective Office Store listing for your app for Office or SharePoint.

Description *

A string that typically explains the purpose of the app; required. The Templates example provides the description "Helps you manage templates in Outlook."

Note that the Description element supports a DefaultValue attribute that corresponds to the locale specified by the DefaultLocale element. See 3 for more information about DefaultLocale.

IconUrl *

The URI of an image file that represents the app; optional. For mail apps, it represents the compose or read app in the EAC, if it’s specified.

Note that the IconUrl element supports a DefaultValue attribute that corresponds to the locale specified by the DefaultLocale element. See 3 for more information about DefaultLocale.

The element is optional in the app manifest, unless you are submitting the app to the Office Store, in which case you must include this element. For more information about submitting images that represent an app in the Office Store, see Create a properly formatted icon for your app for Office or app for SharePointHow to: Create an effective Office Store listing for your app for Office or SharePoint.

HighResolutionIconUrl

The URI of a high resolution image file that represents the app; optional. For mail apps, this image represents the compose app in the app selection pane in Outlook.

This element applies to only compose apps and not read apps, and is useful if Outlook is running on a high DPI device. If you don’t specify this element for a compose app but specifies IconUrl, Outlook uses the latter in the app selection pane.

Similar to IconUrl, you can provide a locale-specific image for this element.

*After the user installs the mail app, the values for Version, ProviderName, DisplayName, Description and IconUrl are surfaced in the EAC, as illustrated in Figure 3.

In this step, you specify the scope of support that the app provides and requires:

You can specify the locales, the modes of the Outlook forms, devices, and any device-dependent custom user interface that the app supports. You should also specify any additional web domains, the host application, and subset of members in the JavaScript API for Office that the app requires. The corresponding elements are defined in sequence in the OfficeApp and MailApp complex types, so make sure you specify the ones you use in the appropriate order. Figure 4 shows how the example Templates mail app specifies its scope of support.

Figure 4. Specifying the scope of support of the mail app

Step 3, specifying the scope of support

Multiple locale support

The elements that support locales for apps for Office are described in Table 2.

Table 2. Elements for locale support

DefaultLocale

A language tag that the host application can assume as the default language for the strings in the manifest, and as the default culture of the users; required. For mail apps, you can specify locale-dependent values in the Description, DisplayName, IconUrl, HighResolutionIconUrl, and SourceLocation elements.

Override

Provides an additional locale and locale-dependent value for the corresponding element; optional. Depending on the element, the value can be a text string or URI.

The Templates example applies a locale override for the Description element: it specifies a default locale of en-us and an English description, and specifies an Override statement with a Japanese description for the ja-jp locale:

<DefaultLocale>en-us</DefaultLocale>
…
<Description DefaultValue="Helps you manage templates in Outlook.">
  <Override Locale="ja-jp" Value ="Outlook テンプレートを管理できます。" />
</Description>

This means that the app assumes the en-us locale by default, specifies the English description for all locales unless the client computer’s locale is ja-jp, in which case the app provides a Japanese description.

You can similarly use the Override element to provide locale-specific string values for the DisplayName element, and locale-specific URI values for the IconUrl, HighResolutionIconUrl and SourceLocation elements. For more information, see Designing an app for Office for specific locales.

Additional domain requirements

Table 3 lists the elements that support an app navigating to more than one domain within the app pane.

Table 3. Elements for additional domain requirements

AppDomains

Allow an app to navigate to domains other than the default domain, while staying within the app pane; optional.

AppDomain

A string that specifies an additional domain that the app can navigate to; required, if you specify the AppDomains element.

The domain of the app start page that you specify in the SourceLocation element is the default domain for that context. Without using the AppDomains and AppDomain elements, if your app attempts to navigate to another domain, the browser will open a new window outside of the app pane. If you want the navigation to stay within the app pane, add an AppDomains element and include each additional domain in its own AppDomain sub-element in the app manifest.

The Templates example specifies a domain https://www.contoso2.com as a second domain that the app can navigate to within the app pane:

<AppDomains>
  <AppDomain>https://www.contoso2.com</AppDomain>
</AppDomains>

For more information about letting your app navigate to a domain other than the default, see How to: Navigate to more than one domain within the same app pane.

Hosts and office.js requirements

The elements in Table 4 let you specify what your app requires to run: the target hosts, the subset of members in the JavaScript API for Office, and the minimum version of the API (office.js).

Table 4. Elements for hosts and office.js requirements

Hosts

The general design of the Hosts and Host elements applies to all types of apps for Office, which allows targeting an app for one or more host applications that support a similar functionality like workbook or mailbox; optional.

Host

A string that maps to one or more host applications that the app is designed for. While Hosts is optional, if you specify a Hosts element, for mail apps, then you must specify at least one Host sub-element with "mailbox" in the Name attribute ("mailbox" is a case-insensitive string), as one of the conditions for Exchange and Outlook to install the mail app. The Templates example specifies Hosts and Host elements as shown below:

<Hosts>
  <Host Name="Mailbox" />
</Hosts>

Requirements

The general design of the Requirements, Sets and Set elements applies to all types of apps for Office, which allows specifying one or more subsets of the JavaScript API for Office that the app requires. Because mail apps do require office.js, you must include these 3 elements for a mail app.

Sets

Specifies one or more subsets of the JavaScript API for Office that the app requires; required for mail apps. The DefaultMinVersion attribute states the minimum required version of the API over all the subsets specified as sub-elements. The attribute is optional, but if you do specify it, as a good consistency check, state at least office.js v1.1 as the minimum required version which is compatible with schema v1.1:

<Requirements>
  <Sets DefaultMinVersion="1.1" >
    <Set Name="Mailbox" />
  </Sets>
</Requirements>

Note that if the version you specify is higher than that supported by the user’s Exchange server or Outlook, Exchange and Outlook will not install the mail app.

Set

Specifies a subset of members in the JavaScript API for Office that the mail app requires, by assigning "mailbox" to the Name attribute ("mailbox" is a case-insensitive string); required for mail apps. You must state the minimum version of office.js for this subset, using the MinVersion attribute. Since this attribute is new in schema v1.1 which requires at least office.js v1.1, you cannot specify MinVersion as 1.0. If you specify both a DefaultMinVersion attribute for the Sets element and a MinVersion for the Set sub-element for "mailbox", then Exchange and Outlook will consider only the version in MinVersion. The Templates example specifies a MinVersion attribute as shown below:

<Requirements>
  <Sets DefaultMinVersion="1.1" >
    <Set Name="Mailbox" MinVersion="1.1" />
  </Sets>
</Requirements>

Compose or read form support

Specific to mail apps is specifying whether the app works while the user is authoring an item (for example, in a compose form of an appointment) or viewing an item (such as reading a meeting request or email). Table 5 includes the elements that allow specifying whether a mail app works in a compose form, read form, or both.

Table 5. Elements for compose or read form support

FormSettings

Allows specifying one or more modes (compose and/or read) of Outlook forms that the mail app works in; required.

Form

Allows specifying the mode of a form that the mail apps works in, as described below; required.

  • Specify xsi:type="ItemEdit" for a compose form of a supported item.

  • Specify xsi:type="ItemRead" for a read form of a supported item.

To further specify the types of items (appointment or message) that the mail app supports, use the ItemIs rule. See more information in the subsection Activating the app in a compose or read form in step 4.

The Templates example supports forms in compose and read modes, and specifies both modes as below:

<FormSettings>
  <Form xsi:type="ItemRead">
    <!-- More XML pertaining to a read form.-->
  </Form>
  <Form xsi:type="ItemEdit">
    <!-- More XML pertaining to a compose form.-->
  </Form>
</FormSettings>

You will see in the next section Tablet and smartphone support the additional XML that you'll specify for forms of each mode.

Tablet and smartphone support

Also specific to mail apps is the support for the default desktop form factor, optional tablet and smartphone form factors, and any locale-dependencies. The related elements are in Table 6.

Table 6. Elements for form factor support

DesktopSettings element (ItemEdit complexType)

DesktopSettings element (ItemRead complexType)

Settings for the mail app running on a desktop computer in the corresponding mode of a form; required.

For a compose form, specify the URI of the source file in the SourceLocation element (ItemEditMailAppSettings complexType).

For a read form, specify the corresponding source file in SourceLocation element (ItemReadDesktopMailAppSettings complexType). Optionally, specify the desired height of the app in the RequestedHeight element (ItemReadDesktopMailAppSettings complexType).

The Templates example specifies the following settings for the desktop form factor:

  • In a compose form:

    <DesktopSettings>
      <SourceLocation DefaultValue=
      "https://<domain>/source_compose_richclient.html" />
    </DesktopSettings>
    
  • In a read form:

    <DesktopSettings>
      <SourceLocation DefaultValue=
      https://<domain>/source_read_richclient.html"/>
      <RequestedHeight>350</RequestedHeight>
    </DesktopSettings>
    

TabletSettings element (ItemEdit complexType)

TabletSettings element (ItemRead complexType)

Settings for the mail app running on a tablet in the corresponding mode of a form; optional.

For a compose form, specify the URI of the source file in the SourceLocation element (ItemEditMailAppSettings complexType).

For a read form, specify the corresponding source file in SourceLocation element (ItemReadTabletMailAppSettings complexType). Optionally, specify the desired height of the app in the RequestedHeight element (ItemReadTabletMailAppSettings complexType).

The Templates example specifies the following settings for the desktop form factor:

  • In a compose form:

    <TabletSettings>
      <SourceLocation DefaultValue=
      "https://<domain>/source_compose_tablet.html" />
    </TabletSettings>
    
  • In a read form:

    <TabletSettings>
      <SourceLocation DefaultValue=
      "https://<domain>/source_read_tablet.html" />
      <RequestedHeight>250</RequestedHeight>
    </TabletSettings>
    

PhoneSettings element (ItemEdit complexType) (app manifest schema v1.1) PhoneSettings element (ItemEdit complexType)

PhoneSettings element (ItemRead complexType)

Settings for the mail app running on a smartphone in the corresponding mode of a form; optional.

For a compose form, specify the URI of the source file in the SourceLocation element (ItemEditMailAppSettings complexType).

For a read form, specify the corresponding source file in SourceLocation element (ItemReadPhoneMailAppSettings complexType).

The Templates example specifies the following settings for the desktop form factor:

  • In a compose form:

    <PhoneSettings>
      <SourceLocation DefaultValue=
      "https://<domain>/source_compose_phone.html" />
    </PhoneSettings>
    
    
  • In a read form:

    <PhoneSettings>
      <SourceLocation DefaultValue=
      "https://<domain>/source_read_phone.html" />
    </PhoneSettings>
    
    

SourceLocation element (ItemEditMailAppSettings complexType)

SourceLocation element (ItemReadDesktopMailAppSettings complexType)

SourceLocation element (ItemReadTabletMailAppSettings complexType)

SourceLocation element (ItemReadPhoneMailAppSettings complexType)

A URI for the HTML source file that is appropriate for the parent form factor element; required if the parent form factor element is specified.

Applying a locale override to the SourceLocation element allows you to provide a specific source file for a specific locale for that form factor and mode of form. For more information, see Designing an app for Office for specific locales.

RequestedHeight element (ItemReadDesktopMailAppSettings complexType)

RequestedHeight element (ItemReadTabletMailAppSettings complexType)

The number of pixels that the mail app requires as the height of the app pane, as appropriate for the corresponding desktop or tablet form factor in a read form; optional.

In a compose form, the height of a compose app is not customizable.

Even though the JavaScript API for Office supports "write once, run all" for mail apps, and generally the same method in the API works transparently across different form factors, you may still want to customize the app experience, for example, for users on a larger tablet screen versus a smaller smartphone screen. Stepping back, because the scenarios available for a mail app in a compose form and read form often differ, the API objects and methods available for mail apps also differ, you would implement separate code for a compose scenario versus a read scenario. Version 1.1 of the apps for Office manifest schema lets you customize a source file and user interface for each mode, form factor and locale.

The Templates example supports read and compose forms, and all 3 form factors. It provides separate source files for each of read and compose modes, and for each form factor in that mode. For the desktop and tablet form factors in read mode, it also specifies a desired height for the mail app in the app pane. Below shows how the Templates example specifies its source files:

  <FormSettings>
    <Form xsi:type="ItemRead">
      <DesktopSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_read_richclient.html" />
        <RequestedHeight>350</RequestedHeight>
      </DesktopSettings>
      <TabletSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_read_tablet.html" />
        <RequestedHeight>250</RequestedHeight>
      </TabletSettings>
      <PhoneSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_read_phone.html" />
      </PhoneSettings>
    </Form>
    <Form xsi:type="ItemEdit">
      <DesktopSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_compose_richclient.html" />
      </DesktopSettings>
      <TabletSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_compose_tablet.html" />
      </TabletSettings>
      <PhoneSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_compose_phone.html" />
      </PhoneSettings>
    </Form>
  </FormSettings>

For more information about the specific form factors that mail apps support, see Overview of apps for Office. For guidelines about designing mail apps for different form factors, see Set up a mail app for Outlook on tablets and mobile devices (schema v1.1) and Apps for Office UX design guidelines.

In this last step, specify the necessary permission and conditions for Outlook to display the mail app, which are also referred as activation rules:

Figure 5 shows the permission and activation rules that the example Templates mail app specify.

Figure 5. Specifying information for operations of the mail app

Step 4, Stating permissions and activation rules

4 tiers of permission determine available APIs

Table 7. Elements for permissions

Element

Description

Supported permission values

Permissions

The permission that the mail app requires to carry out its operations; required.

Restricted, ReadItem, ReadWriteItem, and ReadWriteMailbox

The 4 tiers of permissions are specific to mail apps. Figure 5 shows what you can do with each permission in this 4-tier model.

Figure 5. The 4-tier permissions model for mail apps

4-tier permissions model for mail apps schema v1.1

  

In general, you should specify the minimum necessary permission that your app needs, depending on the exact methods that you plan to use. For example, a mail app that activates in compose forms and only reads but does not write to item properties like Appointment.requiredAttendees, and does not call Mailbox.makeEwsRequestAsync to access any Exchange Web Services operations should specify ReadItem permission.

The Templates mail app specifies ReadWriteItem in the Permissions element in the manifest so that it can access compose APIs in the context of a compose form, as shown below:

<Permissions>ReadWriteItem</Permissions>

See Specify permissions for mail app access to the user's mailbox for details about each tier of permission.

Addressing users’ concern for app security

You must explicitly specify the permission your app needs in the Permissions element in the manifest. If you submit the mail app to the Office Store, using the value you specify, the Office Store will be able to provide consistent, contextual explanation for the extent of possible actions that the app can take in the app listing. End users or IT administrators can decide whether or not to install your app based on the permission you request. After installation, the requested permission is prominently displayed in the Exchange Admin Center (EAC). See Privacy, permissions and security for mail apps in Outlook and Specify permissions for mail app access to the user's mailbox for details.

Accessing necessary APIs

In general, for any type of apps for Office, you should request only the minimum necessary permission for your app. If your app works in a compose form and uses the write methods (for example, Message.to.addAsync or Message.to.setAsync), then you must specify at least the ReadWriteItem permission. Otherwise, depending on the actual methods that your app accesses in the JavaScript API for Office, or the kinds of activation rules that your app specifies in the manifest, choose the minimum necessary permission from Restricted, ReadItem, and ReadWriteMailbox. Specify ReadWriteMailbox only if your mail app uses the Mailbox.makeEwsRequestAsync method. For more details about the support each level of permission provides, see Specify permissions for mail app access to the user's mailbox.

Activating an app in a compose form

Specific to mail apps is using the Rule element to define specific conditions where the mail app is relevant and Outlook should activate it. Activating a mail app is to have Outlook display it in the app selection pane (in a compose form) or app bar (in a read form). The Rule element is mandatory.

In general, you can use the xsi:type attribute to extend the Rule abstract type to different types of rules. There is only one type of rule, ItemIs, that you can use to activate an app in a compose form. Table 8 shows the attributes and possible values you can use with it.

Table 8. Element and type of rules to activate an app in a compose form

Element

Extending a Rule as this type

Activation condition

Attributes & possible values

Rule

ItemIs

The current item is of the specified item type (message or appointment).

ItemType: type of Outlook item that the app supports; required. Choose from: Message or Appointment.

FormType: specifies the possible mode or modes of Outlook forms that the app can be activated in; required. To activate the app in only a compose form for the specified item type, specify Edit. To activate the app in a compose or read form, specify ReadOrEdit.

ItemClass: Outlook message class; ignored unless FormType is Read.

IncludeSubClasses: ignored unless FormType is Read.

To specify activation rules for a compose app, you would specify one ItemIs rule for each item type your app supports. Then in each rule for that item type, specify the FormType - whether the app is to be activated in a compose form (Edit), or compose or read form (ReadOrEdit).

Activating an app contextually in a read form

Similar to a compose scenario, you can use the xsi:type attribute to extend the Rule abstract type to other types of rules to activate an app in a read form. There are more types of rules that you can use in read forms that support activating the app based on the existence of certain strings or attachments in the selected Outlook item. Table 8 shows the type of rules and attributes you can use with them.

Table 9. Element and types of rules to activate an app in a read form

Element

Extending a Rule as this type

Activation condition

Attributes & possible values

Rule

ItemIs

Currently selected item is of the specified type (message or appointment).

ItemType: type of Outlook item that the app supports; required. Choose from: Message or Appointment.

FormType: the possible modes of the Outlook form that the app can be activated in; required. To activate the app in only a read form, specify Read. To specify the app in a compose or read form, specify ReadOrEdit.

ItemClass: Outlook message class; optional, and ignored unless FormType is Read.

IncludeSubClasses: ignored unless FormType is Read; optional, default is false.

Rule

ItemHasKnownEntity

Currently selected item contains an instance of the specified entity, and optionally matches the specified regular expression.

EntityType: a value in KnownEntityType, required.

FilterName: the name of the optional regular expression for the entity; optional.

RegExFilter: regular expression for the entity; optional.

IgnoreCase: for matching the specified regular expression; optional. Default is false.

Rule

ItemHasRegularExpression

Currently selected item contains a match to the specified regular expression.

PropertyName: required. Choose from Subject, BodyAsHTML, BodyAsPlaintext, or SenderSMTPAddress.

RegExName: the name of the regular expression; required.

RegExValue: the regular expression; required.

IgnoreCase: whether to ignore the case when matching the specified regular expression; optional. Default is false.

Rule

ItemHasAttachment

Currently selected item contains an attachment

No attributes

For more information about activation rules available for read apps, see Activate mail apps in Outlook clients, Use regular expression activation rules to show a mail app in Outlook, and Match strings in an Outlook item as well-known entities.

Combining activation rules to activate a mail app in a compose or read form

Sometimes you need to specify more than one activation rule for a mail app. When designing activation rules, you should first consider whether your scenarios occur in only compose forms, read forms, or both types of forms. If your app works in compose forms, you should include one or more ItemIs rule as described in Table 8. If your app also works in read forms, you may want to include additional rules as described in Table 9. The schema for apps for Office manifests requires you to combine multiple rules into one rule of the RuleCollection type. Table 10 describes that Rule element, attribute and possible values you can use with it.

Table 10. Element to combine multiple rules

Element

Extending a Rule as this type

Activation condition

Attributes & possible values

Rule

RuleCollection

A rule collection that evaluates to true

Mode: logical And or Or

The Templates example specifies 2 ItemIs rules, one for each of the message and appointment item types. For each supported item type, the rule specifies the ReadOrEdit form type. It combines the 2 rules using the Or operator, so that Outlook activates the app when the user reads or authors a message or appointment.

<Rule xsi:type="RuleCollection" Mode="Or">
  <Rule xsi:type="ItemIs" FormType="ReadOrEdit" ItemType="Message" />
  <Rule xsi:type="ItemIs" FormType="ReadOrEdit" ItemType="Appointment" />
</Rule>

For more examples of rule collections that support compose and read scenarios, see Activate mail apps in Outlook clients.

The following is a listing of the XML manifest for the example Templates mail app described in this topic.

<?xml version="1.0" encoding="utf-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:type="MailApp">
  <Id>5283AFBB-806E-2D05-BBAF-EF3384D3729A</Id>
  <Version>1.0</Version>
  <ProviderName>Contoso</ProviderName>
  <DefaultLocale>en-us</DefaultLocale>
  <DisplayName DefaultValue="Templates" />
  <Description DefaultValue="Helps you manage templates in Outlook.">
    <Override Locale="ja-jp" Value ="Outlook テンプレートを管理できます。" />
  </Description>
  <IconUrl DefaultValue="https://<domain>/Icon.png" />
  <HighResolutionIconUrl 
    DefaultValue="https://<domain>/HighResIcon.jpg" />
  <AppDomains>
    <AppDomain>https://www.contoso2.com</AppDomain>
  </AppDomains>
  <Hosts>
    <Host Name="Mailbox" />
  </Hosts>
  <Requirements>
    <Sets DefaultMinVersion="1.1">
      <Set MinVersion="1.1" Name="Mailbox" />
    </Sets>
  </Requirements>
  <FormSettings>
    <Form xsi:type="ItemRead">
      <DesktopSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_read_richclient.html" />
        <RequestedHeight>350</RequestedHeight>
      </DesktopSettings>
      <TabletSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_read_tablet.html" />
        <RequestedHeight>250</RequestedHeight>
      </TabletSettings>
      <PhoneSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_read_phone.html" />
      </PhoneSettings>
    </Form>
    <Form xsi:type="ItemEdit">
      <DesktopSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_compose_richclient.html" />
      </DesktopSettings>
      <TabletSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_compose_tablet.html" />
      </TabletSettings>
      <PhoneSettings>
        <SourceLocation DefaultValue=
          "https://<domain>/source_compose_phone.html" />
      </PhoneSettings>
    </Form>
  </FormSettings>
  <Permissions>ReadWriteItem</Permissions>
  <Rule xsi:type="RuleCollection" Mode="Or">
    <Rule xsi:type="ItemIs" FormType="ReadOrEdit" ItemType="Message" />
    <Rule xsi:type="ItemIs" FormType="ReadOrEdit" ItemType="Appointment" />
  </Rule>
</OfficeApp>

Show:
© 2014 Microsoft