FFPopup and the two files that carry an entire iOS popup layer

Two Objective-C files hold the whole popup layer

FFPopup is described as a lightweight library for presenting custom views as a popup, and the repository description says the same in fewer words: presenting custom views as a popup in iOS. The scope is narrow on purpose. There is no view controller hierarchy to manage, no data model, no networking, no configuration file. The manual installation path describes adding the FFPopup.h and FFPopup.m source files to your project and then importing the header wherever you need it.

That makes the whole library inspectable in an afternoon. Someone on a team that dislikes third party dependencies can read both files before wiring them in, rather than auditing a binary framework. It also means the library sits at the same layer as UIKit's own presentation calls rather than replacing them.

The platform targets are declared plainly: iOS 8.0 and later, or macOS 10.13.6 and later, with Xcode 10.1 (10B61) or newer as the build requirement. Those floors are old in absolute terms, which cuts both ways. A team still supporting old iOS versions can use it, and a team on a current toolchain will not hit a stated minimum. The repository contains both an FFPopup directory and an FFPopup_Static directory, alongside the FFPopup.xcodeproj and FFPopup.xcworkspace projects and a Demo folder with separate Objective-C and Swift demo targets.

Nine show animations, nine dismiss animations, and no custom hook

The feature list is where the design shows through most clearly. Show types cover None, Fade In, Grow In, Shrink In, Slide In from top, bottom, left and right, and Bounce In from top, bottom, left, right and center. Dismiss types mirror that structure exactly: None, Fade Out, Grow Out, Shrink Out, Slide Out to the four edges, and Bounce Out to the four edges and center.

That symmetry is the main appeal. Presentation and dismissal are separate choices, so a view can slide in and shrink out, or bounce in and bounce out. The README shows six such combinations as animated demonstrations, including bounce from top paired with bounce to bottom, grow in paired with shrink out, and slide from bottom paired with slide to bottom.

Now the important detail. Directly beneath both lists there is an unchecked box reading Support custom. The enumeration of animation types is complete in the sense that the built in set is enumerated, and closed in the sense that you cannot plug in your own animation type through the documented API. For most popups this is fine, because the built in set covers the transitions product teams actually ask for. It is a real boundary for anyone whose brand needs a bespoke motion.

Two more unchecked boxes reinforce the same pattern. Blur background as an option for blocking interaction with the underlying view is not implemented, and Complete Documentation is also unchecked. Treat the feature list as an accurate map of what exists rather than a wish list.

Layout is two axis enums and background interaction is a third choice

Positioning is expressed as two independent axes rather than one combined enum. On the horizontal axis you can pick Left, Right, Center, Left of center or Right of center. On the vertical axis you get Top, Bottom, Center, Above center or Below center. Composing one horizontal value with one vertical value gives the placement, which is why the usage example builds a layout value from a horizontal enum and a vertical one.

Background behaviour is a separate axis with four states, and the naming here is slightly confusing in a way worth flagging. The list contains Allow interaction with underlying view, Don't allow interaction with underlying view, and Don't allow interaction with underlying view, dim background. The first two are toggles over the same core question of whether touches reach through to what is behind the popup, and the third adds a dimming layer on top of the blocked case.

Read the example rather than the prose and the pattern becomes clear. The popup is created with a content view, a show type, a dismiss type, a mask type, and two booleans for dismissing on background touch and dismissing on content touch. Those two booleans are what give a team the two background interaction modes, and the mask type controls the dimming. Three separate mechanisms end up covering what reads like one decision, so check all of them before assuming the popup will behave the way you expect.

Three install paths, and only one of them needs a network dependency

The library offers CocoaPods, Carthage and manual installation. The CocoaPods route is the shortest. Add the pod to your Podfile:

pod 'FFPopup'

Then resolve the dependency from the project root:

$ pod install

If you want the newest code rather than the published version, the README points at a normal external source dependency instead:

pod 'FFPopup', :git => 'https://github.com/JonyFang/FFPopup.git'

That variant pulls from the master branch directly, which means your build follows the branch rather than a tag.

Carthage is the second route and it needs the tool itself on the machine:

$ brew update
$ brew install carthage

Declare the dependency in your Cartfile:

github "JonyFang/FFPopup"

Then build the framework and copy the binary:

$ carthage update

