HXPhotoPicker for iOS: Live Photo, GIF and iCloud Selection in Swift

What HXPhotoPicker replaces in a Swift app

Apple ships UIImagePickerController and PHPickerViewController, and both are deliberate about doing one thing. UIImagePickerController gives you a single item and an aging interface. PHPickerViewController runs out of process, which is good for privacy and bad for anything that needs to read a Live Photo pair or fetch an asset that lives only in iCloud. HXPhotoPicker exists to fill that gap. The README describes it as a picker that supports LivePhoto, GIF selection, 3DTouch preview, downloading iCloud resources online, editing images and videos, and browsing network images. It lists iOS, iPadOS and Mac Catalyst as targets, and the repository topics include photokit, uiimagepickercontroller and phpicker, which places it in the same slot as Apple's own controllers rather than beside them. The audience is narrow and clear: Swift developers building a chat app, a social client, a note-taking tool or anything else where the user attaches media and expects it to behave the way it does in a mature consumer app. The README's own framing is an imitation of the WeChat picker, and that is the honest description of the product category.

The media types it actually handles, and how selection flows

The feature list separates three groups. Media types are Photo, GIF, Live Photo and Video. Local resource types are the same four. Network resource types are Photo and Video only, which means a remote GIF or a remote Live Photo is not in scope. The picker reads from the photo library and returns results through three documented paths. The first is async/await: Photo.picker(config) or PhotoPickerController.picker(config) returns a result that can be converted to [UIImage], [URL], [AssetURLResult] or [AssetResult]. The second is a delegate, PhotoPickerControllerDelegate, whose pickerController(_:didFinishSelection:) receives a PickerResult carrying photoAssets and an isOriginal flag. The third is a completion closure passed to Photo.picker(config), with a cancel closure alongside it. The result object exposes getImage with a per-asset callback and a completion handler, so you can render thumbnails as they arrive instead of waiting for the whole batch. That is the mechanism: one configuration object, three entry points, and a result type that can be asked for images, file URLs, or asset-level detail depending on what the caller needs. Because Live Photo and GIF are first-class media types rather than special cases, the caller has to decide which representation to request, and the README does not spell out what each conversion does to a Live Photo pair.

Installing HXPhotoPicker with Swift Package Manager or CocoaPods

The README documents two installation routes. Swift Package Manager needs Xcode 13.0 or later, and the README flags this explicitly because resource files and localization files have to be added, which older tooling does not handle. The dependency line pins to 5.0.5 or later within the same major version.

dependencies: [
    .package(url: "https://github.com/SilenceLove/HXPhotoPicker.git", .upToNextMajor(from: "5.0.5"))
]

CocoaPods is the more granular option, and it is where the real decision lives. The bare pod pulls the default build, which the README says does not support GIF or network images on iOS 10 by default. To get those, you pick a loading library: SwiftyGif, SDWebImage or Kingfisher v6.0.0. There are also subspecs that trim the dependency to one component: HXPhotoPicker/Picker, HXPhotoPicker/Editor, HXPhotoPicker/Camera, HXPhotoPicker/Camera/Lite for a camera without location, and HXPhotoPicker/NoLocation. An Objective-C version for v4.0 and below lives under HXPhotoPickerObjC.

pod 'HXPhotoPicker'
pod 'HXPhotoPicker/SDWebImage'
pod 'HXPhotoPicker/Picker'

Before any of that runs, Info.plist needs the usage strings the README tabulates. NSPhotoLibraryUsageDescription and NSPhotoLibraryAddUsageDescription belong to the Picker module. PHPhotoLibraryPreventAutomaticLimitedAccessAlert set to YES on iOS 14 or later suppresses the automatic prompt asking to add more photos, because the picker already handles Limited access and lets the user trigger the expansion. NSCameraUsageDescription and NSMicrophoneUsageDescription belong to the Camera module. A first real call looks like the README's quick-start example: build a PickerConfiguration, pass it to Photo.picker, and read the result.

import HXPhotoPicker

