All About Sitecore Mobile Development


Almost every major organization now has a significant online mobile presence in order to better interact with their audience. To Sitecore’s credit they have been very forward thinking within the mobile space since they have anticipated this trend and added core functionality to Sitecore in order to help with mobile development. This post takes a look at some of Sitecore’s built in mobile development features and compares them with responsive web design (RWD) which is a design methodology that is gaining momentum within the web community.

I want to be clear that I am not advocating the use of responsive web design over traditional Sitecore mobile development, but rather, to take example from WebCreationUK and identifying the advantages and drawbacks to each approach so that we will all be in a better position to choose the correct approach for a particular client or project. It is a very good position to be in when you are able to look at mobile development from multiple angles instead of always applying the same approach regardless of the overall business objectives for a project. I don’t mean to spoil any of the upcoming surprises but there are certainly cases when a hybrid approach that combines responsive web design with Sitecore’s built in features may lead to the optimal solution.

This post also takes a look at how bv02 is improving the responsive design experience within Sitecore by using some of Sitecore’s built in features to mitigate the pitfalls that are present in any responsive design project.

Traditional Sitecore Mobile Development

Sitecore has built the concept of devices into their core product. The idea is that different layouts can be applied to different devices. So you can create a “desktop” device, a “tablet” device, a “mobile” device, a “RSS” device, etc, and then apply different layouts to each device. In order for this concept to be effective, most implementations rely on some sort of device detection. This can be done through the implementation of a 3rd party device detection library or the Mobile Device Detector module available in the Sitecore marketplace.

While device detection has its drawbacks it does allow for some things that responsive web design cannot. For example, device detection can target specific mobile devices and can detect the presence (or absence) of particular features such as touch enabled devices.


  • Result is an adaptive design (some prefer this over responsive design).
  • If just mobile and desktop devices are implemented then it could be more time/cost effective than RWD.
  • Will deliver just the markup and images you need per device. No unnecessary JS, images, HTML as with RWD.
  • Can customize layouts per device. Ex: Different layouts for iPhone, old Blackberries, Touch enabled devices.
  • Can deliver a very tailored design for each device contrary to RWD which does not allow for exact designs since they are fluid.


  • Multiple layouts/renderings per page means not all one codebase
  • Relies on device detection (likely through 3rd party libraries) and may not be 100% effective
  • Cannot be certain layouts will provide the best experience for a specific device depending on device’s screen resolution

Responsive Design with Sitecore

In general, responsive design is independent of the CMS that it is implemented on but there are always subtle differences and quirks to figure out. The challenge for a Sitecore developer is to figure out how to best leverage Sitecore’s built in features in order to create a better responsive design.


  • Designed to fit any device
  • Does not rely on device detection
  • Only one layout per page means one codebase


  • Will deliver all markup and images to page regardless of device. Could result in longer wait times on mobile devices
  • RWD can mean A LOT of extra front end development time
  • Can’t target specific devices. Only differentiation is browser/screen width

Mix and Match RWD with Sitecore Devices

One exciting prospect is that the use of responsive design and Sitecore devices are not mutually exclusive. There are situations where responsive design can be used effectively in conjunction with Sitecore devices (and/or device detection). A good example would be a very large site where RWD would be used on the majority of pages in order to delivery a mobile solution, but specific and important pages (like the home page, sales pages, ecommerce checkout pages) would use device detection and Sitecore layouts to create a very tailored mobile experience for users.

How is bv02 Improving Responsive Design in Sitecore?

In order to improve responsive design within Sitecore we started out by identifying the most problematic issues. It is worth noting that the issues we took into consideration were not solely Sitecore problems as they are problems that plague any responsive design, regardless of the platform.

The two most important issues that we decided needed to be addressed in order to provide a better RWD experience were:

  • Responsive design dictates that images may be rescaled through the magic of CSS to fit on smaller devices, but the images are always loaded at their full file size.
  • All markup and images are delivered to the browser on each page request regardless of the device. That means all HTML, JS, Images, etc are going to be loaded whether the user is on a desktop or mobile phone, even if some of the page elements are being hidden with CSS.

These two issues really make me angry. From my point of view, if we build a responsive site and don’t take care of these issues then we are not really delivering a very good mobile solution. These types of problems are not usually fully understood by clients, so they can easily be overlooked, even though they can have a significant impact on mobile solutions.