The built FFPopup.framework binaries go into the application from Carthage/Build/iOS, and the project needs a Run Script phase containing /usr/local/bin/carthage copy-frameworks so the framework is copied at build time. Note that hardcoded path assumes a Homebrew install location on Intel macOS, which is the kind of detail that tends to need adjusting on Apple silicon.

The manual route has no dependency manager at all. Add FFPopup.h and FFPopup.m to the target, then import it with #import "FFPopup.h". This is the path with the least ongoing cost, and it suits a team that wants to read and vendor the code.

Swift works, and the API was renamed for Swift callers

The library is written in Objective-C, and the project is explicit that it can be used from Swift. With CocoaPods, adding use_frameworks! to the Podfile is what makes the bridging work. With a manual install, you add a bridging header file containing the FFPopup header.

Release history explains why the Swift story is deliberate rather than accidental. Version 1.1.0, published on 2019-04-28, is titled Customize API names for Swift, which indicates that the public method names were adjusted so they read naturally to Swift developers rather than carrying Objective-C conventions over unchanged. The topics attached to the repository include both objective-c and swift, and the Demo folder contains a separate FFPopup_Objc and FFPopup_Swift target, so both call sites are exercised in the sample project.

For someone evaluating the library today, the practical question is how much the Objective-C to Swift naming layer has drifted from what a modern SwiftUI team would write. The project has no homepage and no product site to describe that, so the Demo targets are the only reference for current naming.

The demo project is the real usage documentation

The README shows how to run the sample project by cloning the repository and opening the workspace:

$ git clone https://github.com/JonyFang/FFPopup.git
$ cd FFPopup
$ cd Shell && sh install-bundle.sh && sh install-pods.sh && cd ..
$ open FFPopup.xcworkspace

The sequence matters for anyone cloning the project themselves. The Shell directory contains install-bundle.sh and install-pods.sh, and those scripts prepare the Ruby and CocoaPods dependencies before the workspace will build. Opening FFPopup.xcodeproj instead of FFPopup.xcworkspace will not give you the dependency setup.

This is also the weakest part of the project. The feature list leaves Complete Documentation unchecked, and the usage section in the README shows a single Objective-C snippet that creates a FFPopup with a content view, a show type, a dismiss type, a mask type and the two dismissal booleans, then builds an FFPopupLayout from a horizontal and a vertical enum. There is a Swift equivalent below it in the full README, but the published feature summary stops there.

A team planning to use this library should therefore budget time reading the Demo targets rather than expecting a reference manual. The repository also carries a CHANGELOG.md, a CONTRIBUTING.md, a codecov.yml and a .travis.yml, so the history of behaviour changes is available even where the documentation is not.

Tagged releases stopped in 2021 while commits continued

The repository is not archived and the last push was on 2026-10-07, so code is still landing. The release history tells a different story. The most recent tagged version is 1.1.5, published on 2021-04-13 with a title about fixing typos. Before that came 1.1.4 on 2020-08-30, which fixed issue 11 and updated the Travis-CI script, and 1.1.0 on 2019-04-28, which customised the API names for Swift.

Read together, those facts mean the CocoaPods version a developer gets by default has not changed in over five years, while the master branch has received commits well after the last tag. The README itself points out that people wanting the latest features should use the external source dependency that pulls from master directly. That is a deliberate route, not an accident, but it also means the default install path is behind whatever has landed since.

The licence is MIT, which is permissive for commercial use and carries no copyleft obligation on an app that embeds it. Separate from the licence question, an upgrade cost sits in the small version numbers: since 1.1.0, the visible change log is a typo fix and a CI script fix, so the blast radius of moving to a newer master is likely small. Verify that against the Demo targets, which are the only working example in the repository.

Editorial conclusion

Adopt FFPopup if you need a custom view presented as a popup on iOS 8.0 or later and you prefer two Objective-C source files over UIKit's alert APIs. Do not adopt it if you need custom show and dismiss animations, a blurred background, or complete usage documentation, since each of those boxes is left unchecked in the feature list. Before integrating, open the Demo project in the FFPopup.xcworkspace and confirm that the show, dismiss and mask type names still match the enum names your target code expects.

Frequently asked questions

Official sources

1. Issues
2. JonyFang/FFPopup on GitHub
3. License: MIT
4. README
5. Releases