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.
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
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:
- Lifecycle Metrics
That has not changed, really.
Sure, the actual code required to implement Lifecycle Metrics has changed ever so slightly…
But the rest is identical.
- You can add data to any of those calls, or, to be specific, Context Data
trackState()call will count a PageView, and send the name of the current Activity/View as the “page name”
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.
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 3rd-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.
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!
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
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
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.
6 thoughts on “Mobile SDKs – which one?”
Do you know (have you tested) how does this work for an offline app? Is there some sort of default config stored within the app during the build or does it need to access the Launch configuration every time the App launches?
We are no preparing to release the upgrade to Platform SDKs, but I was not able to get around some of these details with limited access to developers.
The SDK caches the configuration, that I know for sure. Whether it uses some “compiled-in” version on the first ever launch of the app, I have to test. I suspect that’s what it does.
I hope so, because otherwise we have an issue with our security – they want list of IP addresses of Akamai hosting. Do you know if there are plans to enable selfhosting of mobile properties in Launch? Currently I can only see “Adobe hosted” (and that is funny, because when I ask Adobe for IP adresses of “Adobe hosted” ClientCare says that it is not hosted by Adobe, but Akamai and that they don’t have such information).
No idea, sorry. Might be a question for the #adobe-launch channel in the #measure slack, or for the #launch-developers slack…
LikeLiked by 1 person
So the answer is that you can decide to ship a configuration file, and you can still use the update, too. See https://aep-sdks.gitbook.io/docs/using-mobile-extensions/mobile-core/configuration/configuration-api-reference#using-a-bundled-file-configuration
(just placing that here, because in Slack, it’ll be forgotten soon)