# SwiftyPickerPopover: a picker inside a popover for UIKit apps

> SwiftyPickerPopover is a small Swift library that shows a popover containing a UIPickerView or a UIDatePicker on iPhone and iPad, with a builder-style API for fonts, buttons, images, size and dismissal. It targets Swift 5 and iOS 9, ships through CocoaPods and Carthage, and has no Swift Package Manager manifest.

**hsylife/SwiftyPickerPopover** — A more convenient way to display a popover with a built-in picker, on iPhone/iPad of iOS9+.

- Repository: https://github.com/hsylife/SwiftyPickerPopover
- Stars: 645 · Forks: 95
- Language: Swift
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/hsylife-swiftypickerpopover

## A selection popover instead of a picker view on screen

SwiftyPickerPopover exists to solve one UIKit problem well: choosing one value from a list without giving up the whole screen to a picker view. The README describes it as a more convenient way to display a popover with a built-in picker, on iPhone or iPad running iOS 9 or later.

The feature list is short and worth reading literally, because each line is a design commitment. You can display a popover containing a built-in picker with simple code. The library is Swift 5 and iOS 9+, and it is UIPopoverController free, which is a pointed claim: the class has been deprecated by Apple, so a library that avoids it is choosing a different mechanism for presenting the overlay. And it uses a callback, so selection results are delivered to a closure rather than through a delegate protocol.

Those choices put the library in a specific place. It is not a general popover component, and it does not try to be. It is a picker in a popover, which is a pattern you need when the choice is one of several, when it is attached to a button or a bar item, and when the rest of the screen should stay visible.

The repository layout confirms the small size of the thing. There is a SwiftyPickerPopover directory for the sources, a SwiftyPickerPopover.xcodeproj, a podspec, a Demo application with a SampleViewController, a SampleTableViewController.swift and a TextFieldCell.xib at the top level, a CHANGELOG.md and a LICENSE file. The Demo directory includes localisations, with a ja.lproj folder alongside Base.lproj, which tells you the author cares about the library being usable in a localised app.

## Four popover types behind one builder API

The library offers four popovers. StringPickerPopover holds a UIPickerView that lets the user choose a String. ColumnStringPickerPopover holds a UIPickerView with multiple columns. DatePickerPopover holds a UIDatePicker for choosing a Date. CountdownPickerPopover holds a UIDatePicker in the countDownTimer style.

Each type has its own initialiser and its own set of setters, and all of them share a common set. The common API covers the appearance and the behaviour of the container: setPermittedArrowDirections, setArrowColor, setSize(width:height:), setCornerRadius, setValueChange(action:), setOutsideTapDismissing(allowed:), setDimmedBackgroundView(enabled:), plus the presentation and lifecycle calls appear, appear with a bar button item, disappear, disappearAutomatically(after:completion:) and reload.

The string picker adds the setters you would expect for a list of text: fonts, font size, font colour, image names and images, the selected row, the row height, a display string override, and done, cancel and clear buttons. The column picker has the same family of controls, with fonts, font sizes and font colours listed for it, and its own initialiser taking choices, selected rows and column percentages.

The style is a fluent builder. Each setter returns the popover, so the call chain reads as a configuration, and the chain ends with appear, which is what actually presents it. The one API worth singling out is setDisplayStringFor, which lets you show something different from the underlying value, for example a symbol in place of a label, while the code still receives the raw value. That is a small feature with a real effect: the display layer and the data layer can differ without duplicating arrays.

Size is configurable too, and the default is documented: the default width and height of the popover are both 300.0, setSize(width:, height:) overrides either or both, and passing nil or omitting a parameter falls back to the default.

## Anchoring the popover to a view, a cell or a bar button item

Where the popover comes from is the part that has to work in a real app, and the API covers three cases. The primary one is appear with an originView and a baseViewController, where the origin view is the anchor and the arrow points at it. The second is appear with a barButtonItem, for a button in a navigation bar. The third piece of the same call is baseViewWhenOriginViewHasNoSuperview, which the README explains directly: if the origin view has no superview, you need to supply a base view so the arrow has a source view to point from, and if it does have a superview, SwiftyPickerPopover uses that automatically.

That fallback matters in practice, because the common case of a picker attached to a table view cell or a collection view cell hits exactly this problem. A dequeued cell that has not yet been added to a visible hierarchy has no superview, and the arrow position would be undefined without the base view. The README shows the collection view case explicitly, where the cell is dequeued and then used as the origin view.

The bar button item case has a caveat that the README is honest about. The example retrieves the item's view through the Objective-C runtime, with item.value(forKey: "view") as! UIView, and passes that view as the origin. That is a force-cast of a private-ish key path, and it is the kind of thing that can break in a future iOS release.

