Introduction

Reading the app version and build number in Swift is useful for settings screens, support diagnostics, analytics, and crash reporting. These values live in the app bundle metadata, so you should read them from the bundle rather than hardcoding them in the UI.

On Apple platforms, two keys matter most: CFBundleShortVersionString for the user-visible version and CFBundleVersion for the internal build number. A small helper keeps the lookup logic centralized and avoids copy-pasted bundle access across the app.

Read the Version and Build From the Bundle

The simplest approach is to query Bundle.main:

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

The fallback values prevent crashes if the bundle metadata is unexpectedly missing.

Know the Difference Between Version and Build

These two values serve different purposes:

• 'CFBundleShortVersionString is the marketing version users see, such as 2.4.1'
• 'CFBundleVersion is the internal build number, such as 145'

Support screens, bug reports, and analytics are usually better when they show both values, not only one of them.

Show Version Info in the UI

A settings or diagnostics screen is a natural place to surface the information:

1import UIKit
2
3final class SettingsViewController: UIViewController {
4    @IBOutlet private weak var versionLabel: UILabel!
5
6    override func viewDidLoad() {
7        super.viewDidLoad()
8        versionLabel.text = "Version \(AppInfo.fullVersion)"
9    }
10}

This makes it easier for support teams and testers to confirm exactly which build is installed.

It also helps during staged rollouts and TestFlight validation, where two builds may share the same marketing version but differ in internal build number and therefore in behavior.

Include Version Metadata in Logs or Requests

Version information is also useful in telemetry and backend debugging:

let userAgent = "MyApp/\(AppInfo.version) (build \(AppInfo.build); iOS)"
print(userAgent)

Or in a request header:

1import Foundation
2
3var request = URLRequest(url: URL(string: "https://api.example.com/ping")!)
4request.setValue(AppInfo.fullVersion, forHTTPHeaderField: "X-App-Version")

When backend logs include version metadata, it becomes much easier to correlate issues with a specific release.

Keep the Lookup Centralized and Testable

Direct Bundle.main access sprinkled throughout the app makes testing and refactoring harder. A small abstraction helps:

1import Foundation
2
3protocol InfoProvider {
4    func value(for key: String) -> String?
5}
6
7struct BundleInfoProvider: InfoProvider {
8    func value(for key: String) -> String? {
9        Bundle.main.object(forInfoDictionaryKey: key) as? String
10    }
11}

That kind of indirection is useful if you want deterministic unit tests or platform-specific bundle strategies later.

Common Pitfalls

The biggest mistake is hardcoding version text in the UI. That drifts out of sync with the build system sooner or later.

Another common issue is confusing the marketing version with the build number and showing only one when support really needs both.

People also force-unwrap bundle values and assume the keys can never be missing. A helper with safe fallbacks is usually better.

Finally, if CI increments the build number automatically, make sure your app is reading the bundle values and not a stale constant from elsewhere in the codebase.

Summary

• Read version metadata from the app bundle instead of hardcoding it.
• Use CFBundleShortVersionString for the user-visible version and CFBundleVersion for the build number.
• Centralize the lookup in a small helper for reuse and safety.
• Show both values in support-facing UI and diagnostics.
• Include version metadata in logs or request headers when release tracking matters.