Microsoft server-based technologies are .NET under the hood. That's especially beneficial with SharePoint, which is a .NET code generator that provides a .NET environment within which custom apps are easily hosted.
This feature, which Microsoft calls Apps for SharePoint (formerly Web Apps for SharePoint) reduces in-house application design burdens considerably. Placing code within Apps for SharePoint relieves the app designer from having to code from scratch workflows, metadata access and usage. A custom app can access the existing SharePoint code for that functionality without extra effort. As a result, for example, any app that requires workflow (routing of messages generated by the app to and from Exchange) can be developed much faster. SharePoint handles the user interface (UI), data layer, security and administration of the app. The only piece to worry about is truly custom code.
The app programming model we know and love
Placing code within Apps for SharePoint relieves the app designer from having to code from scratch workflows, and other items.
(A strength of the model is broad native client support, including not only Windows but also iOS and Android, which bodes well for mobile SharePoint deployment of custom apps. This development has kinks, but it's part of the Microsoft roadmap.)
Conventional .NET apps may be accessed by Web services and connected internally via a number of methods (APIs, REST, and so on) and this is true of apps for SharePoint as well. And the model supports OAuth 2.0 to make third-party access easier.
Customizing the cloud
This gets tricky with Azure, which has its arms wide open to receive SharePoint now. Microsoft is pushing SharePoint in the cloud hard, and there are clear economic benefits and functional convenience to cloud-based SharePoint. But what are the cloud-based consequences for Quick Apps for SharePoint?
Another consequence is that a variety of hosting options are enabled. The app may either reside completely within SharePoint, or in Azure and access SharePoint components (Web parts, lists). With the former, the model makes it easy to add custom actions to the standard SharePoint user interface.
Integrating with Office
For more on SharePoint
Team sites break down silos
SharePoint 2013 and social media
SharePoint 2013 guide
Finally, any extension of Apps for SharePoint into the cloud must acknowledge Microsoft's push to fully integrate SharePoint with the Office suite, and to that end, the new app development suite Napa Office 365 is now available. In the spirit of SharePoint Designer, these tools let nontechnical users rapidly configure and deploy cloud-based SharePoint apps that handle Office files (Word, Excel and the like), mail, and so on. Take note that such apps will be limited in functionality and scope, but even with these limitations, Napa makes cloud deployment more attractive.
Apps for SharePoint drawbacks
Note that the apps you can build and deploy with this model and these tools must live on the user side of things: The apps being described here are UI-centric, doing fairly conventional storing and retrieval of content management system objects. Anything complex enough to require server-side code won't work.
Moreover, while OAuth makes authentication easy on the front end, SharePoint-hosted apps will have a much harder time tunneling to other back ends: Active Directory Federation Services (ADFS), for example, won't work.
This is frustrating, given SharePoint's embrace of OData for agnostic source connection (which you're locked into, but that's not necessarily a bad thing) because the lack of ADFS offsets the ease with which foreign data sources can be mapped to the app.
All in all, it's a mixed bag, but the strengths outweigh the weaknesses. SharePoint Online has come of age. And while you can't go quite as far in custom apps in a cloud deployment as you can on-premises, you can still go a long way.
This was first published in November 2013