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!). Please come check out our new repo [link to repo] to read up on the features, or maybe even drop us a pull request!

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. Stay tuned for more detail coming soon.

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.