LSTPopView: iOS popups shipped as an Objective-C pod and a Swift package

The library owns the mask, the queue and the dismissal, not the content

LSTPopView is a UIKit popup library written in Objective-C, and the division of labour is stated in the README. The business code owns content and interaction, while the library owns presentation, animation, the mask, the queue and the closing flow. The scenarios it names are confirmation dialogs, bottom panels, input forms, selection lists and sidebars, which is a broad list that all reduce to the same need: a view that appears above the app, blocks or passes touches to a background, and can be dismissed predictably. The audience is iOS developers whose apps need that behaviour in several places and would otherwise write it again per feature. Inside a popup, the content is a custom UIView that you build in code or load from a XIB, and position, offset, corner radius and background are all configurable.

Two independent implementations with very different requirements

The project ships two code bases, not one codebase with a Swift wrapper. The Objective-C side is published as the pod LSTPopView, declares a deployment floor of iOS 8.0 in its podspec, pulls in one third party dependency named LSTTimer, and adds no Swift toolchain requirement. The Swift side is published as LSTPopViewSwift, declares a floor of iOS 15.0, has no third party dependencies and uses only system frameworks, and it requires the Swift 6.2 toolchain, Xcode 26 and the Swift 6 language mode. The README is careful about one point: the deployment floors come from the respective package configurations and do not mean every historical system and device has been run verified. Existing Objective-C projects keep using the same pod declaration with no migration, the two modules can be installed independently, and the Swift version's system and compiler requirements do not leak into a project that only installs the Objective-C pod.

The Swift product can only be fetched from a branch

Installation of the native Swift module is the part with a catch, and it is a supply chain detail rather than a cosmetic one. The Swift Package Manager entry point is the repository itself, so Xcode is pointed at the git URL and the product LSTPopViewSwift is added to the application target:

https://github.com/LoSenTrad/LSTPopView.git

The documentation then says to select Branch: master, and to switch to a Revision when you need to pin the source code. The reason for that instruction is spelled out: tags up to and including 0.3.10 belong to the Objective-C history and do not contain a Swift Package, so they cannot be used to install the native Swift product. The Swift CocoaPods pod uses its own name, and until it is published to the CocoaPods trunk it is also integrated from the git branch:

platform :ios, '15.0'
target 'YourApp' do
  pod 'LSTPopViewSwift', :git => 'https://github.com/LoSenTrad/LSTPopView.git', :branch => 'master'
end

One install route per application target is the rule, so the same implementation is not linked twice through SPM, Pods and manual source at once. A note on versions closes the section: the podspec sets swift_version = '6.0', which describes the language mode and does not mean a Swift 6.0 compiler can build these sources.

Manual integration swaps the module import for plain file references

Manual integration is supported for both languages, and it comes with an import difference that trips people up. For Objective-C you add LSTPopView.h and LSTPopView.m, UIView+LSTPV.h and UIView+LSTPV.m, and LSTPopViewProtocol.h from the Code directory, install LSTTimer as well, and add LSTAlert.h and LSTAlert.m if you want the extra alert wrapper. For Swift you add all five .swift files from the Swift sources directory to the same application or framework target, using iOS 15 or later, the Swift 6 language mode and a Swift 6.2 compiler. When the files are added manually to an application target in Objective-C, the import is written as #import "LSTPopView.h", while the angle bracket form used elsewhere in the documentation is for the CocoaPods module. In Swift, a manual add means you do not import LSTPopViewSwift and do not prefix type names, because the types then belong to your own target. Both source sets must keep the MIT copyright and licence notices, and Carthage has no adapted entry point at the moment.

The configuration surface, from the mask to the auto dismiss timer

The two versions keep close API naming, with enum spellings adjusted to each language, and the full interface lives in the Objective-C headers and the Swift public sources. The documented configuration table is the fastest way to see the surface. A popup can be anchored to the bottom with hemStyle, offset with adjustX and adjustY, and given a corner radius. Background interaction has three separate switches rather than one: isClickBgDismiss for tapping the mask, isHideBg to hide the mask and let touches pass through, and the background click block for a custom reaction. Keyboard avoidance is handled by isAvoidKeyboard with an avoidKeyboardSpace margin. Ordering and lifetime are managed by groupId, a priority value from 0 to 1000, isStack for stacking, isSingle for single display mode, and showTime for closing automatically after a set number of seconds. Gestures are configured separately through dragStyle for dragging down and sweepStyle for a swipe. In the Objective-C version the block that closes a popup should hold the popup weakly, since a strong reference from the block back to the popup creates a retain cycle.

Grouping, priority and the Swift concurrency decisions

Beyond styling, the library manages how several popups coexist. The documentation describes support for grouping, priority, stacking and single display mode, along with querying and managing popups per container view. That is the part of the design that decides whether the library is useful in a real app: a checkout flow that needs a confirmation before a payment sheet, or a busy screen where only one popup should be visible, depends on ordering rules rather than on call order. The native Swift implementation adds the concurrency and platform work that the Objective-C version does not need. It isolates interface state with @MainActor, handles invalidation across multiple Scene contexts, supports the reduce motion setting, and restores accessibility focus after a popup closes. The Objective-C implementation has no equivalent Swift toolchain requirement, which is exactly why the two are kept apart instead of sharing a core.

Three demos, a test target, and no release history

The repository ships enough to check the library before you depend on it. The Objective-C demo lives in the Example directory, where running pod install and then opening LSTPopView.xcworkspace reproduces the original API usage. The native Swift demo has 16 independent scenarios with detailed Chinese comments and event logs, and it opens directly through NativeSwiftDemo.xcodeproj with the NativeSwiftDemo scheme and needs no Pods, because it uses the repository local package; on a physical device you pick your own signing team in Xcode. A third example covers the Objective-C and Swift versions coexisting in one app, checking class names, presentation and queue isolation, and its test host requires iOS 16 or later. The Example directory also contains a Tests folder and a Podfile with a lock file, and the repository has an UPDATE_HISTORY.md, a .travis.yml and separate podspecs for the two modules. The last push was on 2026-10-17, the project publishes no GitHub releases, and the licence is MIT.

Editorial conclusion

LSTPopView fits iOS teams that want one popup library for confirmations, bottom panels, input forms, pickers and sidebars, and that need an Objective-C and a Swift codebase to agree on behaviour without a migration. It does not fit a project that needs a tagged, published release for the Swift product, because that product is only obtainable from a branch, and it does not fit a team that requires Carthage support or a Swift 6.0 compiler. Verify three things first: that the branch you point Swift Package Manager at is the commit you tested, that your build tooling can meet the Swift 6.2 compiler and Xcode 26 requirement, and that you install the Swift module through exactly one of SPM, CocoaPods or manual sources so the same implementation is not linked twice. The last push was on 2026-10-17 and the project publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. LoSenTrad/LSTPopView on GitHub
4. README