Yesterday, SharePoint MVP and Chief Architect at AvePoint Jeremy Thake presented The App Building Playbook for the SharePoint 2013 Marketplace, a highly instructive session in the developer track at SharePoint Fest D.C. Jeremy explained that the purpose of his session was to discuss "how to leverage the platform to build your solutions" for the SharePoint marketplace. Microsoft approached AvePoint early on, inviting them to build an app or two for the 2013 marketplace, and it's the experience of fulfilling that request that Jeremy drew upon to share his insights in his presentation.
In SharePoint 2013, Jeremy showed that Site Contents now has a listing for Lists, Libraries, and Other Apps, pointing out that the phrasing of which seems to imply that, for example, document libraries are now considered to be apps. Jeremy said that he and AvePoint pushed back to Microsoft on this early on, arguing (quite rightly) that it was confusing, but alas, those arguments were to no avail.
After clicking on Add an App, Jeremy pointed out that, "on the left-hand side, in the Quick Launch, very hidden, is the SharePoint Store link." Jeremy stated that, to date, "the adoption of the Store has not been widespread," pointing out that in the over a year its been available, the Nintex Workflow app, for example, has garnered all of two ratings. While looking at the page, Jeremy noticed that Microsoft has now removed the notation of how many downloads a given app has seen. Explaining that the pricing model in the marketplace is currently a per-user fee, but that a "subscription model is coming," Jeremy cautioned would-be app developers that "it's been coming for 18 months." Jeremy went on to demonstrate that, having added a free trial of an app, and confirming that you Trust It, once installed, a user can't open the app directly from the confirmation screen, but must navigate to the app. Consequently, Jeremy explained that, in essence, "a SharePoint app is a special kind of subsite."
Jeremy warned that the "submission process is a little bit challenging," and said that it will be harder for smaller vendors to establish trust for their apps, at least until such time as there are robust reviews and ratings from the SharePoint community in the Store.
Explaining that there are two approaches to app design (with a third being a subset of the second), Jeremy listed them as being SharePoint-hosted apps, and cloud-based apps (which come in the flavors of provider-hosted apps, or Azure auto-provisioned apps, which is where the "third" approach comes into play). The key difference, Jeremy said, is that "when I go to [a non-SharePoint-hosted mode] ... we can have components outside of SharePoint." "There are some limitations to the provider-hosted model" to familiarize yourself with, and the Azure auto-provisioned approach is, by default, available only to Office 365 users. Versioning challenges also come into play when developing a provider- or auto-hosted app. Jeremy cautioned that developers must plan ahead for such versioning-related issues, as versions can become out of sync (and potentially break for users until they upgrade). Furthermore, Jeremy said that the SharePoint app upgrade process is not transactional, which also adds concerns regarding versions going out of sync.
A few more things to be aware of when developing cloud-based apps: you'll need to be able to handle old, Microsoft-issued OAuth tokens on your own within the app; if you ask for tenant-wide access, you can't list that app in the store (it will have to be "side-loaded via the app catalog"; and the same restriction applies to wanting to grant users full control.
Jeremy explained that the three customization packaging and deployment options are:
- Full trust, which "allows you to deploy directly into the SharePoint hive." (On-premises only; no marketplace; and no OAuth; but the "deepest, nicest" UI integration.)
- Sandbox, which is partially trusted. (No marketplace or OAuth; available on-premises and online; and provides UI integration.)
- SharePoint apps. "You can manage licenses specifically" in apps, which is a "good way of controlling where your business apps can be deployed." This is the Microsoft-preferred option, and offers the best overall experience. (Marketplace and app catalog; on-premises and online; OAuth; but restricted UI integration.)
Jeremy mentioned that there is currently no way to upgrade from the full trust or sandboxed method to a SharePoint app, however.
Touching briefly on the SharePoint Store submission process, Jeremy discussed the validation policies and the checklist that is provided to developers.
Wrapping up with a couple of demos, Jeremy first showed AvePoint's Task and Calendar Sync app which is available for free in the Store, and allows users to sync SharePoint task lists and calendar lists with Outlook. The app is a SharePoint 2013 app package, and uses Azure Web, SQL, and Worker roles. Jeremy mentioned that it also "scales really well."
Jeremy then demonstrated the AvePoint Meetings app, which provides meeting tracking capabilities. There is "no Worker role" for this app, and the "majority of data is stored in SharePoint." Jeremy said that "all data are created as list entries in SharePoint," but that there are tradeoffs to consider when doing this, such as how heavy the use of SharePoint platform/lists is versus using SQL instead.