Release notes for apps for Office (Office 2013, office.js v1.0, schema v1.0)

apps for Office

Find information about known issues for developing an app for Office using Office 2013, office.js version 1.0, and the apps for Office manifests schema version 1.0.

Last modified: November 11, 2014

Applies to: Excel 2013 | Excel 2013 RT | Excel Online | Exchange Online | Exchange Server 2013 | Outlook 2013 | Outlook 2013 RT | Outlook Web App | OWA for Devices | PowerPoint 2013 | PowerPoint 2013 RT | Project Professional 2013 | Word 2013 | Word 2013 RT

   Office.js: v1.0

   Apps for Office manifests schema: v1.0

In this article
Common to all app types
Applicable to specific app types
Additional resources

The following issues apply to developing apps for Office in general, unless otherwise stated.

  • Localized Office Store fronts

    You can now list apps for Office in 5 languages (English, French, German, Japanese and Spanish) in Office Store fronts across 23 corresponding markets, as described in table 1. In each of these markets, the Office Store displays app metadata in either English or the corresponding language. When you submit an app for Office, you can provide metadata (descriptions, screenshots, title) in the languages that you would like your app to be listed in, and explicitly specify these languages as submission languages in the Seller Dashboard. Make sure the primary submission language is in the app manifest. If English is the only submission language, by default, your app will be listed in the Office Store fronts in all 23 markets with English metadata. If any of the 4 non-English languages (French, German, Japanese and Spanish) is a submission language, your app will be listed in the Office Store fronts in the corresponding markets, with metadata in that non-English language. If English and any of the 4 non-English languages are submission languages, then the app will be listed in all the 23 markets with English metadata, except for those markets for which the corresponding non-English language has been submitted, where the metadata will be in the corresponding non-English language.

    Note that in the Seller Dashboard, you can explicitly block markets in which to distribute your app. The 5 languages are a subset of the languages and locales which you can localize an app in and specify in the manifest. If you localized your app in some other supported languages, specify English in the manifest and as a submission language in the Seller Dashboard to get the app listed in the Office Store fronts in all the 23 markets.

    Users can verify if a market-specific Office Store front is available for a market by selecting that market in the upper right of the store page, as shown in Figure 1. From there users either are directed to the market-specific store front, or if that store front is not available, see a message that suggests them to go the Office Store in the United States.

    Figure 1. Verify or choose a different market in the Office Store

    Choose a different market for the Office Store.

    Table 1 lists the submission languages that the Office Store is available in, and the locales and markets that correspond to each of these languages. Language identifiers and OptionState Id values in Office 2013 lists all the languages and locales for which you can localize an app. For information about localizing an app, see Localization and How to: Build a localized app for Office. For information about submitting an app and specifying submission languages in the Seller Dashboard, see How to: Submit apps for SharePoint to the Microsoft Seller Dashboard.

    Table 1. List of distribution languages and corresponding markets for the Office Store

    Submission language

    Locale (language tag)

    Market (country or region)



    United States






    Canada - English



    United Kingdom









    New Zealand






    South Africa



    International English









    Canada - French






    International French

























  • Order of attributes for the Override element in a manifest

    If you use the optional Override element in a manifest, because of an XML parser error, you must specify the Locale attribute before the Value attribute.

Icon for mail apps for Office

OWA for Devices is available

OWA for Devices is a collection of native clients that lets you access Mail, People and Calendar items on specific tablets and smartphones. OWA for Devices comprises of the following native clients:

  • OWA for iPad - an app for iPad 2 or higher, with iOS6 or higher

  • OWA for iPhone - an app for iPhone 4S or higher, with iOS6 or higher

To run mail apps on OWA for Devices, the user’s mailbox must be on the latest release of Office 365.

Parity between Outlook clients

One of the design pillars for apps for Office is write-once. The same calls from your mail app to the JavaScript API for Office should work seamlessly and transparently for all Outlook clients: Outlook for Windows, Outlook for Mac, Outlook RT, OWA for Devices, and Outlook Web App. The following list describes the features and APIs that do not currently support write-once and may work differently depending on the Outlook client:

  • Attachment support in mail apps

    Mail apps can now send a web service an authentication token and attachment identifier to enable the web service to retrieve the attachment from the Exchange server. The following object and members now support attachments in mail apps:

    Note Note

    During the initial release period, the attachments API and callback tokens were first available to mail apps that run on OWA for Devices or Outlook Web App.

Apart from the above JavaScript API, be aware of the following requirements and behavior if you are designing a mail app that will run on OWA for Devices:

  • Use the JavaScript method to open pop-up boxes in your mail app.

  • Properly encode characters in a URI when specifying the URL argument for

  • When the app pane opens in OWA for iPad, the item body is not visible.

Icon for task pane apps

Adding a binding to a named content control in Word may fail

In Word, if there are content controls in both the main document and a subdocument (for example, textbox, header, footer), or in multiple subdocuments, attempting to use the Bindings.addFromNamedItemAsync method to bind to another control in that document may fail as if there was a name collision.

Reading table data as a "text" coercion type may return unexpected characters past the null terminator

In Word, if you use the Document.getSelectedDataAsync method to read the selected data from a table and specify the "text" coercion type, you should ignore the characters after the null-terminator in the returned data, if it's present.

Partial writing to a table may fail

If you are doing partial writing to tables, don’t include header data to get the best results. Because of a known issue, partial writing by calling the Binding.setDataAsync method with the "table" coercion type may fail if the operation includes the last row of the table. To work around this, specify null for the header array in the TableData object that is passed to the data parameter in the setDataAsync method call.

Writing to a table may fail

If you are doing full writing to tables, include header data to get the best results. Because of a known issue, partial reading using the Binding.getDataAsync method or writing by calling the Binding.setDataAsync method with the "table" coercion type may not set all the rows of the table correctly if the header row is null. To work around this, specify data for the header array in the TableData object that is passed as an argument to the setDataAsync method.

Events for custom XML parts may not fire reliably in Word

In Word, changes to a custom XML node (such as deleting, adding, or replacing a node) does not always fire the corresponding nodeDeleted, nodeInserted, or nodeReplaced event. There will be a fix shortly after Office 2013 is available to the general public. Meanwhile, instead of using the events for a custom XML node, consider using the bindingSelectionChanged and bindingDataChanged events if binding to a content control is relevant to your scenario.

For example, if you are creating a custom template where there is a repeating section content control for which you would like to listen events, you can select that content, insert a rich text content control to embed the content in that control. Using the Word user interface, assign a name to the Title property of the rich text content control. Then use the addFromNamedItemAsync method of the Bindings object to add a binding to the rich text content control using that name. With a binding in place, you can now use the bindingSelectionChanged or bindingDataChanged event to determine if you should check for changes in the custom XML part that the repeating content control is bound to.

Because the bindingSelectionChanged and bindingDataChanged events cannot provide any context information about which custom XML part changed, you’ll need to manually track the state to determine changes. Also keep in mind that dependence on nested content controls is not as reliable because users can change the structure of their document.

© 2014 Microsoft