Introduction

PhotoPicker discovery error: Error Domain=PlugInKit Code=13 is a log message that often appears when Apple’s picker infrastructure is starting, cancelling, or handing work back to your app. It looks alarming, but it is not always the real cause of the visible bug.

In practice, you usually need to debug the surrounding picker flow rather than treat PlugInKit Code 13 as the root problem by itself. The actual issue is often in result handling, presentation timing, simulator behavior, or photo-library access assumptions.

What the Message Usually Means

PlugInKit is part of the system machinery that supports extension-style services on Apple platforms. The Code=13 message is commonly reported as a “query cancelled” style discovery issue while the system is resolving picker-related services.

That means the message can show up even when the picker more or less works. If the user can open the picker, choose an item, and return to the app, the log line alone is not enough evidence that the picker API itself has failed.

A better framing is:

• the log may be noisy but harmless in some runs
• your app may still have a real bug in how it consumes the picker result
• simulator behavior can differ from real-device behavior

Use the Modern Photos Picker Correctly

Apple recommends the modern photos picker APIs for many selection flows. A simple PHPickerViewController setup looks like this:

1import UIKit
2import PhotosUI
3
4final class ViewController: UIViewController, PHPickerViewControllerDelegate {
5    func showPicker() {
6        var config = PHPickerConfiguration()
7        config.selectionLimit = 1
8        config.filter = .images
9
10        let picker = PHPickerViewController(configuration: config)
11        picker.delegate = self
12        present(picker, animated: true)
13    }
14
15    func picker(_ picker: PHPickerViewController, didFinishPicking results: [PHPickerResult]) {
16        picker.dismiss(animated: true)
17
18        guard let result = results.first else {
19            return
20        }
21
22        if result.itemProvider.canLoadObject(ofClass: UIImage.self) {
23            result.itemProvider.loadObject(ofClass: UIImage.self) { object, error in
24                guard let image = object as? UIImage else {
25                    print(error?.localizedDescription ?? "Image load failed")
26                    return
27                }
28
29                DispatchQueue.main.async {
30                    print("Loaded image size: \(image.size)")
31                }
32            }
33        }
34    }
35}

This keeps the flow explicit: present the picker, dismiss it, then load the selected object from the provider.

Why the Picker Log Is Often Misleading

Developers frequently chase the PlugInKit message when the real bug is elsewhere. Typical examples include:

• forgetting to implement the delegate callback correctly
• dismissing the picker at the wrong time
• failing to load the returned item provider object
• assuming full photo-library access is needed when using the system picker
• testing only on the simulator

For the modern picker path, you generally do not need full library permission just to let the user choose assets through the picker. But if your code later tries to query PHAsset metadata or read the library directly through PhotoKit, that is a different permission model.

Distinguish Picker Access from Library Access

This distinction matters a lot:

• picker-based access lets the user choose specific items through the system UI
• PhotoKit library access is broader and may require explicit authorization

If your app presents the picker successfully but then tries to fetch additional asset details through PhotoKit without the right authorization path, the app behavior may fail after selection even though the picker itself was fine.

Debug the Actual Flow Around the Error

A good debugging checklist is:

1. verify whether the picker appears normally
2. verify whether didFinishPicking is called
3. inspect whether results actually contains items
4. log errors from NSItemProvider loading
5. compare simulator and real-device behavior

If the picker opens and the delegate fires, your problem is probably not “extension discovery” in the abstract. It is likely in the code after the user makes a selection.

When the Simulator Is the Problem

Media pickers on Apple simulators do not always behave exactly like real devices, especially around asset formats, system services, and demo photo libraries. If the bug only appears in the simulator, test on a physical device before drawing conclusions.

That does not mean every simulator issue should be ignored, but it does mean you should separate true app logic bugs from environment quirks.

Common Pitfalls

One common mistake is treating the PlugInKit message itself as the full diagnosis. It is often only a symptom or even harmless log noise.

Another issue is assuming the picker grants unlimited access to the photo library. The system picker and direct PhotoKit access are related but not identical workflows.

It is also easy to forget to load the selected item from NSItemProvider. Selection finished does not mean the image is already in your app’s memory.

Finally, do not debug picker behavior only on the simulator if the problem touches media import, permissions, or system services. Real-device testing is essential.

Summary

• 'PlugInKit Code 13 around PhotoPicker is often a log message, not a full diagnosis by itself.'
• The real bug is commonly in result handling, permission assumptions, or environment differences.
• Use the modern picker flow correctly and load selected data through the item provider.
• Distinguish between system picker access and direct PhotoKit library access.
• Verify behavior on a real device before concluding that the picker API itself is broken.