Skip to Content

Charting SAP’s mobile apps

SAP’s new mobile apps have been appearing in the new SAP app store rapid-fire ever since the mobile store was established in Oct/Nov last year.  I figured it’s time to take stock of what’s there, what’s needed to run them, and what they will run on.

In the diagram below I’ve mapped out each SAP app that I can find, whether it needs an add-on to be deployed to the SAP back-end, what SAP middleware products are required (if any), and what mobile clients the apps will currently run on.  In this blog I don’t attempt to describe what each app is trying to accomplish, for that I suggest you reference SAP’s own app store descriptions or published documentation.  Furthermore I don’t attempt to analyse or display the partner apps, rather I am more interested at first instance to see what the ‘mothership’ has bestowed upon us.

IMPORTANT DISCLAIMER: I cannot guarantee that this is table free from errors (in some cases I found it difficult to find appropriate documentation).   I can certainly guarantee that it will be out of date very quickly (such is the pace of change in the world of mobility).  Please perform your own research or consult your SAP representatives when assessing any particular mobile app. 

First impressions … this list looks quite impressive.  Especially when you turn the clock back 18 months (before the acquisition of Sybase) and there was a dearth of apps available from SAP itself.

If you are wondering, much of the data was extracted from SAP’s own documentation.  Links are as follows:

  • SAP’s app store can be accessed via various channels.  You can access it by downloading a dedicated app which is available on the Apple and Android mobile app stores.  Alternatively web versions are available in two flavours, one hosted in the EcoHub here and the ‘official’ one (powered by Silverlight) here.
  • A very basic documentation link for Mobile Apps for the SAP Business Suite is here.
  • SAP Mobile Applications Roadmap (last updated Aug 2011) document (requires S number for authentication) can be found here.


  • The diagram assumes pre-requisite licenses already exist with the customer.  So for instance the SAP HCM Interview Assistant requires that the customer is already using and licensed for the eRecruitment module.
  • Refer to the SAP documentation for specifics of which app-specific add ons are required for which app.  These are add ons that must be installed on the back-end system (eg. ERP).
  • I have marked a ‘?’ indicator where the available documentation is unclear whether the specific device support exists today, or whether it is in the roadmap.
  • The majority of apps relating to the SAP Business Suite require Sybase Unwired Platform version 2.1, as well as SAP NetWeaver Gateway 2.0
  • For simplicity reasons I have collapsed iPod Touch and iPhone device support into a single column.  Check the SAP documentation because not every app is supported for iPod Touch, and some apps list support for the (latest) iPhone 4S whereas others do not.

Observations (and opinions)

Looking more closely at the diagram, a few interesting observations come to mind. These are personal observations or opinions, not necessarily fact.  Lets discuss …

(i)  SAP NetWeaver Gateway powers the consumer-facing scenario, not Sybase Unwired Platform (SUP)

The SAP Citizen Connect app is a consumer facing app available from SAP which interacts with the SAP Business Suite.  It requires either a CRM or ERP backend, AND SAP NetWeaver Gateway.  This makes sense.  In my opinion SAP NetWeaver Gateway was conceived as an enabler to help SAP reach 1 billion ‘users’, and to do that it was architected for that in mind (arguments about Thoughts on NetWeaver Gateway aside).  SUP on the other hand was born in the Enterprise, and requires for instance device registration for connectivity (something that doesn’t easily scale to the consumer masses).  That is why in its current incarnation SUP is a MEAP (mobile enterprise application platform) and is not to be confused with a MCAP (mobile consumer application platform).

(ii)  For Business Suite customers, if you don’t have SAP ERP 6.0, you’re on your own

SAP has diligently architected products such as SAP NetWeaver Gateway to have the technical ability to connect to older SAP systems (eg. R/3 4.6).  Looking at the apps list however, you need to be on ERP 6.0 SPS15 at a minimum to take advantage of most of the Business Suite apps.  And for some apps (eg. SAP HCM Manager Insight) you need to additionally have Enhancement Package 4 installed.

(iii)  Middleware won’t save you from add-ons to the Back End systems

In a perfect world, one would like to think that REST-enabling middleware such as NW Gateway can provide a layer of abstraction to minimise any need to touch the back end system.  But from the diagram you can see that the majority of the Business Suite apps still require some sort of add-on (specific to the app) to be imported into the backend system.

