Salesforce Marketing Cloud SDKs Aren’t a Mess. They’re a Modular System.

Photo by Caspar Camille Rubin on Unsplash

How to keep your iOS app lean while growing from push to Core, CDP, and personalization

If you’ve worked with Salesforce Marketing Cloud mobile SDKs on iOS, you’ve probably asked yourself one question:

Why are there so many pieces?

MarketingCloudSDK, SFMCSDK, PushFeatureSDK, MAM, notification extensions, extra repositories. At first glance, the whole setup can feel over-engineered.

But the structure is not accidental.

Once you see the pattern, it actually becomes easier to reason about. And more importantly, easier to scale.

The core idea is simple:

Start with one foundation, then attach only the modules you actually need.

That is what makes this approach useful for mobile teams trying to balance delivery speed, app size, and future flexibility.

The iOS mental model

On iOS, both Engagement and Core flows share the same foundation: SFMCSDK.

From there, the stack branches depending on product context.

Marketing Cloud Engagement (MCE)

A typical Engagement setup includes:

• MarketingCloudSDK
• SFMCSDK
• PushFeatureSDK
• optional notification extensions for rich push

Marketing Cloud on Core (MAM)

A typical Core setup includes:

• SFMCSDK
• mam-core-sdk-ios
• optional push features and notification extensions

That is the key distinction.

This is not two completely separate SDK worlds. It is one shared base with different layers on top.

Why this architecture works in practice

1. Smaller app footprint

If your app only needs standard push and basic event tracking, you do not need to ship rich-push extensions, extra templates, or additional UI layers.

That keeps the app lean and avoids pulling in features you are not using yet.

2. Rich push stays optional

Images, carousels, custom notification UI, and advanced notification flows belong in extension targets.

That is a good thing. It means those features stay optional instead of becoming part of every build by default.

3. Your roadmap stays flexible

This same modular model makes it easier to evolve the app over time.

You can start with push, then add CDP capabilities, then layer in personalization later.

No monolithic rewrite. No need to replace the whole stack just because the roadmap expanded.

Where CDP and Personalization fit

This is the part that is easiest to misunderstand.

CDP/Data 360 and Personalization should be treated as part of a Core-oriented setup.

In practical terms, that means:

If you want CDP and Personalization, plan for the Core path: SFMCSDK + the MAM/Core layer, then the CDP and Personalization modules on top.

That detail matters because the foundation may be shared, but not every capability belongs to the same product layer.

Salesforce’s iOS guidance for personalization follows exactly that modular pattern:

• install the required modules,
• initialize Data 360 and Personalization early in the app lifecycle,
• manage consent correctly,
• request decisions with fetchDecisions(...),
• render placements using personalizationsByName.

Docs: iOS Integration — Salesforce Personalization Repo: Personalization-IOS

So yes, CDP and Personalization are modular additions. But they are not just generic add-ons that sit equally on top of every configuration.

Practical advice for iOS teams

• Start minimal and avoid shipping optional modules too early.
• Keep rich push in dedicated extension layers.
• If your roadmap includes CDP or Personalization, design for a Core-layer setup.
• Grow the stack incrementally instead of front-loading complexity.

Once you look at the SDK ecosystem through that lens, it stops feeling chaotic.

It starts looking like what it actually is: a modular architecture designed to let your app grow without turning into a monolith.