Introduction

App version details are often shown on a settings screen, attached to crash reports, or included in support logs. In Swift, that information usually comes from the app bundle, specifically the values stored in Info.plist.

Where Version And Build Values Come From

Two keys matter most:

• 'CFBundleShortVersionString is the marketing version seen by users, such as 2.4.1.'
• 'CFBundleVersion is the internal build number, often incremented every release or CI run.'

Both values live in the main application bundle, so you can read them through Bundle.main. That keeps the information in one place instead of hard-coding version strings throughout the app.

Reading The Values In Swift

The simplest solution is a small helper that reads both keys and returns safe fallback values if the keys are absent.

1import Foundation
2
3enum AppInfo {
4    static var version: String {
5        Bundle.main.object(forInfoDictionaryKey: "CFBundleShortVersionString") as? String ?? "0.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 \(version) (\(build))"
14    }
15}
16
17print(AppInfo.fullVersion)

This approach is better than force-casting because missing or malformed bundle values will not crash the app. A support screen can show AppInfo.fullVersion, while logging code can record version and build separately.

Showing Version Information In The UI

Once the helper exists, displaying the value is straightforward. Here is a small SwiftUI example:

1import SwiftUI
2
3struct AboutView: View {
4    var body: some View {
5        VStack(spacing: 8) {
6            Text("MyApp")
7                .font(.title2)
8            Text(AppInfo.fullVersion)
9                .foregroundColor(.secondary)
10        }
11        .padding()
12    }
13}

The same pattern works in UIKit:

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

Keeping the formatting in one helper prevents different screens from showing slightly different version strings.

Using Version Data In Logging And Diagnostics

Version information is not just for display. It is useful whenever you need to correlate runtime behavior with a specific release. A common pattern is to log it once during app startup:

1import os
2
3let logger = Logger(subsystem: "com.example.myapp", category: "startup")
4logger.info("Starting app version \(AppInfo.version, privacy: .public) build \(AppInfo.build, privacy: .public)")

That makes support investigations easier because bug reports can be tied to an exact app build. If you use analytics or crash reporting SDKs, pass the same values into their metadata APIs so every event is tagged consistently.

Main Bundle Versus Other Bundles

One subtle detail is bundle selection. Bundle.main refers to the app bundle, which is correct for most iOS and macOS apps. If the code lives in a framework or test target, the relevant version information may be stored in a different bundle.

For example, a reusable framework might need:

let frameworkBundle = Bundle(for: SomeFrameworkClass.self)
let frameworkVersion = frameworkBundle.object(forInfoDictionaryKey: "CFBundleShortVersionString") as? String

That distinction matters in modular projects. Otherwise you may accidentally display the host app version when you intended to read a framework version.

Common Pitfalls

• Confusing CFBundleShortVersionString with CFBundleVersion. One is the user-facing release number, the other is the internal build number.
• Force-casting bundle values. Missing keys should not crash the app.
• Reading from Bundle.main inside a framework when the data actually lives in the framework bundle.
• Hard-coding version strings in code or UI labels. The bundle should stay the single source of truth.
• Forgetting to update the build number in release automation, which makes support and crash triage harder.

Summary

• In Swift, version and build metadata usually comes from Info.plist.
• Use Bundle.main.object(forInfoDictionaryKey:) to read CFBundleShortVersionString and CFBundleVersion.
• Wrap the lookup in a small helper so UI and logging code stay consistent.
• Be careful about which bundle you read from in frameworks, extensions, and tests.