Aidan Garnish

Collaboration Not Competition

Getting a SharePoint 2013 App Submitted to the Office Store

I recently had my first SharePoint 2013 app accepted to the Office Store and thought it would be worth sharing some of the lessons I have learned over the last 3 and a bit months whilst trying to get it through the validation process.

The app I submitted is a CSV Uploader that I had previously developed as a full trust wsp solution that used server side code to upload a selected CSV file into a SharePoint custom list. To try and get a better understanding of the new SharePoint 2013 app model I decided to redevelop this functionality using client side code in a SharePoint hosted app. For more information on the three types of app (SharePoint Hosted; Auto Hosted and Provider Hosted) take a look at this Apps for SharePoint overview.

In the end it took me quite a while to get the app submitted to the store despite the initial development process being relatively quick. There were a few reasons for this that were mostly my own daft fault. However, there were some initial teething problems with the process that meant my submission disappeared down a rabbit hole for a few weeks early on and my Office 365 preview developer site undergoing maintenance for several weeks also didn't help.

So...these are my top tips for a smooth SharePoint app submission process. Of course submitting to the App Store is entirely optional, you could always just distribute the app directly to your sites/clients and avoid Microsoft's Office Store validation rules but where is the fun in that? Laughing

1. Read the validation guidelines very carefully. The two pages you want to look at are Validation policies for the apps submitted to the Office Store (version 1.2) and Validation policies for apps FAQ

  • The main thing I missed was that the app has to work in IE8/9 as well as IE10. Since I was originally using the HTML 5 File API to read the CSV file this caused my app to be rejected as IE8/9 does not support File API.
  • Completing the version number correctly on the submission forms was another brief stumbling block. The version number you enter must match the version number in the AppManifest.xml of your solution.
  • Make sure you include the SupportedLocales tag in your AppManifest.xml - Locale support information is required for all apps in the store.

2. Test in Firefox and Chrome as well as IE8/9/10

  • This might sound obvious but it is easy to assume that once you have your app working in a couple of these browsers your testing is done. This cost me a couple of failed submissions highlighting small things that were due to browser inconsistencies. What didn't help was that one of the Microsoft examples includes code to populate a dropdown list with SharePoint list names but the code to add items to the dropdown list did not work in Firefox despite working fine in IE and Chrome! The example is here and I have submitted a comment to flag the issue.
  • It is also worth checking that any of the newer HTML5 features that your app relies on will function in all browsers supported by SharePoint (IE8/9/10; latest release of Chrome, Firefox, Safari) using the handy Can I Use website. E.g. I originally started out using File API but had to switch to using to support IE8/9

3. Make sure that the test steps you submit to the validation team are crystal clear

  • This probably caused me the most head scratching! The test I asked the validation team to carry out was to try and upload a CSV file with a header row of "Title, Description" to a custom list with a "Title" and a "Description" column. Time and again they came back with an error about the "Description" field not being found but it was working fine on my machine, damn it! I eventually figured out that they had added a site column called "Description" to their custom list but the site column had a static name of "kpidescription" which was causing this error. Once that was figured out and the validation team created a column that had a static name of "Description" the tests passed and all was good.
  • The main learning point here is that if your test steps can be misinterpreted it is far more likely that you will have problems. Trying to debug an issue raised by a remote testing team is very frustrating so it is up to you to keep your tests as clear and as unambiguous as possible.

It has been a long and at times frustrating but ultimately satisfying experience getting my first app approved and I am confident that my future submissions will be made much faster by following the advice above.

Finally, I would like to thank a few people who helped along the way. Thanks to Jeremy Thake who nudged the right people when my submission got lost in the process for three weeks. Huge thanks go to Jes Brown of the Office Store Dev Communications team for all his help, communication and general hand holding through the process. He really went above and beyond in the assisstance he provided even going so far as making some sightseeing suggestions while I was in Seattle! Finally, thanks to the validation team for the excellent and detailed feedback that ultimately helped my app to pass validation and hit the store!