The dismiss options are also explicit. disappear() closes it, disappearAutomatically(after:completion:) closes it after a delay with a completion callback, setOutsideTapDismissing(allowed:) controls whether a tap outside closes it, and setDimmedBackgroundView(enabled:) controls the dimmed backdrop. setValueChange(action:) fires as the selection changes, while the done button carries the final value, and there is a separate cancel action, so a user can change the value and then abandon it.

## Installing with CocoaPods or Carthage

There are two installation routes, and the README gives the exact snippets for each.

For CocoaPods, the pod goes into the Podfile with the target name substituted, and the platform line set to iOS 9:

```ruby
platform :ios, '9.0'
use_frameworks!
target ‘YourProjectTargetName’ do
pod 'SwiftyPickerPopover'
end
```

After that you run pod install. The requirements listed are CocoaPods 1.1.0.rc.2 or later, or Carthage 0.12.0 or later, and the note that the project needs Swift 5 and Xcode 11 with iOS 9 as the minimum.

For Carthage, the repository goes into the Cartfile:

```
github "hsylife/SwiftyPickerPopover"
```

Then you run carthage update --platform iOS, add SwiftyPickerPopover.framework to Linked Frameworks and Library in the project, add /usr/local/bin/carthage copy-frameworks to a New Run Script Phase, and add $(SRCROOT)/Carthage/Build/iOS/SwiftyPickerPopover.framework to the Input Files of that phase. Those last three steps are the standard Carthage copy-frameworks wiring, and they are the part newcomers usually miss.

Then the module is imported in the Swift file that uses it:

```swift
import SwiftyPickerPopover
```

What is missing from that list is as informative as what is in it. The repository has no Package.swift, so there is no Swift Package Manager route, and the deployment target of iOS 9 in the podfile is now well below what Apple tooling supports, so in practice the platform line will have to be raised, along with the Xcode and Swift versions the library was written against.

## A UIKit component with a dated toolchain requirement

The constraints on this library are mostly the consequences of its age and its scope. It is a UIKit component: the popover is a UIPopoverController-free container holding a UIPickerView or a UIDatePicker, which means it lives in a view controller hierarchy, and there is no SwiftUI equivalent in the repository. For a team that has moved new features to SwiftUI, this is a UIKit component to wrap rather than a SwiftUI view to drop in.

The stated toolchain requirements are Swift 5 and Xcode 11, and the required list repeats Swift 5, Xcode 11 and iOS 9. Xcode 11 is the constraint that will bite first, since current Xcode versions cannot build a project that assumes an Xcode 11 era toolchain in some cases, and iOS 9 as a deployment target is far below what current tooling will accept without raising it. The library is old enough that adopting it today means adjusting it, not just importing it.

The support policy is also informal. The project has no GitHub releases, so there is no tagged version to pin in a Podfile, which is a real problem for reproducible builds, since a podspec with no version constraint in the Podfile will resolve to whatever is current at install time. The CHANGELOG.md is the only version record, and the last push was on 2026-07-06.

None of this makes the library unusable, and the code is small enough to read in an afternoon, which is a genuine advantage of a component this size. The realistic pattern for a new project is to vendor the source into your own target, adjust the deployment target, and own the code, rather than to depend on an unversioned pod.

## Conclusion

SwiftyPickerPopover suits a UIKit codebase that needs a compact selection popover without writing a container controller, and it suits a SwiftUI codebase poorly, since the library is UIKit only and the repository has no Swift Package Manager manifest, so adoption means CocoaPods or Carthage. Before adding it, check the popover type you need is one of the four provided, and confirm your deployment target and Xcode version still satisfy the stated Swift 5 and iOS 9 requirements. The licence is MIT, the project publishes no GitHub releases, and the last push was on 2026-07-06.

## FAQ

### What does SwiftyPickerPopover provide?

It displays a popover with a built-in picker on iPhone and iPad running iOS 9 or later, in four variants: StringPickerPopover, ColumnStringPickerPopover, DatePickerPopover and CountdownPickerPopover, with a fluent API for buttons, fonts, images, size and dismissal.

### How do I install SwiftyPickerPopover?

With CocoaPods, add pod 'SwiftyPickerPopover' to a target in the Podfile and run pod install. With Carthage, add github "hsylife/SwiftyPickerPopover" to the Cartfile, run carthage update --platform iOS, and add the framework plus the copy-frameworks run script phase. Then import SwiftyPickerPopover in your Swift file.

### How do I show a SwiftyPickerPopover from a table view cell?

The origin view needs a superview for the arrow position, and the README explains that you pass baseViewWhenOriginViewHasNoSuperview to supply one in that case. If the origin view has a superview, the library uses it automatically.

### Can I show a different label than the value I select?

Yes. setDisplayStringFor takes a closure that maps a String to a display String, so the popover can show a symbol while the callback still receives the underlying value.

### What licence does SwiftyPickerPopover use?

MIT, as stated in the README and recorded in the LICENSE file at the root of the repository.

## Sources

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

---

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