Introduction

On iOS, the build version and the marketing version are not the same thing. If you want to show version info in a debug screen, attach it to bug reports, or log it at startup, you usually read CFBundleVersion for the build number and CFBundleShortVersionString for the user-facing release version.

Read Version Values From Info.plist

The app bundle exposes its metadata through Bundle.main. The keys you usually want are:

• 'CFBundleVersion for the build number'
• 'CFBundleShortVersionString for the release version'

In Swift:

1import Foundation
2
3let build = Bundle.main.object(forInfoDictionaryKey: "CFBundleVersion") as? String
4let version = Bundle.main.object(forInfoDictionaryKey: "CFBundleShortVersionString") as? String
5
6print("Build:", build ?? "unknown")
7print("Version:", version ?? "unknown")

This is the most direct way to access the values that Xcode writes into the app bundle.

Wrap the Logic in a Helper

Instead of scattering string keys around the app, wrap them in a small helper:

1import Foundation
2
3enum AppVersion {
4    static var build: String {
5        Bundle.main.object(forInfoDictionaryKey: "CFBundleVersion") as? String ?? "unknown"
6    }
7
8    static var release: String {
9        Bundle.main.object(forInfoDictionaryKey: "CFBundleShortVersionString") as? String ?? "unknown"
10    }
11
12    static var displayString: String {
13        "\(release) (\(build))"
14    }
15}
16
17print(AppVersion.displayString)

This makes it easy to reuse the information in settings screens, support emails, diagnostics, and crash reports.

Show It in SwiftUI or UIKit

For SwiftUI:

1import SwiftUI
2
3struct AboutView: View {
4    var body: some View {
5        Text("Version \(AppVersion.displayString)")
6    }
7}

For UIKit:

versionLabel.text = "Version \(AppVersion.displayString)"

The values are static for the running build, so reading them once and exposing them through a helper is usually enough.

Understand the Difference Between Build and Release Version

Developers often mix these values up:

• 'CFBundleShortVersionString is what users think of as the app version, such as 2.4.1'
• 'CFBundleVersion is the internal build number, such as 2410'

The App Store expects the build number to increase for each uploaded build of a given release version. That is why support teams often ask for both values rather than only one.

Objective-C Version

If you are maintaining older iOS code, the same data is available in Objective-C:

1NSString *build = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleVersion"];
2NSString *version = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleShortVersionString"];
3
4NSLog(@"Version %@ (%@)", version, build);

The source is the same Info.plist; only the syntax changes.

Make It Visible in Diagnostics

Reading the values is only half the job. The real benefit comes when you include them in places where support and engineering can actually see them, such as:

• An in-app debug screen
• Startup logs
• Crash-report metadata
• Support emails generated from the app

That makes it much easier to distinguish "the user is on release 2.3" from "the user is on build 2415 of release 2.3."

Common Pitfalls

• Reading only CFBundleShortVersionString when you really need the internal build number makes bug reports less precise.
• Hardcoding version strings in UI code guarantees they will drift from the actual app metadata.
• Misspelling the Info.plist keys returns nil, so wrap access safely.
• Assuming TestFlight, App Store, and local debug builds all share the same versioning behavior can create confusion if the build number is not being incremented properly in Xcode or CI.

Summary

• Use Bundle.main to read version metadata from Info.plist.
• 'CFBundleVersion is the build number; CFBundleShortVersionString is the release version.'
• Wrap the lookup in a helper so the app uses one consistent source of truth.
• Show both values when you need support-friendly diagnostics.