FSPopoverView: a Swift popover library for iOS menus

FSPopoverView exists because the system popover is not configurable

FSPopoverView is a Swift library for presenting popovers on iOS, and its reason to exist is configurability. The README states the purpose in a single line: "A library to present popovers." What the library adds over a plain presentation is control of the arrow, the border, the shadow, the transition animation and the list appearance, and the developer stays responsible for the anchor geometry that decides where the popover appears.

The audience is iOS developers building menus, action sheets in a custom shape, or small pickers attached to a bar button or a tapped row. The requirements are iOS 12 or later, Swift 5, and Xcode 15 or later. A badge in the README marks the project as Objective-C incompatible, so it slots into a Swift only codebase and creates friction in a mixed one. The MIT license allows the source to be vendored into a proprietary app, provided the notice carried in the LICENSE file is kept.

The data source hands the library your views and your anchor

The custom content path runs through a data source protocol. You create an FSPopoverView, assign a data source, and present it from a bar button. The protocol then asks for four things: a background view, a content view, a content size, and the safe area insets of the container. A fifth callback decides whether a tap outside dismisses the popover, which separates a menu that closes on selection from one that stays open for further interaction.

let popoverView = FSPopoverView()
popoverView.dataSource = self
popoverView.present(fromBarItem: barItem)

The split between background and content view is worth noting. The background view is the popover body that carries the border, shadow and rounded shape, while the content view is the payload you place inside it. Because the size comes from the data source as an explicit CGSize rather than from constraint solving, the developer decides the box, and the library draws the arrow and frame around it. Safe area insets arrive from the container, so a popover anchored near a home indicator can be told about the obstruction.

FSPopoverListView turns an array of items into a menu

The second entry point avoids the data source entirely. FSPopoverListView is data driven: you build an array of FSPopoverListItem values, assign it to the items property, and present the list from a rectangle in a given view. FSPopoverListTextItem is the default item, and it carries an image, a title, a separator flag and a selected handler. Each item calls updateLayout after its fields are set, so the cell measures itself from the values you assign.

let listView = FSPopoverListView()
listView.items = items
listView.present(fromRect: sender.frame.insetBy(dx: 0.0, dy: -6.0), in: view)

Because the list is a plain array, the content is easy to compose from a model type. The demo project in the repository maps a set of features to items, and the last item hides its separator so the group reads as a single block. The trade off is that the list path gives you the built in text item and its separators, while anything beyond that requires subclassing FSPopoverListItem and FSPopoverListCell, which the README mentions without a worked example.

Four installation paths, with CocoaPods marked as the recommended one

The README documents four ways to bring the library into a project. CocoaPods is the recommended route, and the podspec lives at the top level of the repository.

pod 'FSPopoverView'

Carthage is the second option.

github "lifution/FSPopoverView"

For Swift Package Manager, the README describes adding the dependency to the dependencies value of Package.swift or to the package list in Xcode.

dependencies: [
    .package(url: "https://github.com/lifution/FSPopoverView.git")
]

The fourth option needs no package manager at all: download or clone the repository, drag the folder named Source into the project, and tick the options labeled "Copy items if needed" and "Create groups".

There is no version constraint to copy into the podfile or Package.swift, and the README does not show a pinned version for any of these routes. That means the resolution of the dependency version is left to the tooling, and a project that wants a stable build has to record the resolved revision itself.

Arrow, border, shadow and a global appearance proxy

The supported feature list in the README is where this library earns its place. Custom content is supported, so the payload is not limited to a list. Arrow direction is supported, and the arrow can be hidden entirely. The border and the shadow are both customizable, which means the popover can be made to match a design system rather than a system default. The transition animation is customizable as well, so a menu can slide, fade or use something else.

A custom list item is supported for cases where the default text item is not enough. Dark mode is supported for iOS 13 and later, and global appearance is supported through a proxy object that the app configures once at launch:

        let appearance = FSPopoverView.fs_appearance()
        appearance.showsArrow = false
        appearance.showsDimBackground = true

That call belongs in the application launch method, and it changes defaults for every popover the app presents afterwards. The trade off of a global appearance is that it applies uniformly, so a screen that needs a different arrow treatment has to override the shared defaults at the point of presentation rather than relying on one configuration for the whole app.

Three checkboxes are still empty, and no release tags exist

The README keeps an explicit support checklist, and three entries on it are unchecked. Arrow direction priority is not supported, so a popover that is asked to keep pointing at one source while the anchor moves has no documented priority rule. List appends and removes item is not supported, which is the sharpest limitation for a data driven list: the items array is set and the presented list does not grow or shrink on its own. Compatibility with screen rotation is not supported either, so a popover presented before a rotation is in territory the project does not claim to handle.

On maintenance, the last push was on 2026-10-16, and the repository has no GitHub releases. There is no tagged version to point at in a podfile or a Package.swift, and no changelog to read for upgrade notes. The repository carries a podspec, a Package.swift, a .swiftpm directory and an Example project with its own Podfile and Podfile.lock, so the distribution surface is conventional, but the versioning story is thin. An upgrade therefore means reading the source diff yourself rather than reading release notes, and the absence of tags means the dependency version you get depends entirely on how your tooling resolves the branch.

Custom content or list items: choosing between the two entry points

The realistic alternative to FSPopoverView is not another third party package so much as a different choice inside the same library, and the difference in approach is clear. The FSPopoverListView path is declarative in the sense that an array of items becomes a menu with separators and a standard cell, and the cost is that anything unusual requires a subclass. The FSPopoverView path is fully manual: you return your own background and content views, you state the size, and you can put any view inside, at the cost of laying out the cell structure and the content sizing yourself.

UIKit also ships its own popover presentation, and the choice between the two approaches is mostly about who owns the arrow, the frame and the transition. The system presentation owns all of them and adapts to the surrounding context. This library hands the arrow, the border, the shadow and the animation to the developer, and in exchange it expects a Swift 5 codebase on Xcode 15 or later and does not offer Objective-C callers. The practical test is whether a design requires a specific arrow shape or a custom border. If it does not, the system presentation removes a dependency. If it does, this library removes the workarounds that would otherwise be needed, and the empty checkboxes tell you exactly which workarounds will remain.

Editorial conclusion

FSPopoverView fits a Swift only iOS codebase that needs a menu with a custom arrow, border, shadow or transition, and it does not fit a mixed Swift and Objective-C app or a list that changes after presentation, since list mutation and screen rotation remain unchecked features in the README. Before adopting it, confirm that the arrow placement you need is achievable, because arrow direction priority is still listed as unsupported, and read the Source folder of the version you pin against your own build settings.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lifution/FSPopoverView on GitHub
4. README