# AnyImageKit: a Swift toolbox for picking, editing and capturing media

> AnyImageKit is a Swift library that gives an iOS app a photo and video picker, a capture screen and an image editor, in a modular design of four modules, three of which are finished, with the theme, localisation and light or dark appearance handled for you. It is MIT licensed and actively pushed, but the README checklist shows how much of the vision is still open, including the Browser module, emoji and filters, and native macOS.

**AnyImageKit/AnyImageKit** — A toolbox for pick/edit/capture photo or video. Written in Swift. 

- Repository: https://github.com/AnyImageKit/AnyImageKit
- Stars: 786 · Forks: 105
- Language: Swift
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/anyimagekit-anyimagekit

## A toolbox rather than a single component

AnyImageKit is described as a toolbox for picking, editing or capturing photos and videos, written in Swift. The modular design is the first item in the feature list, and the modules are Picker, Browser, Editor and Capture.

Three of those four are marked as done. Browser is the exception, and it is left unchecked in the README, which tells you the project set out to include a general media browsing surface and has not finished it. That single unchecked box is a fair summary of how to read the rest of the checklist: it is a live status board rather than a marketing page.

The Picker module covers the supported media types, which are photo, GIF, Live Photo and video, and supports multiple and mix selection, meaning a user can pick photos and videos together in one session. The Capture module covers taking photos and recording video.

The whole set supports light mode, dark mode or auto mode, and the default theme is described as similar to WeChat. That is a specific design reference rather than an aesthetic claim, and for an audience building consumer apps in that style it saves a design pass.

The implementation is Swift, the licence is MIT, and the default branch is master. The repository is not archived and the last push was on 2026-10-15, so the project is still receiving work even though the published releases are older.

The audience is iOS developers who need media selection and editing that looks finished, and who would otherwise build several view controllers and a theme from scratch.

## What the editor does, and what it leaves out

The image editor is labelled Technical Preview in the README, and its checklist is worth reading closely.

Implemented are drawing, input text, cropping, mosaic and rotate. That is a workable annotation editor: draw freehand on a photo, stamp text on it, crop to a region, blur out something with the mosaic tool, or correct an angle. For a messaging app or a social post composer, those five operations cover the large majority of what users actually ask for.

Not implemented are emoji and filter support. Emoji is a smaller omission, since a text tool plus a keyboard gets you most of the way, but filters are a visible gap. Filters are the feature that makes an editor feel modern, and their absence is the first thing a user may notice.

The same pattern repeats in the camera section. Photo and video capture are done, while Live Photo capture, GIF capture and filter support are not. So the library can pick a Live Photo and a GIF from the library, but it cannot capture either of them.

Taken together, the editor is a preview: the core transformations are there and the decorative layer is not. That is a coherent scope for a library, but it means the finished-product decision rests with the adopting app. If your design calls for filter thumbnails, you will be writing that view yourself.

## Platform coverage stops at iOS and iPadOS

The platform checklist is where a team integrating this will hit the hardest boundary.

Supported are iOS, iPadOS and Mac Catalyst, and the Mac Catalyst entry carries a caveat: it is marked Technical Preview and not supported in editor. So on a Mac Catalyst build of your app, the picker and capture work, and the editor does not. For an app that ships iPad and Mac versions from one codebase, that is a feature-level difference between platforms inside a single binary, and it is the kind of thing that has to be handled deliberately rather than discovered during testing.

Native macOS and tvOS are both unchecked, so there is no Apple silicon native target and no tvOS target in this repository.

The requirements are iOS 13.0 or newer, Xcode 14.1 or newer and Swift 5.7 or newer. Those are the stated minimums at the time of writing, and the release notes table shows the toolchain moving with each version: the 0.18.x line from 2024 onwards lists Xcode 16.0 and Swift 5.10, while the 0.17.x entries sit on Xcode 15.2 with Swift 5.9 and the 0.16.0 release on Xcode 14.3 with Swift 5.8.

Internationalisation is done for English, Simplified Chinese, Turkish and Brazilian Portuguese, with a pull request request for more. The Chinese documentation is linked from the README as a separate file in the Documentation directory, and the Example application ships a zh-Hans.lproj directory, which is a good sign that localisation is treated as part of the package rather than as an afterthought.

## Adding it with SPM or CocoaPods and the Info.plist keys

Installation is short in both supported package managers. With Swift Package Manager the README notes that Xcode 12.0 or newer is needed to support resources and localisation files, and the dependency is declared as:

```swift
dependencies: [
    .package(url: "https://github.com/AnyImageKit/AnyImageKit.git", .upToNextMajor(from: "0.18.2"))
]
```

With CocoaPods you add one line to your Podfile and then update the dependency:

```ruby
pod 'AnyImageKit'
```

The repository ships both manifests, Package.swift and AnyImageKit.podspec.json, along with Package.resolved, the .swiftpm directory and an Xcode project, so either route works without extra tooling.

Before the modules will run, your Info.plist needs the usage descriptions that match which module you use. The README lists them with the module they belong to: NSPhotoLibraryUsageDescription and NSPhotoLibraryAddUsageDescription for the Picker, NSCameraUsageDescription and NSMicrophoneUsageDescription for Capture. There is one more that is easy to miss. PHPhotoLibraryPreventAutomaticLimitedAccessAlert should be set to YES to prevent the automatic limited access alert on iOS 14 and later, and the README explains that the Picker has been adapted with limited access features that the user can trigger to improve the experience.

