The SharePoint 2013 App Playbook - Your Guide to building and publishing a great app


Published on

Office 2013 has brought an amazing new platform for developers to take advantage of, in the format of apps and the online app store. SharePoint 2013 takes full advantage of this and developers can now publish apps to the store and get their products out to a bigger audience than ever before with minimal time and effort. But if you have an idea for the next big app, how do you go about building it and publishing it for the masses? Well then my friend, this is the session for you! During this session Brian and Alex will take you through the full process for building and publishing apps for SharePoint and Project Server 2013 to the store. The boys will share with you the techniques and strategies you will need to create apps that will engage and amaze users, as well as what to do with an app to help make sure it makes its way through the app stores approval process and on to the app store. You’ll get to see real world stories and learnings from apps that are available on the store today, as well as what potential issues you might come across while working with your own apps. If you have ever thought about building an app or are in the process of creating one, this session is a must see!

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The new customisation modelApps are a new type of way we can customise the Office stack, it provides a new standards based direction that’s designed to open up customising SharePoint and Office to a wider audience than ever before. Focus on flexibilityThe new app model brings HTML and JavaScript to the forefront of the app development experience – which means you no longer need to know how to write .NET to create extensions for the Office platform. Familiar tools can be used to generate HTML and JavaScript and you can select whatever tooling you feel is best for the job to create new experiences that bring Office in to a new era, that is more ready than ever for the cloud.Simplify for end usersThe other big benefit of the new approach is that it has enormous benefits for end users – there are no longer complicated processes for installing customisations to Office clients or to SharePoint. A new marketplace facilitates a whole new way for apps to be discovered, and a few simple clicks later the app is installed and ready to use without the need to install components on to servers or install full applications on to client machines.
  • Two types of appsThe new framework provides for two different groups of applications – apps for SharePoint and apps for Office. Apps for SharePointApps for SharePoint provide a new approach to create customisations for SharePoint sites. They bring a focus on using open standards to access SharePoint such as REST and oData, as well as an emphasis on running custom code remotely to the SharePoint farm. SharePoint apps are designed for scale, they are designed to run in the cloud, and they are designed to be seamless in their integration so that the user experience is not disjointed by remote execution scenarios. Apps for OfficeApps for Office allow for specific types of extensions to Office client apps. Again they focus on delivering customisation through HTML and JavaScript, and are designed to integrate in to Office client applications. Certain types of Office apps also have support for the web application versions of the Office software, and can be rendered in the browser and provide exactly the same functionality as they do when run on a desktop client, which brings a new “code once and deploy everywhere” element to customising the Office experience.
  • Common standardsWith a focus on building apps with HTML and JavaScript, common standards is now able to come to the front of mind for developers. Technologies such as REST and oData have been built in to the SharePoint client side APIs to enable more universal approaches to how data can be incorporated from SharePoint in to apps on any platform in any environment and have all the communication take place over HTTP, in a new fully featured way that has not been possible to date.Loose dependenciesMuch like developers who write apps for Facebook or Twitter, apps for Office are now much more loosely bound with the platform and are only dependent on the API endpoints that they consume. This enables SharePoint and Office to be updated and have a much lower risk of causing issues with customisations. This can remove what has traditionally been a significant component of an upgrade project for Office and SharePoint users.New delivery channelsThe app store adds a new discoverability component to SharePoint customisations – all app developers, big and small, can publish in to the store and be discovered by users in multiple markets. This introduces the ability for developers from everywhere to be able to come together and create a new ecosystem for apps and customisations that is similar to the app model that has been prominent in the smart phone market for years now.
  • SharePoint architectureWith a focus on scale and the cloud, the SharePoint app model provides developers with a framework for creating different types of apps that can run in different environments. Apps that don’t have any server side code and rely on JavaScript and HTML only can be deployed directly to the server still, but apps that require complex logic and server side code can now run remotely. This could be on IIS, in Windows Azure, or any other web server at all. The app model provides a framework where an app can be registered with SharePoint so that the platform can manage permissions and access, and through the user of open protocols allow access back to that data.The communication in this model is two way and not just designed to allow remote apps to read from SharePoint – apps can push data back in to SharePoint, and SharePoint can push notifications of events in to your apps. This level of connectivity allows for the creation of more practical and meaningful apps that can solve more real world solutions.
  • Apps for Office architectureWhen apps for Office are installed in a desktop client, the HTML and JavaScript is run in an isolated Internet Explorer runtime process that ensures isolation and performance management for apps. The JavaScript API that is provided to the apps is passed through a transport framework within Office that translates the JavaScript function calls in to native code calls that execute within the Office application. The framework then translates any result set back in to an appropriate JSON based response to be loaded back in to your app.
  • Office web apps architectureAs the Office Web Apps output is HTML, the integration of apps in to this model is a little simpler. Apps are presented within an iFrame that uses the sandbox attribute that was added to HTML5. This will ensure that the JavaScript of the app doesn’t inherit the ability to do more than it was allowed to do in the limited runtime in the desktop by enforcing restrictions such as not being able to create modal dialogs, limited access and use of cookies, and no access to anything happening in the parent window. In this case the JavaScript calls that are made to the Office APIs are translated in to commands that the Office web apps platform can translate and then the results are returned.
  • Tooling optionsGiven the nature of the new apps and their use of HTML and JavaScript, the options for building out the core of an app can look beyond the Microsoft stack. The apps themselves are based on the same approach as a WSP package in SharePoint in that you create a CAB file with a different file extension, so can be built anywhere if the environment is set up right. That being said, there is some impressive tooling in the Microsoft arsenal. Visual Studio 2012 has extensions for creating, building and packaging apps for Office and SharePoint.There is also a new web based tool code named “Napa” that is used to create SharePoint hosted apps for SharePoint as well as Office apps. Napa is itself a SharePoint app that is designed to run in Office365, allowing the developer site to be used to create apps without the need to use Visual Studio.
  • App components hosted within SharePoint - Web scoped feature elements - JavaScript in hosted pages to manipulate the API, authentication is managed by SharePoint so no oAuth neededApp components hosted remotely - Run anywhere and do whatever can be done on the hosting platform you choose - The client side API framework allows communication back to SharePointCombine the two - The two aren’t mutually exclusive, you can use elements from both
  • SharePoint hosted apps - No thought needed to a hosting strategy - Limited to JavaScript to manage API calls - Easiest to start working with, the most limiting for functionality though - Watch out for the update processAutohosted apps - Give automatic remote hosting to Office365 apps - Based on Windows Azure web sites and SQL databases - Multi-tennancy for free, trusts are set up for you when the app is installed - Billing for azure components is the responsibility of the user - Not yet being accepted on to the app storeProvider hosted apps - Most flexibility to do whatever you want, but most responsibility - Need to manage multi tenancy yourself - Need to manage trust between your site and your app yourself too
  • Understanding limitations - Known issues with where custom actions will and will not work, such as the main site settings page being off limits, but ribbon buttons in a document library can be done - Known issues with where images can be stored and used in ribbon customisationsUnderstand what limitations come from client side code - Asynchronous by nature, so you need to code to that - Not all objects exist in the client APIs, such as farm and web app objects, so check first to see if what you want to code has an appropriately usable client side API
  • Well as any SharePoint MCM would tell you the answer is ‘It depends’Really there are two option.. Office StoreThe first option is the one you may have already heard about, the Office StoreThis is a public store available to every user of Office 2013, SharePoint 2013 & Office 365 where they can shop for apps for Office, including apps for Office and SharePoint (and my favourite Project Server).App CatalogSome things won’t fit in a the Office Store, maybe they are apps you have built specifically for your organisation, maybe they have IP you have developed and don’t necessarily want to share. Perhaps more likely you don’t want to use the commercial store, so you can use the App Catalog…Network DriveWell there is a third option too, the network drive for Office 2013 apps, but we’re not going to cover them todaySo let’s look at each of the main options in a little more detail….
  • Target Audience / who can get to itThe corporate catalog is focussed internally early, meaning you need to have an account on the SharePoint farm or 365 instance where it resides. The primary purpose of the catalog is for distribution of internal apps, for example LOB, things with IP that you may not wish to offer to consumers. The corporate catalog is also useful for SideLoading commercial apps that are in development and not yet available in the app store, you can host the apps locally and have the same experience as you would from the store, without that initial acquisition / Add It.The Office Store on the other hand allows anyone who has access to it to download and acquire the app, Where the app is available is up to you, as we’ll see a little bit later, but effectively count on everyone getting to see and potentially download / buy the app. LicencingThe Office Store has an inbuilt licencing engine that you can leverage to determine when trial have expired, or when more users than have been licencned are using the app, with this you can then hook in your business rules to restrict / inform the users. With the App Catalog there is no licencing engineCommerceAs you would expect, the CC does not have any concept of a commerce engine, afterall it’s primary use is internal, but you still have access to the internal licencing mechanism and can audit / limit who has the ability to install the app if you wishThe Office Store on the other hand does have an in built commerce engine, allowing you to set a price which MS will charge the customer for the app. The price itself is dictated by the licencing model you have chosen and can range from pocket money prices per user, upto very expensive for a site licence. Here is another important consideration when picking the price, if it’s small pocket money priced, people will be tempted to try it out, afterall what do they have to lose. If it’s really expensive, well I would suggest that is less likely, but you could mitigate that with a trial or similar process.HostingOut of the box the corporate catalog is not configured, it’s up to you to go in and do a bit of setting up for it to start working. In 365 this is as simple as clicking in an option and creating a site collection. The Office Store on the other hand is hosted by Microsoft and scaled accordingly. All you need to worry about is clicking on the SharePoint Store link in the app to get to it. ValidationGiven it’s primary use is internal, well as you’d expect its up to you to validate what is uploaded is tested and working as expected.Office Store is a whole other story. As MS are offering this to a global audience, they want to make sure it meets some minimum critera, so they do some significant validation which we’ll look at later on..RegistrationIn order to use the office store, you need to register, with the App Catalog, you don’t 
  • The process of getting an app into the store falls into four stepsSet up the Seller DashboardSubmissionValidationApproval
  • Before you can start uploading your app to the Office Store you need to get a Seller Account on the Dashboard set up. Now depending on whether you will be offering commercial (paid) apps or free apps this can vary in the amount of involvement required.Type of AccountDepending on whether you are submitting apps as an individual or a company, there are different requirements for signing up. Payout informationIf you are offering a commercial app that will be charged through the app store, then you need to provide payout info. MS will take a clip on any sale, but the remainder will come through to either your bank account or paypal. Once you have provided the above you submit your sellerdashboard account for approval and validation.Dev AccountOnce it comes back, all you need to do before you can start submitting apps to the store is to associate a paid n Office 365 dev account.You can get one of these with an MSDN Premium / UltimateYou can create a Dev Site Collection in an E1 / E3 tenantYou can sign up for a trial and get one - $99 for the year.
  • Now I want to back up a bit, whilst you need to have you app validated before it’s accepted to the store, looking at the validation policies that late in the game probably isn’t a wise thing to do, instead you need to be across these policies before you even start coding.Apps provide value to the Office Store customer Must be unique, not unfinished and do what you say it doesOffice Store apps can display certain ads You can put apps in there, but it shouldn’t be the primary purpose. They have policies around apps.Apps can sell additional features or content through in-app purchases Need to support PCI DSS for credit card payments, need to roll your own in app purchase mechansimsApps behave predictably Does what the user expects it to do, doesn’t crash, secure, doesn’t do things the user wouldn’t expect, browser supportApps put the customer in control Transmit data without user permission, secure, popups etcApps are appropriate for a global audience No adult content, threatening, profanity etc.Apps are easily identified and understood Manifest correct, screenshots, etcApp updates must not decrease your app’s functionality Can’t take away functionality between releases, if you go from free to paid, free users need the same functionality they had beforeRefunds If a customer needs to be refunded, it’s coming through to you to payApps utilize supported capabilities No unsupported features or capabilities.No autohosted featuresYou can read all of them at the url at the bottom.
  • Dev CompleteYou have completed the dev, all features are built etcTested the appThe app has been fully tested on premises, Office 365, all features are working as you would expect.Check the Validation policyYou should know this inside out. IconsIcons need to be the correct size and the icon you will submit to the store needs to match the app itselfMarketing CopyWhen you submit to the store, you need to provide marketing copy. Get this reviewed and approved before you submit as it can take time to get completedSupport & Privacy LinksYou will need support and privacy statement / links which will be linked from your app marketplace page.ScreenshotsYou need to provide at least one screenshot. Make sure these sell your app and are accurate. Some of them may be used in a featured app carousel.Microsoft submission guidelinesMicrosoft provide a set of guidelines to streamline your submission at Read them.
  • All Supported BrowsersMake sure you test against all supported browsers (IE9,10, Firefox & Chrome). Safari not necessary, but remember they can still use it. IE 8 not necessary if you state it. Make sure what you build will work in all browsers… Does what you sayIf you say it will provide a progress indicator in the app, or the merchandising, make sure it doesProvide feedback to usersLet the user know things are happening. If your publishing all projects in Project Server, let them know you are..Icon SizesDon’t get pinged for submitting app icons that don’t match between merchandising pages and appAsk for the permission you needYour refactoring code and no longer need access to permission x. Make sure you remove it from the app manifest.Tester notesIf your building something complicated, make sure you provide detailed tester notes Other things to be really careful ofRemoving / retiring - capability 90 day ruleChanging pricing from free to paid
  • Demo of an app submission, walk them through the process of submitting an app.
  • The Validation ProcessSLAAt the current time, it takes about a week to validate, but there is no hard and fast SLA for approval. Go Live DateFirst TimeAnalysis & Human TestingTester notes are reallyreally important.
  • Of course now the app is out there, you need to continue to innovate, to add new feature and capabilities. Or you may need to implement bug fixes, so it’s important you need to know how to update and maintain your app
  • IMAGE CREDIT- your appDownload Numbers & MetricsProvides simple metrics for the number of downloads , users, uninstalls etc. Quite useful, but has it’s limitations around historical data Only holds two weeks of weekly info, then aggregated. Accessible via the Metrics tab on the sellerdashboard.Good to see if your users are having problems, push marketing campaigns.Could use Google Analytics – only really good for monitoring installations and sites it is used on, need to be careful of privacy considerations and cookie laws. Data can also be slightly suspect as some organisations will block google analytics.Logs / TelemetryYou could build you own telemetry into the backend, certainly something that is simpler if you are using Off Box hosted apps. Provider Hosted can give you access to the logs.Support Forums / Feedback – Provide dedicated feedback forums. Really consider setting up UserVoice forums to get feedback and suggestions from your users. We have chosen to implement this in NW for Office 365 to give all customers the opportunity to log feature requests directly to the dev team, we can also then give them updates on their requests.Reference DeploymentsHaving SharePoint and different Office 365 tenants that you can monitor / test against. Did April CU break my app?
  • Do you need to update your app?This is the first and most important question, do you really need to update the app. If you app is using the Hoster Provider model, then you don’t necessarily need to update any of the local components, only the stuff that is off box. With this approach, you can simply update these components without needing to update the SharePoint components. The great thing is you can deploy the changes without having to go through the resubmission / validation process and all that entails.For autohosted apps, you don’t have any choice, you need to update all components and resubmit (when the app store accepts them) Takes up to 24 hrs to Prompt for UsersWhen you deploy a new updated app, remember it’s not immediate, it can take up to 24 hours for the user to be notified that there is an update available. By default, SharePoint checks every 24 hours for updates to installed apps. A farm administrator can set this to another value by using the following SharePoint Management Shell command, where n is the number of hours between checks.Set-SPInternalAppStateUpdateInterval -AppStateSyncHours nIf the value is set to 0, then the check is made every time the built-in timer job Internal App State Update executes, which by default is every hour. Farm administrators can use Central Admin to change the frequency of the timer job or run it immediately.Updates are optionalA really important consideration whenever you update your apps is that the updates are optional. There is no capability to force the user to update their apps. What this means that if you are changing API’s that you app may use, you need to support the original version and the new version concurrently. This makes designing up front very important, it also means you should give some serious consideration of whether you do a completely provider hosted solution and simply have a pass through to it.Treat it like a new appEvery app you submit should be tested / debugged if it were a brand new app. Remember, some people will be installing your update as if it were the first installation, so you need to ensure the out of the box logic and update logic behaves as it should. If there are multiple updates, you need to test updates from each of those version to the latest. Do not underestimate this overhead when developing and deploying.
  • Updating an app can be very complicated, as we mentioned before different versions of your app may require different files, different assets, different permissions etc. So each time an app is deployed to the corporate catalog, or submitted to the office store, it’s important that the mechanics for updating are in placeLuckily the app model has taken this into account and the app structure that Brian took you through earlier can be leveraged for updating. App ManifestThe app manifest is used to define the version of the app, some key metadata and what the permissions the app requests (access to lists, access to projects etc) and pre-requisites – perhaps you update app now requires a certain feature to be turned on in the farm, well you can define this in the app manifest.App Web ComponentsThe SharePoint components are a single web scoped feature, so all you need to do is update the feature. The app feature manifest can be configured with VersionRange attributes to define which files etc should be used for which version of the app you are upgrading from for the subsequent app updatesHost Web ComponentsThe host web only holds custom actions (ribbon, ecb’s) and app parts. You just simply update the new host web components and they are applied automatically by SharePoint.UpgradedEventEndPointThere is an event you can call when an upgrade happens to perform custom upgrade processing…Can use this if you use an InstalledEventEndPoint maybe you have a custom database that needs an additional column that needs to be computed, the event can have code hooked up to it to do that custom calculation. Of course, remember you need to have rollback logic in the event should the update fail.Remote ComponentsFinally, if you have remove components you need to update them, again taking into account that some users will hit your remote components with older version of the app, so it needs to support both…
  • DEMO NOTESVisual StudioOpen up Visual Studio and the projectUpdate the manifest file to that you can update the pre-requsitiesApp Web UpdatesSelect the feature, choose the manifest. Show the manifest version and the VersionRange bitsSay about having different versionranges for different upgrades
  • The SharePoint 2013 App Playbook - Your Guide to building and publishing a great app

    1. 1. Brian Farnhill Independent Consultant Alexander Burton App Author
    2. 2. App Web App Web App Web App Web App Web App Web IIS and other web servers REST, JSON, oData, oAuth
    3. 3. Office Host Application Internet Explorer runtime host process App App App App App App Message Transport Apps for Office runtime
    4. 4. Office Web App Iframe <iframe sandbox=“”></iframe> App
    5. 5. • •
    6. 6. Provider hosted apps Auto hosted apps Flexibility and responsibility Simple to implement hosting App Web Used for SharePoint hosted apps Optional for remote apps Remote APIs
    7. 7. Task Pane Content Mail
    8. 8.
    9. 9. Office Store App Catalog Audience Public Users with access to SharePoint Licencing Yes No Commerce Yes No Hosting Microsoft Site Collection Validation / Verification Microsoft SharePoint Registration Yes No
    10. 10. ApprovalValidationSubmission Set up Seller Dashboard
    11. 11.
    12. 12. us/library/office/apps/jj220060.aspx us/library/office/apps/jj163230.aspx
    13. 13.