The good news is that both of these problems can be solved (or mitigated) by using some of Sitecore’s built in features.

How do we start? The first thing we need to do is detect the users screen resolution. That may not seem like a big deal but it opens up a world of possibilities once we have this information. Screen resolution can be detected either through JavaScript or by using device detection (and likely a 3rd party library that stores resolution information). I chose to implement a solution that detects screen resolution with JavaScript. The benefit of the JS solution is that it will work on any Sitecore solution as it can be dropped in without any dependencies (and hence better suited for release as a shared source module). The downside to the JS solution is that the resolution information will not be available on the first page request since JS is a client side language. However, the cookie can be stored for a period of time so that the resolution information will be available on follow up visits.

Once the device resolution is detected on the first page request, it is stored as a cookie and can be referenced on subsequent requests. The device’s screen resolution can be used as a guide to serve images at appropriate widths (and smaller file sizes). This helps ensure that users are not wasting precious bandwidth. The best part is that we can accomplish this by leveraging Sitecore’s image manipulation and image caching features to resize images as needed and cache them for later use. This adaptive images approach can be used as a good first step to mitigate the problems encountered with images within a responsive design framework.

We have packaged the adaptive images concept into a shared source module named Sitecore Adaptive Images which is available in the Sitecore Marketplace.

Now on to the second issue we wanted to solve. The problem is that all content is loaded on each page request regardless of the device. Even though some of the content in responsive design may be visually hidden through CSS, it is still being loaded on page requests and increasing the data that a user needs to download.

How do we solve our second problem? Detecting a device’s screen resolution can be used in conjunction with the Digital Marketing System (DMS) and the Sitecore rules engine to hide or show page elements with personalization and conditional renderings. The rules engine is a very powerful feature in Sitecore that we can leverage. By creating some simple rules we can detect, with a fair degree of accuracy, if a user is on a mobile or tablet device based on screen resolution. The final step is to use the DMS to apply personalization to the layout details of data templates. Note that this is only possible with the installation of the DMS, which is a separate product.

While this will probably never be able to entirely solve the problem of all markup being delivered to browsers, it will allow Sitecore developers to ensure specific markup/JS/Images are not delivered on every device. This means that especially troublesome page elements with large file sizes can be omitted on certain devices.

Different Content to Different Devices

While it may not always be a good idea to serve different content to different devices, there can be certain situations where it is useful to have this capability. This can be achieved fairly easily by following a similar approach as above. The DMS and rules engine can be leveraged to either show/hide conditional renderings or dynamically set the datasource for a rendering if the user is detected to be on a mobile or tablet device.

One thing to keep in mind is that the JavaScript method of detecting screen resolution might not be available on the first page request so it is not 100% reliable. If it is critical that every request (including the first) has access to screen resolution then you should consider using a 3rd party device library to implement a device detection strategy.

Future Work with the DMS

The next step we would like to address is extending the DMS to distinguish users in real time, based on their device’s screen resolution, so that they can be identified as mobile or tablet users. This will allow marketers to create engagement workflows based on devices, which is not usually possible when using a responsive design approach.

What About Native Mobile Applications?

Anyone involved with mobile development will quickly realize that traditional web-based solutions are not best suited to solve every business objective. We live in a world that is now largely driven by native mobile applications like iOS and Android apps and new mobile platforms are emerging at breakneck pace. Since Sitecore sees itself as an online hub that can be used to drive everything digital, they have recently released a mobile software developer’s kit (SDK) to help facilitate the development of native mobile applications. The idea is that content managed in Sitecore can be used in native mobile applications. Very cool.

In Closing

Sitecore has made some good decisions which has given them a competitive advantage in the mobile space. While it is great to have an understanding of Sitecore’s built in mobile features, Sitecore developers should not be afraid to expand their knowledge base beyond the walls of Sitecore. Mobile development is moving at such a rapid pace that it is hard for any organization, including Sitecore, to keep up with the changing landscape. By using new mobile techniques like responsive web design in combination with leveraging Sitecore’s already strong mobile offerings, developers can ensure that they are equipped with the right toolset to approach any mobile problem.

Skip to sharing

Comments are closed.