Mobile SDKs – which one?

If you currently build a mobile app for iOS or Android, and you want to integrate Analytics, Target, Audience Manager, Campaign, you have the choice: you can use the good old Mobile Services SDK and Campaign SDKs, or you can use the new Adobe Experience Platform Mobile SDK, which is driven from the Launch user interface.

So which one should you use?

We all know that the generic answer is “the new one, d’uh!”, but I’d like to go beyond that.

Coverage

Let’s start with the easy bits.

If you build native apps for iOS or Android, or with React Native, then you can use either.

If you build for PhoneGap, Unity, Xamarin, Windows, then you currently have no choice but to use the Mobile Services SDK. That is likely going to change, though, according to the online documentation.

Blackberry and Windows 8 will likely not be supported by the Platform SDK, but hey.

Support for the Mobile version 4 SDKs will end on September 30, 2020

Data

One of the jobs of the SDKs (old and new) is to help you get data into Experience Cloud Solutions — Audience Manager & Analytics.

There are three ways of doing so:

1. Lifecycle Metrics
2. trackState() calls
3. trackAction() calls

That has not changed, really.

Sure, the actual code required to implement Lifecycle Metrics has changed ever so slightly…

But the rest is identical.

1. You can add data to any of those calls, or, to be specific, Context Data
2. A trackState() call will count a PageView, and send the name of the current Activity/View as the “page name”
3. A trackAction() call will not count a PageView, so you’ll have to explicitly specify (an) event(s)

There is one big difference, but I’ll mention that later, in the “Flexibility” section.

Content

The Mobile Services SDK includes Target.

App developers can make calls to Target, then take the reply (usually JSON payload, defined in the Target UI via JSON Offers), and have the app act appropriately.

That is pretty much the same with the Platform SDK. Instead of calling loadRequest() with the Mobile Services SDK, you would call retrieveLocationContent(). The data types have also changed a little bit.

The overall idea is still the same.

Mobile Services also includes push messaging and in-app messaging. That can be done using the “Mobile Services” Extension for the Platform SDK, or maybe a 3^rd-party Extension.

And the functionality formerly available in the Campaign SDK, now lives in the Platform SDK, too, in the form of the Adobe Campaign Classic and Adobe Campaign Standard Extensions.

There is also an Extension called “Adobe Target – Visual Experience Composer“, which allows changing text and images in the app. Not the full potential of Target, but quick.

Configuration Flexibility

This one is where the new Experience Platform SDKs really shine!

The Mobile Services SDKs could be configured through the Mobile Services UI. The result would be a file called ADBMobileConfig.xml. You would take that file, plus the SDK binary, and add them into your app. The SDK would use the ADBMobileConfig.xml file to know things like which report suite to use, whether Target should be enabled, and more.

The Adobe Experience Platform Mobile SDK, on the other hand, requests the configuration each time the app starts, using Launch as a service.

Three reasons why this is cool:

1. File Size

Via Launch, you can add Extensions to your Mobile Property.

Those translate into gradle / Cocoapod configurations, which will omit or include what is needed, during the build.

If your app uses Target, but not Analytics, the code for Analytics will not be included in your app!

2. Dynamic Configuration

The SDK calls Launch when the app starts, and it gets the configuration, or should I say the current configuration that way.

That is important because it means that you can change things for existing apps!

With Mobile Services, a change in report suite ID would have meant releasing your app, with all the headache around that, plus the fact that not all users will follow updates as quickly as you’d like them to. The Platform SDK allows you to make that change, and existing, already installed apps will honour it.

Very, very cool!

3. Limited Support for Rule-based Actions

There is also limited support for Launch Events, Rules, Conditions, and Actions, which means you can, to some extent, even change what Experience Cloud Solutions should do without having to re-release.

Also very, very cool!

Details

A lot of us have fallen for the “with tag management, you won’t need IT anymore” line, so before Luk… you tell me I’m just repeating marketing material, let me go into detail.

The Mobile Core Extension provides a bunch of Data Element Types, such as “Experience Cloud Visitor ID”, “Device Name”, “OS Version”, and so on.

Most of them are constants with no configuration.

The Mobile Core Extension also provides four Event Types: “Collect PII”, “Launched”, “Track Action”, and “Track State”.

The latter fire when the app code calls the trackAction() or trackState() methods, and having a Rule with these Event Types allows you to amend the tracking. The same goes for “Collect PII”, which triggers when your code calls collectPII().

The “Launched” Event Type fires, as you may have guessed, on app launch.

Now the interesting part are the Action Types provided by the Mobile Core Extension. There are “Open URL”, “Send PII”, and “Send Postback”. On top of that, the Analytics Extension provides a “Track” Action Type, which you use to send an action or a state, plus Context Data.

There is an Extension called “Profile”, which can be used to store data in the app, sort of like cookies or Local Storage in a browser. The Extension provides an “Update Profile” Action Type, plus a “Profile Key” Data Element Type for retrieving information from the profile.

Noone knows what other Extensions people will build, and what they will add to the mix. Even with the above, you can do a bunch of stuff in your app, such as storing information in the profile and tracking it under specific circumstances.

I think this is comparable to Processing Rules, in the sense that you can do fairly straight-forward things on the fly, and that it will sometimes save the day.

So, which one?

Obvious choice for me: use the Platform SDK

For some platforms / environments, you do currently not have the choice, true. But you’re reading this, so I presume you’re thinking about it.

The Platform SDK is the future, and the configuration via Launch is pretty cool.

That is all.