That last key is a design decision worth noting. Rather than ignoring the limited library, the library surfaces it and gives the user a way to grant more access deliberately, and the key exists so the system alert does not fight with that flow.

## Presenting the picker and handling the result

The usage example is the part that tells you what the API feels like day to day.

You import the module, create an options object, build an ImagePickerController with that options value and a delegate, and present it. The delegate protocol has two required callbacks: one for cancel, one for finishing with a PickerResult. From the result you get an assets collection, and each asset exposes an image.

```swift
import AnyImageKit

class ViewController: UIViewController {

    @IBAction private func openPicker(_ sender: UIButton) {
        var options = PickerOptionsInfo()
        /*
          Your code, handle custom options
        */
        let controller = ImagePickerController(options: options, delegate: self)
        present(controller, animated: true, completion: nil)
    }
}
```

The options object is a var, and the comment in the example marks the place where your code handles custom options, which is the intended extension point for theme, selection limits and media type filters.

The pattern is a familiar delegate-based modal, which means it drops into an existing view controller without restructuring your navigation. The cost is that the picker owns its own presentation, so a team with a heavily customised navigation stack will have to decide how much of that chrome it accepts.

The repository structure follows the same modular split as the feature list. Sources/ holds the library, Tests/ its tests, Example/ a sample application with controllers, protocols, views, utilities and a Chinese localisation folder, and Documentation/ the release notes and the Chinese README.

## Two version numbers, and what the project is now

The version story needs a word of care, because the repository shows two different views of the same thing.

The release notes table in the README lists v0.18.6 dated 2025-09-03, then v0.18.5, v0.18.4 and v0.18.2 in 2025, and v0.18.1 and v0.18.0 in October 2024. The published releases listed for the repository, however, top out at 0.18.1 from 2024-10-23. The package manifest in the README meanwhile asks for.upToNextMajor(from: "0.18.2"), which is a version the release list does not show.

Those three views do not agree, and the practical consequence is that you should pin deliberately. If you take the SPM snippet as written you get the 0.18.2 line; if you pick the newest published tag you get 0.18.1. Check the release notes document in the Documentation directory for the version you intend to ship.

The other observation is about the pace. The release table spans 2021 through 2025, and the last push on 2026-10-15 shows commits still arriving on master. So the project is being worked on even where the tagged releases have not moved as recently.

Taken as a whole, this is a well-organised, honestly-scoped iOS toolkit. The feature checklist tells you exactly what is and is not there, the localisation and theming work is done, and the gaps, Browser, filters, emoji, Live Photo capture, native macOS and tvOS, are the ones you would have to scope around.

## Conclusion

Adopt AnyImageKit if you are building an iOS or iPadOS app that needs a multi-select media picker with a WeChat-style theme, a capture screen and a drawing, crop, mosaic, rotate and text editor, and you would rather not write those view controllers yourself. Do not adopt it expecting a complete image pipeline, since the Browser module is unchecked, emoji and filter support are absent from the editor, and Live Photo and GIF capture are listed as not done. Before you start, read the feature checklist rather than the marketing line, confirm your Xcode and Swift versions meet the stated requirements, and check the release notes table for the version you pin, since the package manifest points at 0.18.2 while the newest release listed in the repository is 0.18.1.

## FAQ

### What modules does AnyImageKit provide?

The project has a modular design with Picker, Editor and Capture marked as implemented, and Browser listed but not finished. The Picker supports photo, GIF, Live Photo and video with multiple and mix selection.

### How do I add AnyImageKit to an iOS project?

With Swift Package Manager, add the package dependency for version 0.18.2 or newer within the same major version, and use Xcode 12.0 or later so resources and localisation files are handled. With CocoaPods, add pod 'AnyImageKit' to your Podfile and update the dependency.

### Which Info.plist keys does AnyImageKit need?

NSPhotoLibraryUsageDescription and NSPhotoLibraryAddUsageDescription for the Picker, NSCameraUsageDescription and NSMicrophoneUsageDescription for Capture, and PHPhotoLibraryPreventAutomaticLimitedAccessAlert set to YES to prevent the automatic limited access alert on iOS 14 and later.

### What editing operations does the AnyImageKit editor support?

Drawing, input text, cropping, mosaic and rotate are implemented, and the editor is marked as a Technical Preview. Emoji and filter support are listed as not yet supported, and Mac Catalyst is also a Technical Preview where the editor is not supported.

### What are the system requirements for AnyImageKit?

iOS 13.0 or newer, Xcode 14.1 or newer and Swift 5.7 or newer. The licence is MIT, the last push was on 2026-10-15, and the release notes list v0.18.6 from 2025-09-03 while the published releases top out at 0.18.1.

## Sources

- [AnyImageKit/AnyImageKit on GitHub](https://github.com/AnyImageKit/AnyImageKit)
- [Issues](https://github.com/AnyImageKit/AnyImageKit/issues)
- [License: MIT](https://github.com/AnyImageKit/AnyImageKit/blob/master/LICENSE)
- [README](https://github.com/AnyImageKit/AnyImageKit/blob/master/README.md)
- [Releases](https://github.com/AnyImageKit/AnyImageKit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/anyimagekit-anyimagekit