Mobile Commerce with SAP Commerce Cloud (formerly Hybris): Features, Performance and PWA

For most online shops, the phone is where the majority of sessions start. A commerce platform’s mobile capabilities therefore decide whether customers can buy from you at all, not whether the shop looks modern.

Many companies still treat mobile as a shrunken desktop site. That is the wrong way round: design for the phone first, then stretch the layout to the larger screen.

SAP Commerce Cloud, the product formerly known as SAP Hybris, handles mobile in three layers: the responsive SAP Composable Storefront (formerly Spartacus), Progressive Web App (PWA) features, and the OCC REST APIs that any frontend or native app can call. Below is what each layer does and where its limits are.

TL;DR: SAP Commerce Cloud serves mobile shoppers through the responsive Angular-based Composable Storefront, PWA features such as caching and add-to-home-screen, and OCC APIs that also feed native apps. For most B2C and B2B shops a well-built PWA is enough; a native app pays off for barcode scanning, AR or heavy offline use. The biggest mobile wins usually come from performance work on images, JavaScript and caching.

How does SAP Commerce Cloud handle mobile?

Commerce Cloud’s mobile support works in three layers.

Layer 1: the responsive storefront. SAP Composable Storefront is an Angular application whose components adapt to screen size: grids collapse, navigation switches to a menu, touch targets are sized for fingers. The basics, done properly. We once took over a shop whose previous implementation used 32-pixel touch targets on mobile, and customers kept tapping the wrong element. The Composable Storefront defaults are sensible here. (If you are still on the older Accelerator storefront, our guide on migrating to Composable Storefront covers the move.)

Layer 2: Progressive Web App. Composable Storefront ships with PWA support: a service worker for caching and an installable web app with add-to-home-screen. No app store, no approval process, no separate release cycle. SAP describes the PWA feature set as still being extended (SAP Help: Progressive Web Application Support), so push notifications and deeper offline behaviour usually need project work.

Layer 3: OCC APIs. The Omni Commerce Connect REST APIs return structured JSON, and responses can be trimmed with field sets to keep payloads small on mobile networks. That matters on a weak connection in a mountain valley, and it is the same API a native app would use.

Do you need a native mobile app?

For most commerce use cases, no. A PWA covers caching of browsed content, add-to-home-screen and app-like navigation, and with some project work also push notifications. That is enough for the vast majority of B2C and B2B scenarios.

A native app is worth it when you need AR product visualisation, device hardware such as barcode scanning or GPS, heavy offline functionality (field sales, for instance) or dedicated B2B workflow apps. What we advise against is building a native app mainly so the brand has an icon in the App Store: the build and maintenance cost is real, and without a use case the web cannot serve, downloads stay low.

If you do go native, the OCC APIs serve the app the same way they serve the web storefront. Same backend, different frontend. Whether Composable Storefront or a React or Next.js frontend fits your team better is a separate question, which we cover in SAP Composable Storefront vs React and Next.js.

Which mobile performance work matters most?

A slow mobile storefront loses customers at every tap. Google’s Core Web Vitals are the practical yardstick:

• LCP (Largest Contentful Paint): the main image within 2.5 seconds on mobile. Use responsive images, lazy loading and a CDN.
• INP (Interaction to Next Paint): keep the JavaScript bundle small through lazy loading and code splitting.
• CLS (Cumulative Layout Shift): set explicit width and height on images and reserve space for dynamic content.

Commerce Cloud-specific optimisations:

• Image compression and WebP delivery
• CDN caching for static assets and suitable API responses
• Server-side rendering (SSR) in Composable Storefront to get the first content on screen faster
• Lazy loading for product images below the fold
• Lean search API responses for mobile product cards

None of this is glamorous work, but it is the difference between a mobile shop that sells and one that loses customers on every page. If you want an outside view of your storefront, talk to our Commerce team or see how we compare SAP Commerce Cloud partners in Switzerland. More on the platform itself is on our SAP Commerce Cloud page.

FAQ

Does SAP Commerce Cloud support Apple Pay and Google Pay?

Yes, through the payment service provider you integrate, for example Adyen, Stripe or a Swiss provider. The wallets are enabled and configured at the payment provider, not in Commerce Cloud itself.

How does the storefront handle poor connectivity?

The PWA service worker caches static assets and content the customer has already viewed, so browsing degrades gracefully. Transactions still need a connection: checkout cannot complete offline.

Can I have different layouts for mobile and desktop?

Yes. Responsive CSS adapts the components automatically. Where you need different content rather than a different arrangement, SmartEdit lets you personalise or restrict components for specific audiences.

How does mobile search work?

The same search backend (Solr in the standard setup) serves both. The storefront adapts the interface: a full-screen search overlay, touch-friendly filters and facet panels.

What about barcode scanning for B2B?

Commerce Cloud does not include scanning out of the box. You need a native app, or a PWA that uses the browser’s camera access, and several partner components add this capability.