(iv)  Can the app store scale to small development shops?

Given that relatively ‘simple’ apps such as SAP Employee Lookup require a back-end add-on as per my point (iii) above, one wonders how easily small development shops will be able to offer mobile apps if they find the technical need to have customers install ABAP code into the back-end systems.  Take it from me, SAP customers will willingly import code into their precious core systems if it comes from SAP itself, but are more reluctant when it comes to third parties, and much more reluctant if those third parties work from a garage.

(v)  Infrastructure demands – a bridge too far?

If you think the days of NetWeaver Mobile are over, think again.  Some apps (notably SAP CRM Sales and SAP CRM Field Services) utilise the DOE from NetWeaver Mobile in conjunction with SUP.  Partly this is a legacy of the architecture born from the original co-innovation work between SAP and Sybase which pre-dated the eventual acquisition of Sybase.  Note that these days SAP refers to the component ‘DOE’ rather than SAP NetWeaver Mobile, probably to avoid confusing customers with yet another ‘mobility’ middleware offering. But the bottom line is that today, if an on premise customer hypothetically sought to implement ALL of SAP’s Business Suite apps, they would need to run three major middleware products – SAP NetWeaver Gateway, SAP NetWeaver Mobile, Sybase Unwired Platform.  Adding Sybase Afaria for mobile device management makes that four.  If you don’t already have one you might need a reverse proxy in the DMZ (Sybase offers a ‘relay server’ which serves this purpose).  Multiply this number of servers by 3 if you run a basic Dev/Test/Prod set of environments.  For an on premise scenario, this is a bitter pill to swallow.  (Note: special thanks to Jason Scott for augmenting my thoughts on this topic).  On a positive note, it is possible to deploy your SAP NetWeaver Gateway system as an Opinions on Deploying NetWeaver Gateway to the backend system, saving you one set of servers.

I’ve argued since Random thoughts on Mobility and my wishes for TechEd Las Vegas 2011 that we need to see some hosted or On Demand offering for this mobility infrastructure.  Some SAP/Sybase partners are moving to offer this, but I believe many customers would like to see the service established by SAP/Sybase.  SAP are moving to provide an On Demand Portal offering.  I’m thinking that establishing On Demand Mobile middleware is strategically more important.

(vi)  On Demand customers can jump for joy

Speaking of On Demand, notice that (by definition) customers of the on demand solutions need not concern themselves with implementing any middleware.  Assuming they are licensed, then can simply download the relevant app onto supported devices.  To demonstrate the traction this has, if you look at the Apple app store and search for ‘SAP AG’, look at the apps which appear at the top of the list.  If you weren’t aware, Apple uses an algorithm to list the apps with the most recent downloads at the top of any search.  When I last looked both the SAP Business One and SAP Business ByDesign apps were in the top 5 for a search of ‘SAP AG’ apps.  You can also use this technique to get an idea of which of SAP’s apps are most popular based on download statistics.

(vii)  iOS takes the cake, Blackberry Playbook and Android get a bite

A quick glance at the diagram demonstrates that iOS (and in particular iPhone) rules the majority of the currently available apps.  What is more interesting is the solitary app for the Blackberry Playbook, the SAP GRC Policy Survey – and this is the only platform that the app is currently available for (based on the documentation).  Similarly SAP Transport Notification & Status app appears to be currently only available for Android, and no other platform.  The first version of the EAM Work Order app is available on Windows 7 tablets only.  One wonders why these particular apps were orphaned out to their respective platforms in such a manner – to prove the technology can technically handle these device platforms?

(viii)  Write once, deploy to all devices is not as easy as the brochure suggests

