Introduction

In modern Apple platform code, the real conversion is usually from UIImage to Data, because Swift uses Data as the primary binary buffer type. NSData still appears in older Objective-C APIs and bridged frameworks, but you normally create Data first and bridge to NSData only when an API requires it.

Choose PNG or JPEG Representation

A UIImage does not automatically expose raw bytes in a storage-ready format. You first have to encode it into a concrete format such as PNG or JPEG.

For PNG:

1import UIKit
2
3let image = UIImage(named: "avatar")!
4if let data = image.pngData() {
5    let nsData = data as NSData
6    print(nsData.length)
7}

For JPEG:

1import UIKit
2
3let image = UIImage(named: "photo")!
4if let data = image.jpegData(compressionQuality: 0.8) {
5    let nsData = data as NSData
6    print(nsData.length)
7}

The important difference is that PNG is lossless, while JPEG is lossy but often much smaller for photos.

When to Prefer JPEG Versus PNG

Use PNG when the image has transparency, sharp edges, text, or assets where exact reproduction matters. Use JPEG when the image is photographic and file size matters more than perfect pixel preservation.

That format decision is usually more important than the Data to NSData bridge itself. The bridge is trivial. The encoding choice affects quality, upload size, storage cost, and decode behavior later.

Bridging Between Data and NSData

Swift bridges these types automatically.

let data: Data = image.pngData()!
let nsData: NSData = data as NSData
let bridgedBack: Data = nsData as Data

If you are working with Swift-first code, keep the value as Data as long as possible. Only bridge to NSData when you call an API that explicitly expects Foundation’s Objective-C type.

Be Careful with Image Size and Memory

Encoding a large UIImage creates a full binary representation in memory. If the image came from the camera or photo library, that can be much larger than expected. In upload flows, it is common to resize or recompress first.

if let jpegData = image.jpegData(compressionQuality: 0.6) {
    // upload or store compressed data
}

If you skip this step for large photos, the app can waste bandwidth and memory even though the conversion code itself is correct.

Common Misunderstanding: data(using:)

Developers sometimes search for a generic data(using:) conversion because that method exists on String. UIImage does not use data(using:) for image encoding. The correct APIs are pngData() and jpegData(compressionQuality:).

That is a small but important distinction. A string-to-bytes conversion is not the same as image compression and format encoding.

Common Storage and Upload Flow

A typical workflow is: pick or generate the image, resize it if needed, encode it as JPEG or PNG, keep it as Data in Swift code, and only bridge to NSData when an older API requires it. That keeps the conversion logic explicit and avoids unnecessary Foundation bridging at every step.

For example, upload code usually wants a Data payload first and treats NSData as an implementation detail rather than the application-level type.

Common Pitfalls

• Treating UIImage to NSData as a direct cast instead of encoding the image first.
• Using PNG for large photos when JPEG would be much smaller.
• Using JPEG when transparency must be preserved.
• Keeping values as NSData everywhere in Swift instead of using Data until bridging is necessary.
• Forgetting that large images may need resizing or recompression before storage or upload.

Summary

• Convert UIImage by encoding it as PNG or JPEG first.
• In Swift, Data is the main binary type and bridges easily to NSData.
• Use pngData() for lossless output and transparency support.
• Use jpegData(compressionQuality:) when size matters and lossy compression is acceptable.
• The important design choice is usually the image format, not the Data to NSData bridge.