AsyncPhoto – Augmented Code

In the part 1 of the series, AsyncPhoto for displaying large photos in SwiftUI, we built a SwiftUI view which has a similar interface to Apple’s AsyncImage, but provides a way to use any kind of image data source. In the part 2 of the series, we’ll implement an in-memory cache for the AsyncPhoto. This is important for reducing any flickering caused by the nature of async image loading. An example to highlight where it comes useful is when we have a detail view which displays a thumbnail of a large photo. If we open the detail view multiple times for the same photo, we really do not want to see the loading spinner every single time. Another benefit is that we do not need to load a huge photo in memory and then spending CPU on scaling it down.

OK, let’s jump into it.

The aim of the cache is to cache the scaled down images. We never want to cache the original image data since it would make the memory usage to through the roof, and we would still need to use CPU to scale down the image. Before we start, we need to remember that in part 1 we designed the AsyncPhoto in a way where it has an ID, scaledSize properties and a closure for returning image data asynchronously. Therefore, the caching key needs to be created by using the ID and the scaled size, since we might want to display a photo in multiple AsyncPhoto instances with different sizes. Let’s create an interface for the caching layer. We’ll go for a protocol based approach, which allows replacing the caching logic with different concrete implementations. In this blog post we’ll go for a NSCache backed caching implementation, but anyone else could use other approaches as well, like LRUCache.

	/// An interface for caching images by identifier and size.
	protocol AsyncPhotoCaching {

	/// Store the specified image by size and identifier.
	/// – Parameters:
	/// – image: The image to be cached.
	/// – id: The unique identifier of the image.
	func store(_ image: UIImage, forID id: any Hashable)


	/// Returns the image associated with a given id and size.
	/// – Parameters:
	/// – id: The unique identifier of the image.
	/// – size: The size of the image stored in the cache.
	/// – Returns: The image associated with id and size, or nil if no image is associated with id and size.
	func image(for id: any Hashable, size: CGSize) -> UIImage?


	/// Returns the caching key by combining a given image id and a size.
	/// – Parameters:
	/// – id: The unique identifier of the image.
	/// – size: The size of the image stored in the cache.
	/// – Returns: The caching key by combining a given id and size.
	func cacheKey(for id: any Hashable, size: CGSize) -> String
	}

	extension AsyncPhotoCaching {
	func cacheKey(for id: any Hashable, size: CGSize) -> String {
	"\(id.hashValue):w\(Int(size.width))h\(Int(size.height))"
	}
	}

view raw AsyncPhotoCaching.swift hosted with ❤ by GitHub

The protocol only defines 3 functions for writing, reading, and creating a caching key. We’ll provide a default implementation for the cacheKey(for:size:) function. Since the same image data should be cached by size, the cache key combines id and size arguments. Since we are dealing with floats in a string, we’ll round the width and height.

The next step is to create a concrete implementation. In this blog post, we’ll go for NSCache which automatically evicts images from the cache in case of a memory pressure. The downside of a NSCache is that the logic in which order images are evicted is not defined. The implementation is straight-forward.

	struct AsyncPhotoCache: AsyncPhotoCaching {
	private var storage: NSCache<NSString, UIImage>
	static let shared = AsyncPhotoCache(countLimit: 10)

	init(countLimit: Int) {
	self.storage = NSCache()
	self.storage.countLimit = countLimit
	}

	func store(_ image: UIImage, forID id: any Hashable) {
	let key = cacheKey(for: id, size: image.size)
	storage.setObject(image, forKey: key as NSString)
	}

	func image(for id: any Hashable, size: CGSize) -> UIImage? {
	let key = cacheKey(for: id, size: size)
	return storage.object(forKey: key as NSString)
	}
	}

view raw AsyncPhotoCache.swift hosted with ❤ by GitHub