The App Store (Silverlight version) greets you with the mantra “Anytime, Anywhere, Any Device”.  Notice that even with the months taken to create these apps, the first versions of apps on the SAP store have been typically deployed for generally only one and on some occasions two devices.   Whilst SUP brochures promote the ability to develop and deploy apps to multiple devices, the ease with which this can occur is less clear.  When deploying for a particular device platform (eg. iOS), you often still need to do specific (and sometimes onerous) work to refine that app for productive use on that platform.  When dealing with native apps that ‘last mile’ work can be tedious, and not obvious when you see the ‘create an app in 15 mins’ demonstrations.  And in truth I don’t blame SUP for this.  Any technology that seeks to ‘produce’ native mobile apps for a wide variety of rapidly evolving client platforms is taking on a challenging task.  Some communities have attempted to approach the problem by focussing on HTML5 web apps and wrapping them in technologies such as PhoneGap.  Indeed I believe this is a key reason why SUP now ships with a similar concept in its The value of HTML5 in the SUP Hybrid Web Container, and why it also ships with the jQuery Mobile framework for use in the container.  As that evolves, we may see more apps shipped using that web container technology and supporting more device platforms simultaneously.  In this respect, I like that SUP supports the ability to deploy both native apps and mobile web apps wrapped in a secure container.

(ix)  Double check the app store specifications and requirements

In the course of my analysis I noticed discrepancies in how an app is listed in one of the app store channels versus another.  For example, the Sales OnDemand iPhone app appears in the Silverlight version of the app store, but interestingly I could not find it (at time of writing) in the iOS ‘SAP mobile apps’ app. The SAP Cart Approval 2.0 app lists ERP 6 as the required back end system in the EcoHub web app store, whereas the Silverlight store and iOS ‘SAP mobile apps’ app lists it as requiring SRM 7.0.  I also noticed that some apps are listed as supporting the latest iPhone 4S, whereas others do not … this could simply be due to a delay in updating the documentation.

The moral of the story here is to double check the details and technical requirements for an app with your SAP representative before you commit to it.

Also, be careful about how you read the SAP App store statistics. On the Silverlight app store (for instance), there are ‘light versions’ of apps listed  (presumably for trial purposes), in addition to the full versions.  The app store includes statistics for number of apps by industry, device type etc.  The existence of those ‘light versions’ skews the numbers somewhat.

Final Thoughts

Turn the clock 12 months back and there was no app store, and hardly any apps to speak of.  SAP/Sybase were trying to sell what was effectively a mobile development and runtime platform (ie. build your own), and NetWeaver Gateway was not yet released to customers.  Now we see an app store with a good initial pool of SAP supplied apps, not to mention additional partner apps which I have not discussed here.  Will the app store take off?  I believe the next 12 months will be crucial to answering that question.  In particular to see more devices supported for specific apps, and to see more partner apps published in the store (I am told there are many in the process of being certified right now).

One thing is certain – SAP now has some (long awaited) momentum in this space (although as SAP Mentor Thorsten Franz rightly indicates, it could be Why Mobile Isn’t Getting Off the Ground… Faster).  I can’t wait to see where we will be in January 2013.

