.. /posts

Salesforce Marketing Cloud Mobile SDKs: One Stack, Two Worlds — and Why the Modularity Actually Helps

~6 min read
salesforcemarketing-clouddata-cloudpersonalizationsdkiosandroid

Salesforce Marketing Cloud mobile messaging can look chaotic at first: MarketingCloudSDK, SFMCSDK, PushFeatureSDK, Mobile App Messaging SDK (MAM), plus notification extensions and multiple repos. It’s easy to label it a mess.

But if you look at it as a modular system, it starts to make sense — and that modularity has a real benefit: if you don’t need rich push, you don’t have to ship rich-push components.

This post maps:

  • what’s for Marketing Cloud Engagement (MCE / “legacy”)
  • what’s for Marketing Cloud on Core (Advanced/Growth on the Salesforce platform)
  • what’s shared
  • and how the modular design can actually reduce bloat

Quick reference

  • MCE (Engagement) → MobilePush SDK: one stack per platform (see Android / iOS below for repos and artifacts).
  • MC on Core (Advanced) → Mobile App Messaging SDK (MAM): same foundation on iOS + MAM layer; on Android, a separate MAM artifact.

Android: two worlds, two main SDKs (and why it’s clearer than iOS)

On Android the split is straightforward: you pick one top-level SDK depending on your Marketing Cloud edition. No shared foundation visible in your Gradle file — you add one dependency and get the stack for that product.

MCE (Engagement / legacy) on Android

  • SDK: MobilePush SDK — you add the marketingcloudsdk Maven artifact.
  • Repo: MarketingCloudSDK-Android (source and LearningApp; same repo also documents the SDK).
  • Maven: com.salesforce.marketingcloud:marketingcloudsdk:{version} from the SDK Maven repository.
  • Initialization: You configure and initialize with pushModuleConfig (and from SDK v8+, you use SFMCSdk to initialize the MarketingCloudSdk). Config comes from your Marketing Cloud Engagement app (app id, access token, sender id, mid, server URL).
  • Requirements: Firebase Cloud Messaging, Android 6 (API 23) or later; optional dependencies for location/beacon features (Play Services Location, AltBeacon) if you need geofence or proximity messaging.

So for MCE you have a single entry point: MarketingCloudSDK (MobilePush), consumed as marketingcloudsdk. Under the hood it’s built from modules (core, push, etc.), but you don’t manage those modules yourself — that’s the umbrella dependency pattern: one artifact pulls in the right pieces.

Marketing Cloud on Core (Advanced) on Android

  • SDK: Mobile App Messaging SDK (MAM).
  • Artifact: mobileappmessagingsdk — com.salesforce.marketingcloud:mobileappmessagingsdk:{version} from the same Marketing Cloud Maven repository.
  • Initialization: You use mamModuleConfig (and the same SFMCSdk entry point) and pass MAM-specific config: app id, endpoint URL, access token, tenant id.
  • Requirements: Same as MCE for the basics — FCM, Android 6+ (docs also mention newer SDKs targeting Android 8+). No separate “foundation” dependency in your app; the MAM artifact bundles what it needs.

So on Android you don’t see “SFMCSDK + something else” in your dependency list the way you do on iOS. You add either marketingcloudsdk (MCE) or mobileappmessagingsdk (MAM). The LearningApp in the MarketingCloudSDK-Android repo can use both (e.g. for demos or migration), but for a given app you choose one stack based on your edition.

Why the Android story is simpler

  • One dependency, one stack: One artifact per product; no visible “foundation + product layer” split in Gradle.
  • Same repo, different artifacts: Both MCE and MAM artifacts are published from the same Maven repository; you pick the artifact that matches your Marketing Cloud edition.
  • Modularity under the hood: Salesforce can still ship and version internal modules (core, push, etc.) without forcing you to declare each one. You get a single dependency and transitive resolution does the rest.

iOS: a shared foundation + different layers

On iOS things look more complex because both worlds share the same foundation and the split is explicit in repos and packages.

iOS — MCE (Engagement / legacy)

A typical setup:

There isn’t a separate “MCE module” you add as its own package. In practice MCE = the same base stack running in an Engagement context.

iOS — Marketing Cloud on Core (MAM / Advanced)

Here’s the twist:

  • You still use the same foundation (SFMCSDK), and you add the “on Core” layer:
    • Mobile App Messaging SDK (repo: mam-core-sdk-ios) — in Package.swift it depends on sfmc-sdk-ios.
    • Plus PushFeatureSDK when you need push.
    • Optionally Extension SDK for rich push.

So “on Core” on iOS isn’t “a totally different universe” — it’s:

The same foundation (SFMCSDK) + the MAM layer

Why the modular approach actually helps

It can feel messy when you first see all the repos and names, but modularity has real benefits:

1) Smaller footprint when you only need basic push

If your needs are:

  • standard push
  • device/user identification
  • basic analytics/event tracking

you shouldn’t have to pull in notification UI templates or extension-specific code “just in case”. A common mistake is shipping everything upfront. This architecture supports a need-to-have approach.

2) Rich push and templates as an optional layer

Features like:

  • rich image push
  • carousel/templates
  • delivery events
  • custom push UI

usually require a Notification Service Extension and/or Notification Content Extension. That’s a separate layer. If you don’t use it, don’t ship it.

3) One foundation layer across multiple products

The same pattern shows up beyond push:

  • Data 360 (the new name for Data Cloud / Salesforce’s CDP): the same mobile foundation (e.g. MarketingCloudSDK / SFMCSDK) can feed a CDP module — event queueing, flattening, forwarding to the CDP. So you’re not wiring a second, unrelated SDK; you’re attaching a data layer to the stack you already have.
  • Salesforce Personalization: again, same foundation plus a CDP/personalization module. Use one SDK surface for identity and events; add personalization when you need it.

So Data 360 (Data Cloud / CDP) and Salesforce Personalization don’t each get their own monolith. You get:

One foundation + attachable modules per use case

That helps with incremental adoption (push now, personalization later), long-term compatibility, and product evolution without constant re-architecture.

Practical takeaways

  1. Don’t add extensions if you don’t need rich push. Keep the main app target minimal.
  2. iOS: one foundation (SFMCSDK) + MAM layer for Core (mam-core-sdk-ios). Android: one artifact — marketingcloudsdk (MCE) or mobileappmessagingsdk (Core) — same Maven repo.
  3. If your roadmap is push → data/360 → personalization, add capabilities incrementally; the modular model supports that.