Introduction

If your app logs an access error like [access] <private> when presenting UIImagePickerController, the root cause is usually privacy configuration, not the picker itself. Starting in iOS 10, Apple made camera and photo library access fail fast when usage description keys are missing. The fix is a combination of correct Info.plist entries and a permission flow that checks authorization before presentation.

Why This Error Appears on iOS 10

Before iOS 10, many apps could rely on weaker runtime checks and still work in testing. iOS 10 changed the contract. If your app touches camera or photo library APIs without a matching privacy usage string, the system denies access and may terminate the process.

UIImagePickerController can open either the camera or the photo library. Each source type has its own privacy requirement. In practice, that means your app must declare the reason for camera use and photo library use separately, even if your UI exposes one button.

The crash or access warning also appears when code paths are hidden behind conditional logic. A common case is opening the camera on one device and the photo library on another. If one key is missing, that path fails only on certain devices, so the issue appears random.

Required Info.plist Keys

At minimum, include the usage description keys that match all possible source types you present. Keep the message human and specific so users understand why you ask for access.

1<key>NSCameraUsageDescription</key>
2<string>We need camera access so you can take profile photos.</string>
3<key>NSPhotoLibraryUsageDescription</key>
4<string>We need photo library access so you can choose existing images.</string>
5<key>NSPhotoLibraryAddUsageDescription</key>
6<string>We need permission to save edited photos to your library.</string>

NSPhotoLibraryAddUsageDescription is only required when you save back into the library. If your app only reads images, the first two keys are typically enough. Still, teams often add all three to prevent future regressions when save functionality is introduced.

Safe Runtime Permission Flow in Swift

A stable approach is to check capability and authorization before presenting the picker. This keeps the flow deterministic and gives users a clear recovery path.

1import UIKit
2import Photos
3
4final class PhotoController: UIViewController, UIImagePickerControllerDelegate, UINavigationControllerDelegate {
5    private let picker = UIImagePickerController()
6
7    override func viewDidLoad() {
8        super.viewDidLoad()
9        picker.delegate = self
10    }
11
12    @IBAction func chooseFromLibrary() {
13        let status = PHPhotoLibrary.authorizationStatus(for: .readWrite)
14        switch status {
15        case .authorized, .limited:
16            presentLibraryPicker()
17        case .notDetermined:
18            PHPhotoLibrary.requestAuthorization(for: .readWrite) { [weak self] newStatus in
19                DispatchQueue.main.async {
20                    if newStatus == .authorized || newStatus == .limited {
21                        self?.presentLibraryPicker()
22                    } else {
23                        self?.showPermissionAlert(resource: "Photo Library")
24                    }
25                }
26            }
27        default:
28            showPermissionAlert(resource: "Photo Library")
29        }
30    }
31
32    private func presentLibraryPicker() {
33        guard UIImagePickerController.isSourceTypeAvailable(.photoLibrary) else {
34            return
35        }
36        picker.sourceType = .photoLibrary
37        present(picker, animated: true)
38    }
39
40    private func showPermissionAlert(resource: String) {
41        let alert = UIAlertController(
42            title: "Permission Needed",
43            message: "Enable \(resource) access in Settings to continue.",
44            preferredStyle: .alert
45        )
46        alert.addAction(UIAlertAction(title: "Cancel", style: .cancel))
47        alert.addAction(UIAlertAction(title: "Open Settings", style: .default) { _ in
48            guard let url = URL(string: UIApplication.openSettingsURLString) else { return }
49            UIApplication.shared.open(url)
50        })
51        present(alert, animated: true)
52    }
53}

This pattern avoids presenting a picker that cannot read data. It also handles denied and restricted states instead of silently failing.

Common Pitfalls

The first pitfall is adding only one usage key. For example, teams add NSCameraUsageDescription and forget NSPhotoLibraryUsageDescription, then the library path fails in production.

The second pitfall is requesting authorization too late. If the picker is presented before permission is granted, users see broken behavior. Always request and validate first, then present.

Another frequent issue is unclear permission copy. If the string is vague, users deny access more often. Use concrete language tied to a visible user action, such as taking a receipt photo or selecting an avatar image.

Finally, developers sometimes test only on simulators where camera behavior differs from real devices. Run the full flow on physical hardware and test both granted and denied states.

Summary

• iOS 10 enforces privacy declarations for camera and library access.
• UIImagePickerController needs matching Info.plist usage keys for every source type you use.
• Check authorization before presenting the picker to avoid runtime failures.
• Provide a clear Settings recovery path when access is denied.
• Test permission flows on real devices with multiple authorization states.