Adobe Tech Blog
Published in

Adobe Tech Blog

Adobe Experience Platform Mobile SDKs Move to Swift for iOS

In late 2016 we embarked on a journey to reimagine our existing Adobe Experience Platform Mobile SDKs. There were a few concrete goals in mind, as well as a few nice-to-haves. First and foremost we wanted to implement an extensible and pluggable architecture that would allow for incremental additions of functionality, both internally developed and from partners and customers alike. Additionally, we wanted to build platform-independent logic that was easily portable across various client devices and operating systems. Lastly, we wanted to ensure that the various performance metrics that we track for the SDK (CPU time, memory consumption, binary size, stability) remained at least the same as our pre-existing SDKs.

Language selection

With our baseline requirements and architectures in hand, we moved on to the selection of the underlying language(s) that could be used to achieve or exceed our goals. Because we build for multiple platforms, we first investigated languages that could be used across all of them. This turned out to be a very short list (C++). After a few POCs though, we realized that the restrictions and size implications of shipping a C++ library for Android implementations were too significant to ignore, and we decided to align on a core language for each key platform (one for iOS, one for Android).

Choosing to split the SDK by platform opened up some potential new language choices. Languages such as Swift and Kotlin were gaining significant traction at the time. After some research and POCs, we determined that neither of these languages had yet to implement the features we needed. We specifically needed libraries, code visibility, ubiquity, and general developer comfort. Ultimately we chose to utilize C++ for iOS and Java for Android. We also decided to still implement portable cores for each language, and isolated platform/OS-specific features into their own companion library. This allowed us to port to any future platforms with either the C++ or Java core.

Building the future

Over the two years, our team worked diligently to build out the new functionality in the chosen languages, as well as comprehensive test harnesses, documentation, and a variety of new features (that our new architecture now allowed for). Much awaited functionality such as runtime configuration updates, 3rd party extensions, and a full Adobe Experience Platform Launch integration became reality, and we were able to complete a successful early beta period culminating in a successful GA release in 2019.

Post-release, we have continued to update the SDKs with new features, extensions, and performance/stability enhancements. With the number of customers who have migrated and the advanced implementations that they’ve been able to achieve with the new AEP SDKs, we consider this a clear success.

The only constant is change

While we do consider the re-architecture and re-implementation of the SDKs into C++ and Java to be a huge success, both for our internal process as well as our customer’s use cases. We firmly believe that SDK work is never done. As we continued to iterate on the SDKs, some rough edges started to appear. This is namely related to “C++isms”: binary sizes crept upwards, ABI compatibility for pre-compiled binaries was difficult, exceptions became more opaque, and threading models got complex. We also started receiving requests to support SPM (Swift Package Manager). This led us to revisit our previous foray into Swift as our language of choice for the iOS platform.

We put together an investigatory “spike” team and spent a month porting our C++ architecture into Swift. We also took this opportunity to clean up some APIs, some internal functionality got much smoother (a blog post for another time), and we even took SPM for a test drive. We then vetted our approach with internal teams and found our investigatory efforts to be a massive success. Finally, we decided to go all-in on Swift.

Where are we now

We’ve completed a fully functioning version of the AEP Mobile SDK in Swift. This version is faster, smaller, simpler, and easier for a Swift-native app to implement. It’s also fully open-source and available via SPM. We’ve also built out a “compatibility” layer, to make transitioning from the existing C++ SDK to the Swift version almost zero-cost (depends on if you’re using any really advanced features, but even if you are we promise it’s easy!).

We’re also embarking on some changes to the internal workings of the Java-based SDKs as well, but those changes will be far more transparent and less disruptive due to not needing a language switch. Please come check out our new repos, listed below to read up on the features, or maybe even drop us a pull request.

Closing thoughts

Whether you are a developer implementing Adobe Experience Cloud solutions or an Adobe partner building an extension, the first step would be to try out our SDKs and documentation. Get started by visiting the links above or SDK documentation.

Getting your use cases to work in a simple, streamlined manner is paramount. If something can be improved or isn’t making the most sense, please start asking questions and filing issues.

Once you become more comfortable with our software and have seen our contribution guidelines (see the CONTRIBUTION.md file in each repo for guidelines, processes, etc., submit a pull request through GitHub.)

Your code doesn’t need to be perfect. We’re here to help and we ❤️ contributions.

References

Documentation

  • aep-sdks-documentation: Documentation for the Adobe Experience Platform Mobile SDKs for Adobe Experience Cloud solutions such as Adobe Analytics (with Mobile Services and Media Analytics), Adobe Audience Manager, Adobe Campaign (Standard & Classic), and more.

Swift Repositories

  • aepsdk-core-ios: Swift Core Mobile SDK component to allow for configuration access to default lifecycle events and conditions.
  • aepsdk-edge-ios; Swift extension that allows for sending XDM formatted data to Adobe Experience Cloud solutions, by leveraging Edge Network capabilities.
  • aepsdk-analytics-ios: Swift extension for Adobe Analytics built to understand your customers as people and steer your business with customer intelligence.
  • aepsdk-audience-ios: Swift extension for Adobe Audience Manager which enables data DMP use cases.
  • aepsdk-target-ios: Swift extension to tailor and personalize your customers' experience on mobile application with Adobe Target.
  • aepsdk-rulesenginge-ios: Swift extension providing a simple, generic, extensible rules engine.
  • aepsdk-userprofile-ios: Swift extension to provide client-side store referenceable in rules by Adobe Experience Platform Launch.

--

--

--

News, updates, and thoughts related to Adobe, developers, and technology.

Recommended from Medium

Make a Color LUT Instagram Filter in Spark AR | Best Steps

Developing Cross-Platform (Android/iOS) Apps Using a Single Codebase With Flutter

Catch the Poki iOS Game Project part 3

From Swift to Flutter

QUIC is now available for iOS15. Bidirectional stream with iOS and quic-go

How to handle navigation in SwiftUI

Starting auto-layout programmatically

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jaemi Bremner

Jaemi Bremner

Experience Technologist. Currently Director of Developer Content Engine for DataStax. Former Developer Advocate for Adobe Experience Platform. Twitter: @jaeness

More from Medium

Using composition to deal with cross-cutting concerns in iOS

Introducing the Agoda Widget: What is it, and why did we develop it?

Push notifications beyond the basics

UIViewController Lifecycle