# SKPhotoBrowser: a Swift photo viewer for iOS apps that need a Facebook-style gallery

> SKPhotoBrowser is an MIT-licensed iOS image viewer written in Swift, distributed through CocoaPods, Carthage and Swift Package Manager. It covers the common gallery case well, but the README leaves the caching and deletion details mostly to the source.

**suzuki-0000/SKPhotoBrowser** — Simple PhotoBrowser/Viewer inspired by facebook, twitter photo browsers written by swift

- Repository: https://github.com/suzuki-0000/SKPhotoBrowser
- Stars: 2,736 · Forks: 551
- Language: Swift
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/suzuki-0000-skphotobrowser

## The gallery screen every iOS app rebuilds

A tap on a thumbnail should open a full-screen viewer. The user pinches to zoom, swipes sideways to move between images, swipes down to dismiss, and maybe taps a caption or an action button. None of that is hard in isolation, and all of it together is a week of work that has nothing to do with your product. SKPhotoBrowser exists to absorb that week.

It is aimed at iOS app developers who already have images somewhere (a UIImage, a remote URL, or a local file path) and need a presented view controller to show them. The README describes the interface as "Minimalistic Facebook-like interface, swipe up/down to dismiss", and that is the whole design target: a familiar full-screen gallery, not a media manager. The requirements listed are iOS 9.0+, Swift 2.0+ and ARC, and the project ships an example app in SKPhotoBrowserExample/ alongside the library target.

The scope boundary matters more than the feature list. This is a viewer, not a picker, not an editor, not an uploader. If your screen needs to select images from the device library, SKPhotoBrowser is the wrong component entirely, because it displays what you hand it.

## How SKPhotoBrowser models an image and presents it

The data flow is deliberately flat. You build an array of SKPhoto objects, wrap each source in the right factory method, construct an SKPhotoBrowser with that array, optionally call initializePageIndex, and present it. Three source types appear in the README: SKPhoto.photoWithImage for a UIImage you already hold, SKPhoto.photoWithImageURL for a remote string, and SKLocalPhoto.photoWithImageURL for a file on disk.

Caching is per photo, not global. The README sets photo.shouldCachePhotoURLImage = false on a URL photo and notes that true uses NSCache. That means the decision lives on each SKPhoto instance, so a grid of thumbnails and a full-screen set can be configured differently without touching a shared cache object. The trade-off is that nothing in the README explains eviction, memory ceilings, or what happens when a cached entry is stale. You are trusting NSCache defaults.

Presentation has two entry points. The plain initializer shows the browser from nothing. The second initializer, SKPhotoBrowser(originImage:photos:animatedFromView:), takes a source view and animates the transition from it, which is what the README demonstrates inside collectionView(_:didSelectItemAtIndexPath:). That second path is the one that makes a thumbnail grid feel connected to the viewer, and it requires you to pass the cell's image as the origin, so cells without a loaded image need a fallback.

Behaviour is configured through static option objects rather than instance properties. SKPhotoBrowserOptions and SKToolbarOptions hold flags such as displayToolbar, displayCounterLabel, displayBackAndForwardButton, displayAction, displayStatusbar, displayDeleteButton and swapCloseAndDeleteButtons, plus colors, image padding and the toolbar font. Because they are static, they are process-wide: setting SKPhotoBrowserOptions.backgroundColor affects every browser you present afterwards, so if two screens need different chrome you have to set the options immediately before each presentation.

## Installing SKPhotoBrowser and showing a first gallery

CocoaPods is the shortest path. The README gives a two-line Podfile addition, and the podspec is at the repository root.

```bash
pod 'SKPhotoBrowser'
use_frameworks!
```

After pod install, reopen the workspace rather than the project. Carthage users add a line to the Cartfile instead, and Swift Package Manager users point Xcode at the repository URL, which the README says is available. All three routes ship the same library; the podspec and Package.swift both sit at the top level of the repository.

If you want the share feature, which the README says includes saving an image into the gallery, add the photo library permission to Info.plist. Without it the save path has no authorization to work with.

```xml
<key>NSPhotoLibraryAddUsageDescription</key>
<string>Used to save images into your galery</string>
```

The first real use is a URL-backed gallery. Build the array, then present.

```swift
var images = [SKPhoto]()
let photo = SKPhoto.photoWithImageURL("https://placehold.jp/150x150.png")
photo.shouldCachePhotoURLImage = false // you can use image cache by true(NSCache)
images.append(photo)

let browser = SKPhotoBrowser(photos: images)
browser.initializePageIndex(0)
present(browser, animated: true, completion: {})
```

What you should see is a full-screen browser starting at index 0, with the image loaded from the URL. If you are opening from a collection view, use the origin-image initializer instead so the transition animates out of the tapped cell, and pass indexPath.row to initializePageIndex.

```swift
let browser = SKPhotoBrowser(originImage: originImage ?? UIImage(), photos: images, animatedFromView: cell)
browser.initializePageIndex(indexPath.row)
present(browser, animated: true, completion: {})
```

Before any of this, check the version table in the README against your Swift toolchain. It maps Swift 5.0 to SKPhotoBrowser 6.1.0 and above, Swift 4.2 to 6.0.0 and above, and older Swift releases to older tags. Installing the current release on a mismatched compiler is the most likely first failure.

## Where SKPhotoBrowser stops being the right tool