You must be Logged on to comment or reply to a post.
    • Thanks Pierre,

      I know you have blogged heavily on SUP in the past.  If there are any points in which I am factually incorrect feel free to point them out.  I am always happy to be corrected!


  • Hi John

    Excellent article and really liked the consolidated view of the SAP delivered apps that you pulled together and hopefully someone in the SAP mobile team will create and maintain an official version as I could see that being valuable for customers.

    I also think an onDemand offering delivered by SAP at a reasonable cost would go a long way in helping adoption in the mobile space.



    • Hi Jarret,

      Thanks for your feedback.  At one point I thought about porting this chart to the wiki, but then thought to myself that really SAP should produce the official chart, just like you suggest.  Hope my blog helps in some way to make this happen.  For now, the chart in this blog will need to serve as a ‘snapshot’, not a living document.

      One the of challenges I had was reconciling all the different versions of the app stores.  I must have looked at each one (EcoHub, Silverlight version, iOS version, documentation) several times over but kept coming across minor differences.  Even then, there are instances where I have placed ‘?’ in the chart because none of the versions of the app store clarified the position.



  • Great blog John. I especially like your point form opinions which I totally agree with. A ‘Platform as a Service’ offering from SAP would be ideal.
    I note with interest in another SAP blog that they are recommending the combination of SUP 2.1 and Gateway 2.0 for “always connected” scenarios and the use of MBO’s for offline scenarios.
    • Hi Sergio,
      Great suggestion. Although I would be guessing, because this is not explicity indicated in the SAP app store descriptions I looked at.  For that reason I don’t think I will add the column.  Maybe in a subsequent snapshot.  I think an educated guess however is that apps relying upon DOE have offline support, and given what we see in this post …
      Developing Mobile Apps with Sybase Unwired Platform 2.1 and SAP NetWeaver Gateway 2.0
      .. that “SUP+GW is best suited for online apps”, one might assume that currently all the apps relying on Gateway are online apps.  If anyone out there has a better clarification, I’d like to hear it.
      • I’m with you John and it would be nice to cooperate with you keeping the matrix updated all together.
        What about creating a wiki page and migrate the great excel you prepared into a wiki table.
        Meanwhile, after reading tons of documents, I’m pretty sure that SAP Retail Execution supports offline even if it doesn’t use DOE.
        I’m also pretty sure that SAP Travel Receipt Capture  support the offline scenario’s.
        Since when using Gateway MBO are not supported I’m deducting that synchronization is managed at program level within the native code.

        …Keep going, you rock!

        • Hi Sergio,
          Originally I was thinking to port this to a wiki, then decided SAP should produce it, then you have just about convinced me that perhaps the community might do a better job of it.  The good thing about a wiki is we could add useful links to each app (eg. blog posts).  It would be worth it just to get your own knowledge about what apps are online versus offline into it.

          Interested if anyone else thinks it is a good idea, or NOT a good idea to port this to the wiki? 

          PS.  Sergio, if I do port the table, I will advise you via a blog comment.

          • Hi,

            It IS a good idea! I think I saw the same kind of document on our internal forums (but with less details). I can compare both documents and modify the public one if something is missing or wrong. It will be a lot easier if John’s document is on the Wiki.


          • Hi,

            It IS a good idea! I think I saw the same kind of document (with less details) in our internal forums. I can compare both documents and update John’s if something is missing or wrong. It will be a lot easier if the document is on the wiki.


          • Hi,

            It IS a good idea! I think I saw the same kind of document (with less details) on our internal forums. I can compare both documents and update John’s if anything is missing. It will be a lot easier if this document is on the wiki.
            PS : this is the 3rd time I try to post this comment…


  • Hi John,

    As usual, a well researched blog with excellent observations. It is a true fact that all apps seem to be iOS first. Eventhough SUP ships with a BB RAD tool, there hardly seems to be a single app for BB.

    Let’s hope that, with the release of the Android native support, many iOS only apps will now be ported to Android, and that the combination of Mobile Business Objects + Webcontainers will take flight as well.

  • Hi John,
    Great Blog as usual. I think Portal on device can be considered as  well. The big advantage from my opinion for this solution is that we can continue to develop solutions that can be supported by any device (iphone, Blackberry , android ..) +  all advantages linked to the use of web applications. The security side is not clear enough i think ? But let’s wait for the Q2 2012.
  • So it seems that SAPs focus is almost exclusively for the ios platform. I find this interesting – as many businesses are adopting Android platform as their choice for corporate phone – due to the cost implications, range of choices and combined with the overall market share of Android based devices.
    I wonder when SAP will start to take the Android platform seriously into contention.
    • Hi Julian,
      My guess on this is that Android support has only been introduced to SUP in recent times, so with product development timelines for the apps it probably wasn’t available when they commenced work. 
      That said, this exposes a great challenge in mobility.  The underlying mobile platforms are evolving at a rapid pace.  I have experienced this first hand with publishing iOS and Android apps.  My iOS apps (eg. myHelp) were coded only 18 months ago with iOS 3.1.  Since then Apple has introduced iOS4 and now iOS5!  Imagine if ABAP evolved at that pace.  At that level, keeping on top of the new libraries and APIs with each evolution of the native platform is a real challenge.  Then, if you have a technology (such as SUP) that seeks to support development for multiple of these native platforms, then the challenge to keeping up is even more challenging.

      Lets hope we see more support for Android fill out the chart this year.


      • You’re right – I wasn’t thinking before posting – I fully understand – and thats just for iOS – Android is also going through similar speed of platform changes – and no doubt the MS platform too. It not only makes it hard for SAP – but also for those of us interested in App development with the SAP ecosystem – as to which platform to focus on. Personally I see Android and iOS as the 2 main alternatives currently. Android is looking even more interesting now that Google has released the app inventor to beta.
    • Hi Jan,
      Thanks for clarifying.  Not sure why I tagged Mobile Workflow as needing NW Mobile – that must be an error on my part.  As to EAM Work Order, I was very frustrated because none of the SAP mobile store channels provided any detail for middleware requirements, other than a vague reference to SUP in the solution description.  I will fix the image in the next 24 hours.


    • Hi Jan,
      I’ve just made the corrections to the blog image (you will see the version 1.1 in the top right).  I don’t intend to keep updating this as SAP adds or amends apps, but if there are errors in the chart as at the time of writing, I am happy to fix them.
      Thanks again.
  • Hi John,

    Firstly thank you for once again providing such a comprehensive and useful blog post. I do hope that SAP picks up this chart and creates an ongoing updated version themselves for us to reference.

    Secondly I couldn’t agree more with your statement “I’ve argued since last year that we need to see some hosted or On Demand offering for this mobility infrastructure.  Some SAP/Sybase partners are moving to offer this, but I believe many customers would like to see the service established by SAP/Sybase.”  – I think that this would lower the barrier to entry for customers to a point where some real momentum could be gained.

    Keep up the great work! 🙂


    • Hi Simon,

      Thanks heaps.  Knowing that some people actually read my blogs makes it worth the effort. 
      And hopefully we will be able to catch up at Mastering SAP Technologies in March?

  • SSO nightmare is back like in the first days of the SAP Portal.
    During my first experiences, I learned that SAP Mobile Apps in the area of HCM, are currently supporting Basic Authentication only.
    To improve local access security users are daily  required to type an 8 digits PIN but the backend user/password have to be typed or stored into the settings.
    Certificates (e.g.X.509) seem not yet supported.
    Any experiences?
    New SSO support column into the matrix?


  • Hi All,
    I picked up an interesting tweet from Chris Whealy (@LogaRythm) from SAP the other day.  It goes like this “Partners building 3rd party #sapnwgw services should use RFCs -> customer not require to add IW_BEP to their live system -> least invasive”. 
    Interesting.  So perhaps partners need not require add-ons to the backend systems if they take this approach, which waters down my concerns in (iii) and (iv) above.


  • Hi John,

    To answer one of your questions, here’s the list of supported devices for SAP CRM Sales 2.0 (released for ramp-up 21/12/2011) :

    iPad/iPhone – iOS 4.3 & above (includes iOS5 support)
    Blackberry – BB OS 6.0 and BB 7.0 (touch and non-touch phones)
    Windows – Windows 7 Tablets, Laptop & Desktop devices, also runs on Windows Vista and Windows XP (NO Phone support)
    Android – Honeycomb 3.0 (release dependent on SUP Support for Android)

    The previous version (1.2) supports iOS, WM and BlackBerry (5.0+) devices.


    • Hi Pierre,

      Thanks so much for this detail. I am a little hesitant to update the chart with this however because it is still in ramp-up.  Although I guess it must actually exist then, right?  Do you know when expected time for GA is?  One thing I want to avoid is the slipperly slope of charting based on what SAP is planning, rather than what SAP has delivered.  The ramp-up scenario kind of falls in between.  I compiled the chart primarily from publicly available information sources (mobile store, SAP help). 
      In relation to your supported devices list, this implies that whilst version 1.2 supported Windows Mobile devices, version 2.0 no longer supports Windows Mobile?  Interesting.

      • Hi John,

        Well you can still update the chart with the information related to version 1.2. According to the information available on the marketplace (Software Downloads > Installations & Upgrades > A-Z > M > SAP Mobile Solutions > SAP CRM Sales then MOB CRM SALES CRM INT and MOB CRM SALES ERP IN) version 2.0 should be available end of february.


  • Hi John
    Great article!

    We have a native app on the Apple App Store that enables SAP Workflow on iPhone and iPad.. Do we need to do anything additional to make it work with SUP or Netweaver Gateway?


    • Hi Manish,
      You haven’t provided much detail, but I would presume you would need to do work to enable your app for SUP and NetWeaver Gateway.  I would suggest you post your question separately in the iPhone/iPad Application Development forum.


  • Hi John,

    excellent article!
    The only real pain point in my opinion (which you also mentioned) is the too complex infrastructure (Gateway, SUP, DOE, …) which is required to run the SAP apps.