We also added a shared instance since we want to use a single cache instance for all the AsyncPhoto instances. Let’s see how the AsyncPhoto implementation changes when we add a caching layer. The answer is, not so much.

	struct AsyncPhoto<ID, Content, Progress, Placeholder>: View where ID: Hashable, Content: View, Progress: View, Placeholder: View {
	// redacted

	init(id value: ID = "",
	scaledSize: CGSize,
	cache: AsyncPhotoCaching = AsyncPhotoCache.shared,
	data: @escaping (ID) async -> Data?,
	content: @escaping (Image) -> Content = { $0 },
	progress: @escaping () -> Progress = { ProgressView() },
	placeholder: @escaping () -> Placeholder = { Color(white: 0.839) }) {
	// redacted
	}

	var body: some View {
	// redacted
	}

	@MainActor func load() async {
	// Here we access the cache
	if let image = cache.image(for: id, size: scaledSize) {
	phase = .success(Image(uiImage: image))
	}
	else {
	phase = .loading
	if let image = await prepareScaledImage(for: id) {
	guard !Task.isCancelled else { return }
	phase = .success(image)
	}
	else {
	guard !Task.isCancelled else { return }
	phase = .placeholder
	}
	}
	}

	private func prepareScaledImage(for id: ID) async -> Image? {
	guard let photoData = await data(id) else { return nil }
	guard let originalImage = UIImage(data: photoData) else { return nil }
	let scaledImage = await originalImage.scaled(toFill: scaledSize)
	guard let finalImage = await scaledImage.byPreparingForDisplay() else { return nil }
	// Here we store the scaled down image in the cache
	cache.store(finalImage, forID: id)
	return Image(uiImage: finalImage)
	}
	}

view raw AsyncPhoto.swift hosted with ❤ by GitHub

We added a new cache argument but also set the default value to the shared instance. The load() function tries to read a cached image as a first step, and the preparedScaledImage(for:) updates the cache. We rely on the cache implementation to keep the cache size small, therefore here is no code for manually evicting images from the cache when the ID changes. The main reason is that the AsyncPhoto instance does not have enough context for deciding this. For example, there might be other instances showing the photo for the old ID or maybe a moment later we want to display the photo for the old ID.

To recap, what we did. We defined an interface for caching images, created a NSCache based in-memory cache and hooked it up to the AsyncPhoto. We did all of this in a way that we did not need to change any existing code using AsyncPhoto instances.

There were some other tiny improvements, like using Task.isCancelled() to more quickly react to the ID change, setting the default placeholder colour to a light gray, and providing a default implementation for the content closure. Please check the example project for the full implementation. Here is the example project which reloads an avatar and as we can see at first, spinner is shown, but when images are cached, the change is immediate.

SwiftUIAsyncPhotoExample2 (GitHub, Xcode 15.1)

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Support me on Patreon

Donate with Paypal

Buy me a coffee

AsyncPhoto for displaying large photos in SwiftUI

