The name “apps for SharePoint” is changing to “SharePoint Add-ins” & its official ( Any references to the app with-in the SharePoint eco-system will now be termed as Add-in. This is not limited to SharePoint but also Office.

But why this change? Some reasons we get from experts,

  • Microsoft’s multi-platform support of Office client across the Windows/Mac, iOS, Android and Windows 10 environments ended terming the Office client as “apps”, and so having “apps” within “apps” was causing confusion
  • Microsoft received multiple feedback that “apps” weren’t working in the enterprise space who were building something that was valued at much more than a simple app.

The notion also needed to be consistent here with the name change across both Office & SharePoint for the Office Store perspective.

Whatever may be the reasons, we just need to update our pointers from Apps to Add-ins. Below is the table that might help you to do that.

Original name New name Applies to
apps for Office Office Add-ins Office
mail app for Outlook Outlook Add-in Office
app for Excel Excel Add-in Office
app for PowerPoint PowerPoint Add-in Office
app for Word Word Add-in Office
apps for SharePoint SharePoint Add-ins SharePoint
app part add-in part SharePoint
app web add-in web SharePoint
SharePoint App Model SharePoint Add-in Model SharePoint
SharePoint Hosted App SharePoint Hosted Add-in SharePoint
SharePoint Provider Hosted App SharePoint Provider Hosted Add-in SharePoint

For any existing app you have developed & deployed, to update the app, you use the same product ID in the app manifest that you used for the original version. The version number in the app manifest should be greater than the version number of the original app or the most recent update. Within 24 hours after you upload your update to an organization’s app catalog, and within a week of uploading it to the Office Store, a notification that an update is available appears next to the app’s listing on the Site Contents page of every website where it is installed.

When you are developing an update, you don’t want to wait 24 hours every time you upload a new version to your test SharePoint app catalog.

  1. After the latest update is uploaded to the app catalog, open the Site Contents page on the website where the app is installed and choose the button on the app’s tile.
  2. On the call out that opens, choose the About tab. On the About page that opens, there is a notice that a new version is available.
  3. Choose the Get It button. The Site Contents page reopens, and there is a notice on the apps’s tile that the app is being updated.


Image Source: msdn

Why it takes 24 hours for an app to update is because 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 n

If 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.

​There are three types authorization policies in SharePoint 2013. This post explains what each of this means and where exactly these are used.




This was the policy which was there in 2010 too. Whenever your code gets executed, only the user permissions are considered. If the user have the rights to do what the code have to do, it executes fine. There is no other authorization required.


User + App:

As you start coding your SharePoint apps, you will come across the terms like App Manifest, App permissions etc.,  where in you mention certain permissions your app needs to execute the code it contains. Some of such permissions levels are (Read, Manage etc,). In this case, when your code gets executed, the app should have the required permissions & also the user whose context the app is getting executed should have the same level of permissions.

For example, in case your app is trying to update an item in a list in your host web, your app may have Write permissions  but if your user is having only Read permissions your code will not execute & vice-versa. So both your app and the user should have Write permissions for the app to work.

To put it simply both your user context and app context are taken in to consideration here.



If at all a timer job can be made possible for SharePoint online, then it’s using this authorization method.

This method allows you to execute code even if the current is not having the required permissions. We will not be able to elevate/provide every user the required permissions. But we need to perform an action that the user is not entitled to. People always consider this as a replacement for RunWithElevatedPrivileges in farm solutions. But it’s not. This is not same as RunWithElevatedPrivileges. RunWithElevatedPrivileges still takes the current user context in to consideration. But in this case we ask the app to totally ignore the user context.  This is done by adding the property AllowAppOnlyPolicy=”true” to your app manifest file. Below will be the permissions you will see in the manifest file.

<AppPermissionRequests AllowAppOnlyPolicy=”true”>

<AppPermissionRequest Scope=”http://sharepoint/content/tenant&#8221; Right=”Manage” />


In general, a current user is required to be present for a call to be made. In the case of app-only policy, SharePoint creates a SHAREPOINT\APP, similar to the existing SHAREPOINT\SYSTEM user. All app-only requests are made by SHAREPOINT\APP. There is no way to authenticate as SHAREPOINT\APP through user-based authentication.

Since app-only calls effectively does what a user is not meant to do , you should be conservative in creating apps that ask for permission to make them. Calls should use the app-only policy only if:

  • The app needs to elevate its permissions above the user for a specific call; for example, to approve an document under conditions evaluated by the app.
  • The app is not acting on behalf of any user; for example, an app that performs nightly maintenance tasks on a SharePoint document library.

2014 in review

Posted: December 30, 2014 in Uncategorized

The stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 97,000 times in 2014. If it were an exhibit at the Louvre Museum, it would take about 4 days for that many people to see it.

Click here to see the complete report.

With “Apps” being the buzz word in SharePoint 2013, and if you could have started developing apps, you could have noticed that your App.js file starts with a statement as below:

“use strict”;

App.js enables you to access SharePoint objects using ECMAScript & the version being used is ECMAScript 5. ECMAScript 5’s strict mode is a way to opt in to a restricted variant of JavaScript. Strict mode is a way to introduce better error-checking into your code.

Strict mode makes several changes to normal JavaScript semantics.

  1. Strict mode eliminates some JavaScript silent errors by changing them to throw errors.
  2. Strict mode fixes mistakes that make it difficult for JavaScript engines to perform optimizations: strict mode code can sometimes be made to run faster than identical code that’s not strict mode.
  3. Strict mode prohibits some syntax likely to be defined in future versions of ECMAScript.


Below are the most important restrictions when you use strict mode,

  1. Using a variable without declaring it
  2. Writing to a read-only property
  3. Adding a property to an object whose extensible attribute is set to false
  4. Deleting a variable, a function, or an argument
  5. Deleting a property whose configurable attribute is set to false
  6. Defining a property more than once in an object literal
  7. Using a parameter name more than once in a function
  8. Using a future reserved keyword as a variable or function name
  9. Assigning an octal value to a numeric literal, or attempting to use an escape on an octal value
  10. The value of this is not converted to the global object when it is null or undefined
  11. The string “eval” cannot be used as an identifier (variable or function name, parameter name, and so on)
  12. You cannot declare a function inside a statement or a block
  13. If a variable is declared inside an eval function, it cannot be used outside that function
  14. The string “arguments” cannot be used as an identifier (variable or function name, parameter name, and so on)
  15. You cannot change the values of members of the local arguments object
  16. “with” statements not allowed

Note : Browsers not supporting strict mode will run strict mode code with different behavior from browsers that do, so don’t rely on strict mode without feature-testing for support for the relevant aspects of strict mode. Strict mode code and non-strict mode code can coexist, so scripts can opt into strict mode incrementally.