YPImagePicker: an Instagram-style photo and video picker for iOS apps

The gap YPImagePicker fills between UIImagePickerController and a custom camera screen

The stock iOS pickers cover selection well and editing poorly. UIImagePickerController gives you a system camera or a library browser, and PHPickerViewController gives you out-of-process library access, but neither gives you a filter carousel, a square crop step, a video trimmer with cover frame selection, or multi-select with a selection gallery. Building those yourself means writing an AVFoundation capture session, a PHPhotoLibrary fetch layer, a crop gesture handler and an export pipeline, then keeping all of it working across iOS releases.

YPImagePicker is aimed at teams that want that stack already assembled. The README describes it as an "instagram-like photo/video picker for iOS written in pure Swift", and the notable features list is the shape of the product: library, photo, video, crop, flash, filters, albums, multiple selection, video trimming and cover selection, and output image size. The API surface is one screen stack configured by a single struct, which is the actual selling point. If your app already has its own camera UI, this library is competing with code you have written, not with a missing capability.

How the picker is wired: one configuration struct, one callback

Everything routes through YPImagePickerConfiguration, a struct whose fields the README lists with their defaults. The top level controls the shell: config.screens decides which tabs exist (the default is [.library, .photo]), config.startOnScreen picks the initial tab, config.showsPhotoFilters and config.showsVideoTrimmer toggle the two heaviest sub-flows, and config.showsCrop takes a crop mode. Nested structs split the rest by concern. config.library holds selection rules such as mediaType, maxNumberOfItems and numberOfItemsInRow. config.video holds recordingTimeLimit, minimumTimeLimit and the trimmer bounds. config.gallery holds hidesRemoveButton.

The data flow is deliberately narrow. You build a YPImagePicker with a configuration, present it, and receive everything through the single didFinishPicking callback. Items arrive as a collection with a singlePhoto accessor, and each photo exposes fromCamera, image, originalImage and modifiedImage. That last pair is the important distinction: originalImage is what the user picked before filters, modifiedImage is the transformed result and can be nil. If you need the untouched asset for your own server-side processing, you have it; if you need what the user saw, you have that too.

The configuration is also settable globally. Assigning to YPImagePickerConfiguration.shared makes every subsequently constructed YPImagePicker inherit those values, which is convenient for an app with one consistent capture flow and awkward for an app that wants a different picker per feature. There is no documented per-instance override of the shared value beyond constructing with an explicit configuration.

Installing YPImagePicker with CocoaPods or Swift Package Manager

CocoaPods is the path the README puts first, and it asks you to refresh the spec repo before adding the pod, since the podspec lives in the central repo.

pod repo update
pod install

Your Podfile needs the pod plus use_frameworks!, because this is a Swift framework rather than a static library.

# Podfile
target 'MyApp'
pod 'YPImagePicker'
use_frameworks!

The README also offers a throwaway demo target: running pod repo update and then pod try YPImagePicker clones and opens the sample project so you can click through the picker before integrating it. For Swift Package Manager, add the repository URL through File > Swift Packages > Add Package Dependency, or declare it in your own Package.swift.

.package(
name: "YPImagePicker",
url: "https://github.com/Yummypets/YPImagePicker.git",
.upToNextMajor(from: "5.0.0")
)

The README notes a minimum target of iOS 12.0 for the SPM path. Before the picker can run at all, three privacy usage descriptions must be in your Info.plist: camera, photo library and microphone. The README gives the keys and placeholder strings.

<key>NSCameraUsageDescription</key>
<string>yourWording</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>yourWording</string>
<key>NSMicrophoneUsageDescription</key>
<string>yourWording</string>

A first real use is short. Build a configuration, construct the picker, and handle the single callback.

import YPImagePicker

var config = YPImagePickerConfiguration()
config.screens = [.library, .photo]
config.library.maxNumberOfItems = 4

let picker = YPImagePicker(configuration: config)
picker.didFinishPicking { items, _ in
    if let photo = items.singlePhoto {
        print(photo.fromCamera)
    }
}

If the camera tab opens and the photo tab shows your library, the three Info.plist keys are in place and the framework linked. A blank or immediately dismissing camera screen usually means the usage description string is missing.