The README is thin on two things that matter in production: caching behaviour and deletion. Caching is one boolean per photo with an NSCache mention and no documented eviction policy, memory budget or failure handling. If your gallery streams large images over a slow connection, you are not given a prefetch story, a retry story, or a way to observe load failures. You would be adding that yourself around the browser, and at that point you should ask whether you want the viewer to own the pipeline at all.

Deletion is described in the feature list with a note that setting displayDelete=true shows a delete icon in the status bar and that deleted indexes can be obtained from a delegate method called didDeleted. The README does not document the delegate protocol signature, the ordering of callbacks, or what the browser does to its own photo array after a delete. You will be reading the source in SKPhotoBrowser/ to use it correctly. That is a documentation gap, not a bug, but it changes the cost of adopting the feature.

The other boundary is platform. The badge in the README says platform iOS, and the requirements say iOS 9.0+. There is no macOS, tvOS or watchOS target described, and no web or cross-platform story. If you are sharing a viewer between an iOS app and anything else, this library only covers one side.

Finally, the static options are a real constraint. Because SKPhotoBrowserOptions and SKToolbarOptions are global, an app with two visually different galleries has to sequence its presentations carefully, and any code that presents a browser inherits whatever the last caller set.

## Alternatives and how their approach differs

The related searches around this project cluster on other browser components, and the comparison is instructive because they solve adjacent but different problems. YPImagePicker and HXPhotoPicker are pickers: they own the selection flow from the device photo library and typically include cropping or filtering. SKPhotoBrowser does none of that. It takes images you already have and displays them. If your screen is "choose photos to upload", a picker is the correct dependency and SKPhotoBrowser would be an extra layer you write yourself.

MWPhotoBrowser, IDMPhotoBrowser and YBImageBrowser are closer siblings, in that they are also full-screen viewers. The practical difference is the delivery and the surface area. SKPhotoBrowser is Swift-first and ships a Package.swift alongside the podspec, so it can be pulled in through Swift Package Manager as well as CocoaPods and Carthage; the README's version table ties each release to a Swift version, which is useful when your toolchain lags. Its configuration model is the static options objects described above, which is simple to call and awkward to scope. If you need per-screen configuration or a viewer that also owns loading and caching policy, a browser whose options are instance-scoped will fit better, and you should compare on that axis rather than on the feature bullet list, which is broadly similar across all of them.

One more distinction: SKPhotoBrowser's README documents a delete affordance and a delegate callback, which some viewers leave out. If in-gallery deletion is part of your flow, that is a reason to look here first, provided you are willing to read the source for the delegate contract.

## Maintenance, licensing and the cost of upgrading

The repository is not archived, and the most recent push recorded is 2026-07-13. Release history shows 7.0.0 in July 2021, then 7.1.0 and 7.1.1 in February 2026, so the project had a long quiet stretch followed by a recent pair of releases. That pattern is worth knowing before you plan around it: the code is not abandoned, but the gap between 7.0.0 and 7.1.0 is measured in years, and a dependency with that cadence can sit unchanged for a long time between updates.

Upgrade cost is dominated by the Swift version table, not by the library's API. The README maps SKPhotoBrowser 6.1.0 and above to Swift 5.0, 6.0.0 and above to Swift 4.2, 5.0.0 and above to Swift 4.1, and 4.0.0 and above to Swift 3.2. Because the current line requires Swift 5.0 or later, an app still on an older toolchain is pinned to an older tag and will not receive the 2026 changes without a compiler upgrade first. The CHANGELOG.md at the repository root is where the per-release detail lives; the README itself does not enumerate what changed between 7.0.0 and 7.1.1. There is no documented migration guide, so treat each major bump as something to verify against the changelog and the example project.

The licence is MIT, which is permissive and places few conditions on commercial use, typically requiring preservation of the copyright notice and licence text. That is a statement about the licence identifier, not legal advice; read the LICENSE file at the repository root and have your own counsel review it if the distinction matters to your organisation.

## Conclusion

Adopt SKPhotoBrowser if you are building an iOS-only gallery screen and want a presented view controller that already handles zooming, paging, captions and swipe-to-dismiss, with CocoaPods, Carthage or Swift Package Manager as the delivery path. Do not adopt it if you need a cross-platform viewer, a picker, or an image pipeline that resizes and uploads as well as displays. Before writing code, check the version-versus-Swift table against your toolchain, confirm that NSPhotoLibraryAddUsageDescription is present if you plan to use the share and save feature, and read the source for how SKPhoto.shouldCachePhotoURLImage and the delete delegate actually behave, because the README describes both only in passing.

## FAQ

### How do I install SKPhotoBrowser in an iOS project?

Add pod 'SKPhotoBrowser' and use_frameworks! to your Podfile for CocoaPods, or add github "suzuki-0000/SKPhotoBrowser" to your Cartfile for Carthage. The README also states it is available in Swift Package Manager using the repository URL in Xcode.

### Can SKPhotoBrowser display images loaded from URLs?

Yes. The README shows SKPhoto.photoWithImageURL for a remote string, and each photo has a shouldCachePhotoURLImage property that uses NSCache when set to true.

### Does SKPhotoBrowser support deleting photos from the viewer?

The feature list says setting displayDelete=true shows a delete icon in the status bar, and that deleted indexes can be obtained from a delegate method called didDeleted. The README does not document the delegate signature or what happens to the browser's photo array afterwards.

## Sources

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

---

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