Apple has designed Swift to be fully cross-compatible with existing Objective-C-based APIs. This interoperability extends to all third-party SDKs as well.
The Swift developer tools already come bundled with an excellent importer that makes using Objective-C APIs almost indistinguishable from native Swift APIs. However, since this importing is done automatically and on the fly, there are some corner cases that aren’t quite covered or could cause issues.
In this post, I will go through the process of setting up a brand new iOS app, written in Swift, that imports and uses a few of the Creative SDK frameworks. You can find a fully-working and configured sample in the Creative SDK samples GitHub repository.
To get started, we’ll need to create an iOS app that uses Swift as its main programming language.
Note that you can easily integrate the Creative SDK into Objective-C codebases, but for this article we’re going to focus on Swift.
The first step is to create an iOS app, preferably a “Single View Application” to keep things simple.
The Creative SDK is currently a static library written in Objective-C. One of the powerful features of Objective-C is the ability to augment existing functionality using Categories.
Since Categories are used for some publicly-accessible functionality of the SDK, we’re required to specify the
-ObjC linker flag in the “Other Linker Flags” setting in the newly created app’s Build Settings. Consult the Technical Q&A 1490 (QA1490) for more information about why this flag is necessary.
Note: This section was deprecated in
v0.14.2160, and is no longer required. If you are using a newer version of the Creative SDK, you can skip to the next section.
In the past, the Creative SDK was configured as a “monolithic” framework that contained all the functionality in a single framework. This made it easier to integrate all the Creative SDK APIs in one step.
Over time, the functionality and complexity of the Creative SDK grew, which made the monolithic framework more difficult to integrate and use. This prompted us to split the features of the SDK into smaller, more independent frameworks. To maintain backwards compatibility with existing apps that were using the monolithic framework, we introduced a preprocessor macro that would dictate whether the “split components” were used.
To tell the preprocessor that we intend to integrate functionality from different frameworks within our app, we need to specify the
Framework Search Paths
We need to specify the path to the location where we’ve downloaded the Creative SDK as the Framework Search Path. This path is used for code completion and binary linking.
All we need to do is to specify the path in the Build Settings:
Linking with the Creative SDK Binaries
Now we can add the desired Creative SDK frameworks to our app.
For this guide, we’ll only need the “Core” framework, so we add it in the Build Phases screen. The Creative SDK has other iOS-provided dependencies that we also need to specify.
The full list of dependencies is as follows:
Since the Creative SDK provides some UI components, we’ll need to reference a few resources (compiled storyboards, images, etc.).
To do this, we’ll need to copy the
AdobeCreativeSDKCoreResources.bundle from the
AdobeCreativeSDKCore.framework bundle. This bundle is under the Resources symlink:
The final step before we can use the Creative SDK APIs from Swift is to provide a Bridging Header. This Bridging Header is the guide the Swift importer uses to determine which APIs should be imported and made available in Swift.
All we need to do is to create a new header (
.h) file and add it to our project. Make sure to name this file according to the Swift and Objective-C Interoperability Guide.
Also make sure to specify the name of this header file in the “Objective-C Bridging Header” setting on the Build Settings page. Since we’re only using the Creative SDK Core framework, we only need to import that framework’s umbrella header:
We’re now ready to use the Creative SDK APIs from our Swift app. Since almost all functionality that is exposed by the Creative SDK requires a user account, we can start by configuring the Authentication Manager with the client ID and secret values that are given to us when we register our app with Adobe:
override func viewDidLoad()
// Do any additional setup after loading the view, typically from a nib.
AdobeUXAuthManager.sharedManager().setAuthenticationParametersWithClientID(kClientId, clientSecret: kClientSecret, enableSignup: false)
From this point on, we can call any of the Creative SDK APIs and, as long as an authenticated user session exists, those API calls will work.
There are a few potential issues to be aware of when attempting to use the Creative SDK from Swift. Here are a few issues that you could run into:
- Make sure the
-ObjC linker flag is specified under the “Other Linker Flags” setting in the Build Settings page of your app’s main target.
- Make sure the
USE_CSDK_COMPONENTS preprocessor macro is defined for both Debug and Release configurations of your target. This macro was introduced as a backwards compatibility measure, is temporary, and will go away in an upcoming Creative SDK release.
- In some cases Xcode will not specify the path to the location where you downloaded the Creative SDK frameworks as the “Framework Search Path”. Make sure the path is specified so Xcode’s code completion features function.
- Even if the search path is correctly specified, deprecated methods won’t be marked as such in the suggestion list. These methods are marked as deprecated after they’re actually used in the code. We’re still investigating a way to get this to work. In the meantime, it’s always a good idea to check the API documentation to make sure you’re not using deprecated API methods.
- In some cases, additional header files might need to be added to the Bridging Header file in order for certain Creative SDK APIs to be fully visible to the Swift importer. We’ve fixed this issue in an upcoming version of the Creative SDK, so this shouldn’t be an issue. However, if you come across any method or class that should be there but isn’t, simply including the header file that defines the method/class in question in the Bridging Header manually should resolve the issue.
Apple have done a tremendous job in developing Swift and its tooling. At this point, all APIs from the Creative SDK should easily be accessible and usable. There are small corner cases that can be addressed by simple configuration changes or coding practices, some of which are documented here.
In the near future, we’re planning to move away from static libraries and instead use dynamic frameworks for the Creative SDK. This move will eliminate the Bridging Header and a few of the initial setup steps. It will also set us up to mix and match Swift code with our existing Objective-C codebase, although we’ll have to wait for Swift ABI compatibility, which is scheduled for later this year, tentatively.