Validation policies for apps FAQ

To help make your app submission as trouble-free as possible, we’ve listed some common submission errors, and how to avoid them, below:

• Make sure that the app version number on the submission form exactly matches the app version number in the app version manifest.

  Note
  You must specify your app version using the following syntax: a. b. c. d Where a is an integer between 1-9999, and each of b, c, d are each integers between 0-9999. For example: 1.0.0.0 6.23.0.1

• Make sure that all app locations are SSL-secured (HTTPS).

• Make sure you specify an icon for your app in your app package or manifest, and that the icon is correctly sized and formatted.

  • For apps for Word, Excel, and Project, you are required to link to an image using the <IconUrl> element in the app manifest. The image specified must be 32 pixels by 32 pixels.

    For more information, see IconUrl element (OfficeApp complexType) (apps for Office).

  • For mail apps, you are required to link to an image using the <IconUrl> element in the app manifest. The image specified must be secured with HTTPS. This image is shown as the 64 pixels by 64 pixels image associated with your app in the installed apps dialogue. For best customer experience, specify a 64 pixel by 64 pixel image for the IconUrl element in app manifests for mail apps. Validation requires this image to be between 64 pixels by 64 pixels and 128 pixels by 128 pixels. The image must be in one of the following file formats: GIF, JPG, PNG, EXIF, BMP or TIFF

    For more information, see IconUrl element (OfficeApp complexType) (apps for Office).

  • For apps for SharePoint, you are required to include an icon in the app’s package. The image included must be 96 pixels by 96 pixels. The image that you include in your app’s package must match the image that you submit via the Seller Dashboard form.

• Make sure your app’s ID is unique.

  A common mistake is creating a manifest for a second app based on a previously-submitted manifest and forgetting to change the app ID in the new manifest.

• Make sure your app manifest is valid against the current manifest schema.

  For detailed manifest schema information, see Schema reference for apps for Office manifests and Schema reference for manifests of apps for SharePoint.

• Make sure your app has been tested and is fully functional.

• Make sure your apps for SharePoint specify their supported locales.

  You are required to specify supported locales, or your app will not be accepted by the Office Store. See Locale support information is required for all apps in the Office Store for details.

• Make sure your OAuth client IDs match

  If your app for SharePoint accesses services using OAuth, make sure the OAuth client ID that you created in Seller Dashboard matches the client ID in your app manifest.

• Make sure you specify a Support URL in the SupportUrl element of your app for Office manifest

• Your app for SharePoint package must conform to the Open Packaging Convention.

• Make sure that you submit a privacy link.

  You’re required to include a privacy link for each app that you submit to the Seller Dashboard. The privacy link must link to a valid privacy statement. If your app does not collect or transmit user information, you must link to a statement that states this fact.

One of the strengths of the app model is that, if you make updates to the web service for your app, you do not have to resubmit your app to the Office Store. However, if you make changes to any items or data you submitted for your app via the Seller Dashboard, such as the app manifest, screenshots, icons, or app submission form data, you’ll need to resubmit your app so that the Office Store can implement those changes. You must resubmit your app with an updated app manifest that includes a new version number. You must also make sure to update the app version number in the submission form to match the new manifest's version number.

You can now submit paid apps to the Office Store through the Seller Dashboard, with the following restrictions:

• If your app for SharePoint contains an app for Office, it must be priced as free in the Office Store. Paid apps for SharePoint that contain apps for Office will not be accepted until these commerce capabilities are enabled.

• Only mail apps priced as free are being accepted into the Office Store at this time.

• Additional restrictions apply to autohosted apps.

  See Can I submit an autohosted app for SharePoint to the Office Store?, below, and policy 10.2 in Validation policies for the apps submitted to the Office Store (version 1.4) for information on autohosted apps.

In addition, consider the following when deciding whether to submit a paid app:

• If you submit a paid app, you can also choose to offer a trial. If you choose to submit a trial offer in conjunction with your paid app, it is recommended that your app use the Office app licensing framework.

  For more information, see Licensing apps for Office and SharePoint, Which business model is right for your app?, and Creating and verifying licensing in a paid app for Office.

The infrastructure for autohosted apps will remain in preview status for a period of time after SharePoint 2013 releases. Autohosted apps (which includes all apps that depend on Access) will not be accepted by the Office Store during this preview phase.

For more information on autohosted apps, see How to: Create a basic autohosted app for SharePoint.

If your app uses the JavaScript APIs for Office, you must reference the Microsoft-hosted Office.js file located at:

https://appsforoffice.microsoft.com/lib/1.0/hosted/office.js

Do not include a copy of the Office.js file in your app, or reference a copy of the file hosted elsewhere.

Apps that are not SSL-secured (HTTPS) generate unsecure content warnings and errors during use. For this reason, all apps submitted to the Office Store are required to be SSL-secured.

There are two aspects of your app submission that relate to supported languages:

1. The languages you declare in your app package or manifest

   You declare which languages your app supports differently depending on app type:

   • For apps for SharePoint, declare language support using the SupportedLocales element (PropertiesDefinition complexType) (App Manifest), in the app manifest within the app package. For more information, see Explore the app manifest and the package of an app for SharePoint.

     The maximum number of allowable supported locales for apps in the Office Store is 25.

   • For apps for Office that aren’t dictionaries, declare language support using the DefaultLocale element (OfficeApp complexType) (apps for Office) and the Override element (LocaleAwareSetting complexType) (apps for Office), within the app manifest. For more information, see Designing an app for Office for specific locales.

     The maximum number of allowable declared languages for apps in the Office Store is 25.

   • For apps for Office that are dictionaries, you can also use the TargetDialects element (Dictionary complexType) (apps for Office) within the app manifest.

     The maximum number of allowable TargetDialects for apps in the Office Store is 25.

2. As a first step to app submission, you will select a default language for the app in Seller Dashboard. As a second step, you are able to add additional languages via Add A Language.

   Note
   You can declare more languages in your app's package than are available for submission in Seller Dashboard.

• Validation policies for the apps submitted to the Office Store (version 1.4)

• Publish apps for Office and SharePoint

• How to: Create or edit your seller account in the Microsoft Seller Dashboard

• How to: Add apps in the Microsoft Seller Dashboard

• How to: Create an effective Office Store listing for your app for Office or SharePoint

• How to: Create Client IDs and secrets in the Microsoft Seller Dashboard

• Start building apps for Office and SharePoint

• Apps for Office and SharePoint UX guidelines