Where YPImagePicker gets in the way

The library owns the whole capture and selection experience, and that is the limitation as much as the feature. If your app needs a custom camera overlay with live guidance, or a selection grid that matches a design system the picker does not know about, you are fighting the configuration surface rather than extending it. The README's UI Customization section is referenced in the table of contents but the configuration fields shown are colours, fonts, overlay view and status bar behaviour. That is a skin, not a plugin architecture.

iPad is a documented rough edge. The README states that on iPad the picker supports one size only, and that you should set YPImagePickerConfiguration.widthOniPad before displaying it, then present it with that preferred content size in a dialog or popup. Nothing in the README describes what happens if you present it full screen on iPad instead. Treat the iPad path as something you configure deliberately, not something that works by default.

Permission handling is also yours. The README lists the three Info.plist keys but does not document what the picker does when the user has already denied camera access, or how to route them to Settings. If your app has a permission pre-prompt flow, plan to reconcile it with the picker's own first-run prompt. And the minimum target of iOS 12.0 is stated only for the SPM path, so confirm the deployment target your CocoaPods integration resolves to before you assume it matches.

YPImagePicker versus PHPickerViewController and DKImagePickerController

PHPickerViewController is Apple's out-of-process picker. It runs in a separate process, so the user can select photos without granting your app library access at all, and it needs no photo library usage description. If your requirement is "let the user attach an existing photo", PHPickerViewController does it with less permission surface and less code. It does not give you a camera with filters, a crop step, or a video trimmer, which is exactly the ground YPImagePicker occupies. The two are not substitutes; they answer different questions.

DKImagePickerController is the closer comparison, another third-party picker with multi-select and album browsing. The difference in approach is scope. YPImagePicker bundles capture, filtering and video trimming into the same flow and exposes them through one configuration struct and one callback, while a picker built around selection keeps the capture side out of the library. If you need filtering and trimming, the integrated flow saves you wiring two libraries together. If you only need selection, the integrated flow is extra surface you will never configure.

There is no Android story here. The related searches show people asking for YPImagePicker on Android, and the answer is that this is a Swift iOS library; the repository contains a podspec, an Xcode project and a Package.swift, and nothing else. For Android you are looking at a different project entirely.

Maintenance, releases and what the MIT licence means for you

The repository is not archived and the last push was on 2026-07-28, which is recent. Release 5.4.0 landed the same day and its title mentions stability, performance and a privacy manifest. That last item matters: Apple requires privacy manifests for certain APIs, and a picker that touches the photo library and camera is exactly the kind of dependency that triggers the requirement. Earlier releases show 5.3.2 for CocoaPods support and 5.3.1 for iOS 26 support, so the project has been tracking platform changes rather than sitting still.

Upgrade cost is the usual Swift dependency cost. Major versions can change the configuration struct, and because the picker is presented modally and configured before presentation, a breaking change in YPImagePickerConfiguration shows up as a compile error rather than a runtime surprise. That is a favourable failure mode. The bigger cost is behavioural: if a release changes default screens or filter sets, your users see a different capture flow without any code change on your side. Pinning the version and reading the release notes before bumping is the cheap insurance here.

The licence is MIT. In practical terms that permits commercial and closed-source use, modification and redistribution provided the copyright notice and permission notice are included. This is not legal advice; if your organisation has a dependency review process, route the LICENSE file through it rather than treating this paragraph as clearance. A permissive licence also means no support contract, so the release cadence you see in the repository is the only maintenance guarantee you get.

Editorial conclusion

Adopt YPImagePicker if you are shipping a native iOS app in Swift and want the camera, library, crop, filter and video trim flow in one screen stack, and you are willing to own the Info.plist privacy strings and the iPad sizing yourself. Do not adopt it if you need Android, or if you only need to select an existing asset and PHPickerViewController already covers that with no permission prompt. Before you commit, verify the minimum deployment target against your own, check that the three privacy usage descriptions are present in your Info.plist, and confirm on a real iPad that setting YPImagePickerConfiguration.widthOniPad produces the dialog size you want.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Yummypets/YPImagePicker on GitHub