Pressure is on and more and more companies are moving to SharePoint Online for the intranet and extranet and whatever else they have running in their server room. So, Few people asked me, what is the difference between developing apps versus on-premise solutions. The short answer is , a lot and since this is not really a helpful answer I will start a long list of gotchas and will add to it as I go along
In here we’re discussing SharePoint Hosted apps just to be clear.
-When you delete an app which has been installed on the site – your app site gets deleted too … so if you stored some data in the app site and you find it valuable – make sure you backup that data first. This is different from Sandbox or Full Trust solutions in a way when you delete the solution lists and libraries created by that solution live on unless you redeploy the solution and chose to overwrite the list. Not so with apps.
-You can create custom workflows and even build those in Visual Studio, not only in SharePoint designer but those will have to use only out of the box actions available, you can’t create your own workflow actions and deploy them you have to play around with what’s configurable out of the box
-Out of the box approval workflow can be added to any of the lists on the app site but initiation or association form will not load for the list so basically you can’t initiate a workflow.
-You can’t connect and edit the apps site created with an app – you just get an error. This is probably a limitation in SPD (they probably don’t want you to ruin the app site or find out how it works ;)) but nevertheless
-You can’t provision your site template as an app similar to what you can do with Sandbox solutions
You own apps versus apps you bought in the app store
-There are certain things which you (as an app) can’t do if you’re in the app store. One of which being that app that is being sold in the app store can’t have Full Control on the parent site – this is actually a huge limitation in a way that app store apps will never (unless MS change it) have a full potential capability of the app that has been developed by a dev and uploaded to the corporate catalog.
Pages and other Assets
-Page, CSS, JS, Image, MasterPage etc provisioning to the parent site using the app involves hacks and not really robust
App Parts – they’re kind of like web parts but not really
-App parts that you build run in an iframe on the page, so it’s not like you can emit some CSS, JS, or HTML that will have access to the parent DOM
-For the same reason as above, you can not style or add JS interaction to app parts by adding your styles or JS to master page since those run in an iframe of the app site and therefore are not really inheriting your master page for the main site
-If elements on your app part take a certain space, and you place the app part on the page which has a limited space – you will end up with scroll bars in the app part because – yes, you guessed it, it’s running in an iframe. This is a huge issue for example if your app has a flyout (for ex a menu) and typically a flyout would fly over other elements on your page – well now that it’s an app part – you can’t – it will just be flying in the constraint of the iframe.
-You can’t really take a third party app part and “wrap it” and pass parameters dynamically. This is my favorite thing to do with we parts that is not possible with app parts. You can wrap a third party web part into your own with a purpose of feeding parameters to web part. This is helpful for example when you have a weather web part that has a web part parameters passing the location name but you want to dynamically pass that data at the time of rendering. You could just wrap a web part in your own custom web part and do that logic – doesn’t work like that with apps parts – it just doesn’t.
-App parts can’t be placed on a master page like controls. So traditional web parts are just user controls or web controls wrapped in a magical web part wrapper which means that you can hardcode your web part into masterpages so that users can’t remove them – there are few valid cases for this. Well, you can’t do that with app parts.
-App pages are not web part pages, so users can’t edit the app home page and customize what they see there. Once you define the app landing page – it is what it is.
More to come, stay tuned …