let config = PickerConfiguration.default
let images: [UIImage] = try await Photo.picker(config)

If the call returns, you get an array of images; if the user cancels, the async version throws rather than returning an empty array, which is a detail worth handling explicitly.

Where HXPhotoPicker is the wrong tool

The clearest limitation is platform. The README lists iOS, iPadOS and Mac Catalyst. There is no Android target, no web target, and no server-side component. The related searches include "Hxphotopicker android", which suggests people arrive looking for something the repository does not offer. The second limitation is dependency weight. Choosing HXPhotoPicker/SDWebImage or HXPhotoPicker/Kingfisher means the picker's image loading is tied to a library you may already use, and if your app standardizes on a different one, you are either adding a second image cache or accepting the default build without GIF and network image support. The third is the editing surface. The README lists a long set of image and video editing operations, including doodle, stickers, text, crop, arbitrary-angle rotation, custom masks, mosaic, adjustments and filters, plus music with lyric subtitles for video. That is a lot of UI to inherit, and the README does not describe how to remove individual editing tools or replace the editor's chrome. If you need a picker and nothing else, HXPhotoPicker/Picker exists, but the documentation does not explain what the trimmed subspec still pulls in. Finally, the project is a single-maintainer repository under SilenceLove, with releases spaced months apart. The last push was on 2026-06-10, and the most recent release listed is 5.0.5 on 2025-12-01. That is not abandonment, but it does mean a bug in a new iOS release waits for the maintainer rather than for you.

How it compares with ZLPhotoBrowser and GKPhotoBrowser

The related searches name ZLPhotoBrowser and GKPhotoBrowser, and both are reasonable comparison points because they occupy adjacent slots. ZLPhotoBrowser is a picker and browser in the same family, and the practical difference is scope: HXPhotoPicker documents a video editor with music and lyric subtitles, and a network image browser alongside the picker, so it is closer to a media suite than a single screen. GKPhotoBrowser is oriented around browsing and viewing images, which is a different job from selecting and editing them. If your requirement is only to display a full-screen image viewer with gestures, a browser-only library is the smaller dependency. If your requirement is to attach media with the editing and iCloud behavior a consumer app expects, HXPhotoPicker covers more ground in one package. The cost of that coverage is the configuration surface: PickerConfiguration is a single object that governs appearance, selection limits, media types and the editor, and the README does not enumerate its fields.

Licence, upgrade cost and what the repository does not say

HXPhotoPicker is MIT licensed, and the README carries the MIT badge. MIT permits commercial and closed-source use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive arrangement, and it is the same licence the CocoaPods ecosystem expects. It is not legal advice, and if your organization has a policy on attribution in shipped binaries, that policy is the thing to check, not this paragraph. On upgrade cost, the version history is instructive: 5.0.3 in July 2025, 5.0.4 in September 2025, 5.0.5 in December 2025. Three patch releases in roughly five months, with no major version change in that window. The README's SPM example pins with .upToNextMajor, so patch and minor updates arrive automatically and major ones do not. The README does not document a migration guide between 5.x releases, and it does not document rollback. If you pin with CocoaPods instead, the podspec and Podfile.lock in the repository show that the project itself uses CocoaPods for its example app, so the pod route is exercised by the maintainer's own build.

Editorial conclusion

Adopt HXPhotoPicker if you are shipping a Swift app on iOS 10 or later and need a picker that already understands Live Photos, GIFs, iCloud assets and in-app editing, and you are willing to depend on a single maintainer. Do not adopt it if you need the picker to keep working after the underlying photo library changes without a release, or if you are building on Android, where the related searches point but the repository does not go. Before committing, verify two things against your own project: that your Xcode version satisfies the SPM requirement of Xcode 13.0 or later for resource and localization files, and that the CocoaPods subspec you pick matches the image loading library you already ship, since HXPhotoPicker/SDWebImage, HXPhotoPicker/Kingfisher and HXPhotoPicker/SwiftyGif are separate choices rather than a default.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SilenceLove/HXPhotoPicker on GitHub