Background

The current SDWebImage 5.0 Swift API is exported from Objective-C interface by clang importor. Which looks OK, but not really convenient compared with other pure Swift API. For example:

• Objective-C API:

[imageView sd_setImageWithURL:url placeholderImage:nil options:0 context:@{SDWebImageContextQueryCacheType: @(SDImageCacheTypeMemory)} progress:nil completion:^(UIImage *image, NSError *error, SDImageCacheType cacheType, NSURL *url) {
  // do something with result
    if (error) {
        NSLog(@"%@", error);
    } else {
       // do with image
    }
}];

• Swift API:

imageView.sd_setImage(with: url, placeholderImage:nil options:[] context:[.queryCacheType : SDImageCacheType.memory.rawValue] progress:nil) { image, error, cacheType, url in
  // do something with result
  if let error = error {
      print(error)
  } else {
      let image = image!
  }
} 

This looks not so Swifty in Swift world. A better design should looks like this, by using the powerful of Swift Language syntax, including:

• Default Params
• Enum with Associated Object
• Result Type

• The polished Swift API:

imageView.sd.setImage(with: url, options: [.queryCacheType(.memory)] { result
    switch result {
    case .success(let value):
        let image = value.image
        let data = value.data
    case .failure(let error):
        print(error)
    }
}

Note: The options arg is a enum with associated object, which combine the SDWebImageOptions and SDWebImageContext together, don't need to separate. Objective-C API has to use two type because of the pool C enum limitation to bind to Int value.

Solution

To achieve this goal of polished Swift API, we have some choices.

Modify the Objective-C source code interface with NS_SWIFT_NAME

This can solve the cases like renaming, for example: SDImageCache can renamed into SDWebImage.ImageCache, which drop the prefix of SD

However, this can not solve the issue like SDWebImageOptions + SDWebImageContext into the new API SDWebImage.ImageOptions enum cases.

Create another framework (overlay) and rewrite API

See: https://pspdfkit.com/blog/2018/first-class-swift-api-for-objective-c-frameworks/
See: https://forums.swift.org/t/how-apple-sdk-overlays-work/11317
See: https://github.com/apple/swift/blob/06685bcb516942d6b4ae2cb0c6be5ce324029898/stdlib/public/Darwin/Network/Network.swift

This can be done like this: Create a new framework called SwiftWebImage (naming can be discuessed), which have a source files named SDWebImage.swift and have the following contents:

@_exported import SDWebImage

Then, maked all the public API in SDWebImage as @unavailable, like this:

@available(*, unavailable, renamed: "SwiftWebImage.ImageOptions")
public struct SDWebImageOptions {}

@available(*, unavailable, renamed: "SwiftWebImage.ImageOptions")
public struct SDWebImageContext {}

Finally, implements the overlay logic by calling the original SDWebImage API, like this (the sd wrapper is from Kingfisher's design, actually the same) :

/// Wrapper for SDWebImage compatible types. This type provides an extension point for
/// connivence methods in SDWebImage.
public struct SDWebImageWrapper<Base> {
    public let base: Base
    public init(_ base: Base) {
        self.base = base
    }
}

extension SDWebImageCompatible {
    /// Gets a namespace holder for SDWebImage compatible types.
    public var sd: SDWebImageWrapper<Self> {
        get { return SDWebImageWrapper(self) }
        set { }
    }
}

extension UIImageView : SDWebImageCompatible {}

public protocol ImageResource {}

extension URL : ImageResource {}

extension SDWebImageWrapper where Base: UIImageView {
    @discardableResult
    public func setImage(
        with resource: ImageResource?,
        placeholder: UIImage? = nil,
        options: ImageOptions? = nil,
        progress: LoaderProgressBlock? = nil,
        completion: ((Result<ImageResult, ImageError>) -> Void)? = nil) -> CombinedOperation? {
            // convert the `ImageOptions` into the actual `SDWebImage` and `SDWebImageContext`
            // finally call the exist `sd_setImage(with:) API
        }
}

Done. When you import the SwiftWebImage framework, your original SDWebImage old Swift API will be marked as unavailable, so you can enjoy the new API.

import SwiftWebIamge
import SDWebImage // This will be overlayed and not visible, actuallly you don't need to import this

Overlay framework naming

Question: For Apple Standard Framework like Network.framework, the Swift Runtime provide a overlay framework which module name is the same as Network. So if you write :

import Network

You actually don't import the Network.framework, but import the libSwiftNetwork.dylib and its module.

import SwiftNetwork // Actually what you do

// The libSwiftNetwork has this:
@_exported import Network

@available(*, unavailable, renamed: "Network.NWInterface")
typealias nw_interface_t = OS_nw_interface

public class NWInterface {
    // ...Call C API for internal implementations
}

We want to adopt this design as well, so that you don't need to replace the import SDWebImage into import SwiftWebImage. However, due to the reality that we support 3 different package manager:

• CocoaPods: Available to do so by using the custom prepare_script script phase to copy the module name
• Carthage: Available to do so by using the custom Build Phase in Xcode Project
• SwiftPM: Not available to do so because you can not declare two framework with same module name :)

And, for exist SDWebImage 5.0 user, if he/she really don't want to update to the new Swifty API, they can still use import SDWebImage to use the old Objective-C exported API. Naming the overlay framework different from SDWebImage can allows for this choice.

Which means: there are two types of Swift API, depends on how you import:

• Don't use overlay framework

import SDWebImage

let imageCache = SDImageCache.shared
imageView.sd_setImage(with: url, options: [], context: [.imageScaleFactor : 3])

• Use overlay framework

import SwiftWebImage

let imageCache = ImageCache.shared
imageView.sd.setImage(with: url, options: [.scaleFactor(3)])

Rewrite SDWebImage totally with Swift and drop Objective-C user

As my personal option, this is not always a good idea. There are already some awesome Swift-only Image Loading framerwork for iOS community:

• Kingfisher: https://github.com/onevcat/Kingfisher
• Nuke: https://github.com/kean/Nuke

We have some common design and solution for the same thing. Rewrite entirely need some more timeing and unit testing to ensure function.

And, SDWebImage 5.0 current is still popular in many Objective-C project and users, expecially in China. Nearly 80% users from Objective-C use it in the company's App (not personal App). And most of them have a codebase which mixed the two language. Drop these Objective-C user need to be carefuly considerated.

And I think: Currently, Objective-C and Swift is a implementation details, the benefit from Swift written in implementation may including:

• Thread Safe: I disagree with this. The thread safe issues exists in Kingfisher and Nuke, which is not what a language can solve. But Swift have strict optiona type to avoid some common mistake like null check.
• Performance: However, the Image Loading framework performance is not becaused of Objective-C runtime message sending architecture, it's because of some queue dispatch issue, or Image Decoder code. Both of them can not been solved by Swift language level.
• Maintainess: This is the main reason. The new iOS programmer now have less knowledge about Objecitive-C practice and best coding style, using Swift in implementation can attract better contribution from new users.

So, my personal idea for SDWebImage 6.0.0, it's that we only rewrite the API level for Swift, still using Objecitive-C for internel implementation. Both Swift and Objective-C shall share the same function and optimization from version upgrade.