Release notes for apps for Office (Office 2013, office.js v1.0, schema v1.0)
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
Apps for Office manifests schema: v1.0
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.
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.
Locale (language tag)
Market (country or region)
Canada - English
Canada - 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.
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:
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
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.