Migration Guide to Version 5.0.x
In-App Protection SDK for Apple version 5.0.x renames the product (formerly Malwarelytics for Apple) and changes how the library is distributed. There are no source code changes — the Swift module is still called WultraAppProtection and the public API is unchanged. You only need to update the way the library is integrated into your project.
Summary of Changes
| Area | Change |
|---|---|
| Product name | Malwarelytics for Apple is now In-App Protection SDK for Apple |
| Source code / API | No changes. The module name remains WultraAppProtection |
| CocoaPods | Support dropped, because CocoaPods is being sunset. Use Swift Package Manager instead |
| Swift Package Manager | The library is no longer distributed from the malwarelytics-apple-release Git repository. It is now available from the Wultra Swift package registry as wultra.iap-sdk-apple |
| Authentication | The registry credentials are stored in the Keychain or in the .netrc file, see Installation |
Product Rename
The product is now called In-App Protection SDK for Apple. The rename affects documentation and distribution only. Your imports and API calls remain the same:
import WultraAppProtection
CocoaPods Is No Longer Supported
CocoaPods has been sunset, and the SDK is no longer published as a pod. If you integrated the library with CocoaPods, migrate to Swift Package Manager.
Before (Podfile):
target 'MyProject' do
use_frameworks!
pod 'AppProtection', :git => 'https://github.com/wultra/malwarelytics-apple-release.git', :tag => '3.4.0'
end
After: remove the AppProtection pod from your Podfile, run pod install and add the SDK via Swift Package Manager as described in the next section.
Swift Package Manager Integration Has Changed
The SDK is no longer resolved from a Git repository URL. It is now distributed through a Swift package registry, which means that:
- the dependency is declared with a package identifier (
wultra.iap-sdk-apple) instead of a Git URL, - the registry needs to be configured and authenticated before the first use,
- the library product is referenced with
.product(name:package:).
1. Configure and authenticate against the registry
Follow the Prerequisities section of the installation guide. In short:
swift package-registry set --global --scope wultra https://wultra.jfrog.io/artifactory/api/swift/iap-sdk-apple
swift package-registry login https://wultra.jfrog.io/artifactory/api/swift/iap-sdk-apple \
--username [email protected] \
--password <JFrog access token>
By default, the credentials are stored in the macOS Keychain. Optionally, add the --netrc parameter to store them in the ~/.netrc file instead. The netrc file is less secure (credentials are saved in plain text), but it is easier to use in CI/CD flows, because it needs no UI interaction. In non-interactive environments, also add --no-confirm to skip the confirmation before writing to the file:
swift package-registry login https://wultra.jfrog.io/artifactory/api/swift/iap-sdk-apple \
--username [email protected] \
--password <JFrog access token> \
--netrc \
--no-confirm
If you store the credentials in the .netrc file instead of the Keychain, you also need to pass -packageAuthorizationProvider netrc to xcodebuild. See Installation for details.
2. Replace the dependency
If you use Xcode’s user interface, remove the old https://github.com/wultra/malwarelytics-apple-release package from the project and add the wultra.iap-sdk-apple package from the registry instead.
If you declare the dependency manually in Package.swift:
Before:
dependencies: [
.package(name: "AppProtection", url: "https://github.com/wultra/malwarelytics-apple-release.git", .upToNextMajor(from: "3.0.0"))
],
targets: [
.target(
name: "YourLibrary",
dependencies: [
"WultraAppProtection"
])
]
After:
dependencies: [
// Use the latest version from the Release Notes
.package(id: "wultra.iap-sdk-apple", .upToNextMajor(from: "<version>"))
],
targets: [
.target(
name: "YourLibrary",
dependencies: [
.product(name: "WultraAppProtection", package: "wultra.iap-sdk-apple")
])
]
3. Build
Resolve the packages and build your project. As the module name did not change, no changes in your source code are needed.
If you build with xcodebuild in a CI/CD environment, make sure that the registry credentials are available to it (see Installation).