While working on one of my private projects which deals with showing large photos as small thumbnails in a list, I found myself needing something like AsyncImage but for any kind of data sources. AsyncImage looks pretty great, but sad it is limited to loading images from URL. It has building blocks like providing placeholder and progress views. In my case, I needed something where instead of the URL argument, I would have an async closure which returns image data. This would give me enough flexibility for different cases like loading a photo from a file or even doing what AsyncImage is doing, loading image data from a server. I would love to know why Apple decided to go for a narrow use-case of loading images from URL but not for more generic approach. In addition, I would like to pre-define the target image size which allows me to scale the image to smaller size and therefore saving memory usage which would increase a lot when dealing with large photos. Enough talk, let’s jump in.

	struct AsyncPhoto<ID, Content, Progress, Placeholder>: View where ID: Equatable, Content: View, Progress: View, Placeholder: View {
	@State private var phase: Phase = .loading

	let id: ID
	let data: (ID) async -> Data?
	let scaledSize: CGSize
	@ViewBuilder let content: (Image) -> Content
	@ViewBuilder let placeholder: () -> Placeholder
	@ViewBuilder let progress: () -> Progress

	init(id value: ID = "",
	scaledSize: CGSize,
	data: @escaping (ID) async -> Data?,
	content: @escaping (Image) -> Content,
	progress: @escaping () -> Progress = { ProgressView() },
	placeholder: @escaping () -> Placeholder = { Color.secondary }) {
	// …
	}

view raw AsyncPhoto.swift hosted with ❤ by GitHub

The AsyncPhoto type is a generic over 4 types: ID, Content, Progress, Placeholder. Last three are SwiftUI views and the ID is equatable. This allows us for notifying the AsyncPhoto when to reload the photo by calling the data closure. Basically the same way as the task(id:priority:_:) is working – if the id changes, work item is run again. Since we expect to deal with large photos, we want to scale images before displaying them. Since the idea is that the view does not change the size while it is loading, or displaying a placeholder, we’ll require to pre-define the scaled size. Scaled size is used for creating a thumbnail image and also setting the AsyncPhoto’s frame view modifier to equal to that size. We use a data closure here for giving a full flexibility on how to provide the large image data.

AsyncImage has a separate type AsyncImagePhase for defining different states of the loading process. Since we need to do the same then, let’s add AsyncPhoto.Phase.

	extension AsyncPhoto {
	enum Phase {
	case success(Image)
	case loading
	case placeholder
	}
	}

view raw AsyncPhoto.Phase.swift hosted with ❤ by GitHub

This allows us to use a switch statement in the view body and defining a local state for keeping track of in which phase we currently are. The view body implementation is pretty simple since we use view builders for content, progress and placeholder states. Since we want to have a constant size here, we use the frame modifier and the task view modifier is the one managing scheduling the reload when id changes.

	var body: some View {
	VStack {
	switch phase {
	case .success(let image):
	content(image)
	case .loading:
	progress()
	case .placeholder:
	placeholder()
	}
	}
	.frame(width: scaledSize.width, height: scaledSize.height)
	.task(id: id, {
	await self.load()
	})
	}

view raw AsyncPhoto.swift hosted with ❤ by GitHub

The load function is updating the phase state and triggering the heavy load of scaling the image.

	@MainActor func load() async {
	phase = .loading
	if let image = await prepareScaledImage() {
	phase = .success(image)
	}
	else {
	phase = .placeholder
	}
	}

view raw AsyncPhoto.swift hosted with ❤ by GitHub

The prepareScaledImage is another function which wraps the work of fetching the image data and scaling it.

	private func prepareScaledImage() async -> Image? {
	guard let photoData = await data(id) else { return nil }
	guard let originalImage = UIImage(data: photoData) else { return nil }
	let scaledImage = await originalImage.scaled(toFill: scaledSize)
	guard let finalImage = await scaledImage.byPreparingForDisplay() else { return nil }
	return Image(uiImage: finalImage)
	}

view raw AsyncPhoto.swift hosted with ❤ by GitHub

I am using an UIImage extension for scaling the image data. The implementation goes like this:

	extension UIImage {
	func scaled(toFill targetSize: CGSize) async -> UIImage {
	let scaler = UIGraphicsImageRenderer(size: targetSize)
	let finalImage = scaler.image { context in
	let drawRect = size.drawRect(toFill: targetSize)
	draw(in: drawRect)
	}
	return await finalImage.byPreparingForDisplay() ?? finalImage
	}
	}

	private extension CGSize {
	func drawRect(toFill targetSize: CGSize) -> CGRect {
	let aspectWidth = targetSize.width / width
	let aspectHeight = targetSize.height / height
	let scale = max(aspectWidth, aspectHeight)
	let drawRect = CGRect(x: (targetSize.width – width * scale) / 2.0,
	y: (targetSize.height – height * scale) / 2.0,
	width: width * scale,
	height: height * scale)
	return drawRect.integral
	}
	}

view raw UIImageScaling.swift hosted with ❤ by GitHub

Here is an example of using AsyncPhoto from my test app, where I replaced photos with generated image data.

	// Example of returning large image with a constant color for simulating loading a photo.
	AsyncPhoto(id: selectedColor,
	scaledSize: CGSize(width: 48, height: 48),
	data: { selectedColor in
	guard let selectedColor else { return nil }
	return await Task.detached {
	UIImage.filled(size: CGSize(width: 5000, height: 5000),
	fillColor: selectedColor).pngData()
	}.value
	},
	content: { image in
	image.clipShape(Circle())
	},
	placeholder: {
	Image(systemName: "person.crop.circle")
	.resizable()
	})