# GHDropMenu is an iOS filter menu you drag into a project, and it comes with two usage modes that must not be mixed

> shabake/GHDropMenuDemo is an Objective-C component for the drop down, slip side and tag style filter menus used by Chinese e-commerce apps, with a Swift demo alongside it. Integration is by dragging a folder into Xcode, the minimum target is iOS 13.0, and the component ships as source with no package manager support.

**shabake/GHDropMenuDemo** — :sunny::sunny: 仿京东/美团电商筛选菜单 电商筛选菜单 电商通用筛选菜单:tennis::tennis: Imitation Jingdong / Meituan e-commerce screening menu E-commerce screening menu E-commerce general screening menu

- Repository: https://github.com/shabake/GHDropMenuDemo
- Website: https://github.com/shabake/GHDropMenuDemo
- Stars: 657 · Forks: 88
- Language: Objective-C
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/shabake-ghdropmenudemo

## Three directories, and you only need one of them

The repository is worth understanding before you install anything, because it contains three things and only one of them is the component.

GHDropMenu/ is the component itself: the menu control, the cell classes and the model objects. This is the folder you integrate. GHDropMenuDemo/ is a runnable demo application that includes Swift examples, and GHDropMenuDemo/Example/ holds the sample page code inside the demo, grouped by scenario, with the demo's home rows carrying a subtitle that explains what each sample does and which file to copy.

That last detail is the most useful thing in the project. Rather than a single sample, the demo provides several, each isolating one layout pattern, so you can pick the one that matches your screen and copy that implementation rather than reverse engineering the whole component.

The project also links to a Flutter version in a separate repository, which tells you the component has been ported across platforms and that the Objective-C implementation is the origin rather than an afterthought.

The primary language is Objective-C, and the demo carries Swift examples alongside the Objective-C ones, so both sides of the interoperability story are visible in the same Xcode project.

For an evaluator, the honest summary is that this is a source drop-in component with a thorough demo, not a distributed library.

## Two modes: a titled top bar, or a full screen slip filter

The documentation is emphatic that the two usage modes should not be mixed, and the difference between them is structural rather than cosmetic.

Mode A is the ordinary top filter with a title bar and a drop down. You create the menu with a factory method that takes a configuration model, a frame, a block that selects the title, and a block that receives the side filter result as an array of tags. The menu is added to your view like any other UIView, and the documentation states that the popover attaches itself to the container of the current window, so you usually do not have to manage that yourself.

Mode B is the full screen slip filter only. Here you create the menu with a different factory method that takes the configuration model and the tag array block, then set its frame to the bounds of your view, set an autoresizing mask that flexes in both width and height, add it as a subview and call show.

In code, mode B looks like this:

```objc
GHDropMenu *menu = [GHDropMenu creatDropFilterMenuWidthConfiguration:model
                                            dropMenuTagArrayBlock:^(NSArray *tags) { /* ... */ }];
menu.frame = self.view.bounds;
menu.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
[self.view addSubview:menu];
[menu show];
```

The ordering constraint in mode B is stated as a requirement: set the frame, add the subview, and only then call show. The menu does not attach itself to the window automatically in this mode.

That difference is the part to internalise. Mode A handles its own presentation layer, mode B is a view you own and position yourself, and mixing the two habits produces a menu that either floats in the wrong place or never appears.

## Closing the menu is your job, and the Swift name differs

One behaviour has to be implemented by the integrating app rather than the component, and it is the kind of detail that produces a visible bug: the mask left behind on the window when the user navigates back.

The instruction is to close the menu when returning to the previous page so that the overlay does not remain attached to the window. In Objective-C that is a call to closeMenu, placed in viewWillDisappear or in your own back handler. In Swift the equivalent is close(), which the documentation describes as the renamed Swift version of closeMenu.

The renaming is worth noting because it is exactly the kind of divergence that makes porting an integration from one language to the other slow. The Objective-C selector and the Swift method name are not the same string, and searching for one in the other language gets you nothing.

The broader pattern here is that this component gives you presentation and callbacks but leaves navigation lifecycle to the host. If your app has a tab bar, a navigation stack, or modal sheets layered on top of the menu, you own the teardown.

The same guidance applies to the popover host: the documentation mentions ghPopupHostView in the implementation notes for the ordinary top filter and the slip examples, which is the layer that decides where the drop down attaches.

## Five sample pages, one per filter layout

The mapping table in the documentation links each item in the demo list to the file that implements it, and the set of layouts is the clearest statement of what this component covers.

There is a complex filter menu example, a slip side filter menu example, and an ordinary filter menu example, each with an Objective-C view controller in the Example directory and a Swift counterpart. There is a suspend or floating filter example built around a table view, and there is a waterfall grid example in the Meituan delivery style, with its own controller.

Each entry names the class to look at, for example GHComplexMenuViewController, GHSlipMenuViewController, GHNormalMenuViewController, GHSuspendViewController and GHMeituanFoodViewController, and the Swift files follow the same naming pattern with a Swift prefix.

That naming is a small but real piece of documentation. The component is designed around a handful of recognisable screen types from Chinese e-commerce apps, which is why the repository description compares it to the filter menus of Jingdong and Meituan.

For the floating table view case there is also a specific recommendation: for the section headers of the table view inside the floating list, the documentation suggests the reusable GHSuspendMenuHeaderView from the suspend example. Reusing the header view rather than writing your own is the difference between a menu that matches the reference implementation and one that nearly matches.

The integration instructions close the loop: copy the whole GHDropMenu folder into your Xcode project, tick Copy items and your target, import GHDropMenu.h on the page that needs it or use a bridging header in Swift, and then copy the pattern from one of the example files, creating a GHDropMenu or a GHDropMenuModel, adding it as a subview and calling show when needed. The documentation is explicit that you do not need to change your existing architecture, because the menu is a UIView.

## Running the demo means picking a scheme, not a build flag

The demo runs from Xcode with a specific procedure, and the scheme choice is the interesting part.

You open GHDropMenuDemo.xcodeproj in Xcode, select the GHDropMenuDemo target, pick a simulator and run. Optionally you can choose a scheme at the top: GHDropMenuDemo gives you a two tab layout with an Objective-C list and a Swift list, while GHDropMenuDemo-ObjC and GHDropMenuDemo-Swift go straight into the list for that language.

The switch between those behaviours is an environment variable, GH_ROOT_DEMO, configured through the scheme under Run and Environment Variables. That is a useful detail for anyone who wants to see both language implementations of the same screen, and it also hints that the demo has a routing layer keyed off a root configuration value.

Every row on the demo home screen has a subtitle explaining what the sample demonstrates and which file to copy from it, so the demo doubles as an index rather than a gallery.

The demo also appears in the repository as a separate entry, with the project file at the top level and the demo sources inside GHDropMenuDemo/, so the two are shipped together. The animated preview of the interactions is in the README as a GIF, which is the quickest way to see the intended behaviour before opening Xcode at all.

## A source drop-in with no package manager and no releases

The environment requirements are short: iOS 13.0 as the minimum system version, and the documentation notes that the price validation style prompts have been moved onto UIAlertController.

The integration model is the defining constraint. There is no CocoaPods podspec, no Swift Package Manager manifest and no Carthage setup described in the documentation. The install instruction is to drag the GHDropMenu folder into your Xcode project, tick Copy items and the target, and import the header. The Flutter port lives in its own repository under a different name, which confirms the pattern of distributing source that you copy rather than declare as a dependency.

That model has a specific consequence: you own the copy. There is no version to bump, no changelog to track on your behalf and no upstream fix that arrives in your app. When the component changes, you change it.

The repository has no GitHub releases and the last push was on 2026-08-20, so the code is being worked on but not being cut into tagged versions.

The licence is MIT, which is the permissive choice and appropriate for source you copy into a commercial app. The README also links an English version of the documentation, which is worth noting given that the main document is in Chinese and this component targets a specific market pattern that many English speaking developers will not recognise from the name alone.

## Conclusion

Use GHDropMenu if you are building an iOS e-commerce listing screen and want the filter menu pattern from Chinese retail apps without writing it from scratch, and if you are comfortable integrating by copying source files into your project. Do not adopt it if you need a maintained dependency with versioned releases, since the repository has no releases and no package manager manifest is described, and expect to own the fork. Before integrating, open GHDropMenuDemo.xcodeproj and run the demo on a simulator, pick one of the example view controllers as your reference implementation, and check that your deployment target is iOS 13.0 or higher.

## FAQ

### What is GHDropMenu?

It is an Objective-C iOS component providing filter menus in several styles, including a drop down top bar, a slip side filter and a floating list. The repository also ships a demo app with both Objective-C and Swift examples.

### How do I add GHDropMenu to an Xcode project?

Drag the whole GHDropMenu folder into the project with Copy items enabled and your target selected, then import GHDropMenu.h on the page that needs it, or use a bridging header in Swift. No package manager or podspec is involved.

### What is the difference between the two GHDropMenu usage modes?

The ordinary top filter attaches its popover to the current window container on its own, while the full screen slip filter must have its frame set, be added as a subview and then have show called, in that order.

### How do I close the GHDropMenu when leaving a screen?

Call closeMenu in Objective-C, for example in viewWillDisappear, and close() in Swift, which is the renamed Swift equivalent. Closing it prevents the mask from being left on the window.

### What is the minimum iOS version for GHDropMenu?

The documented minimum system version is iOS 13.0.

### How do I run the GHDropMenu demo?

Open GHDropMenuDemo.xcodeproj in Xcode, select the GHDropMenuDemo target, choose a simulator and run. Schemes GHDropMenuDemo, GHDropMenuDemo-ObjC and GHDropMenuDemo-Swift select which list you land on, controlled by the GH_ROOT_DEMO environment variable.

## Sources

- [Issues](https://github.com/shabake/GHDropMenuDemo/issues)
- [License: MIT](https://github.com/shabake/GHDropMenuDemo/blob/master/LICENSE)
- [Project website](https://github.com/shabake/GHDropMenuDemo)
- [README](https://github.com/shabake/GHDropMenuDemo/blob/master/README.md)
- [shabake/GHDropMenuDemo on GitHub](https://github.com/shabake/GHDropMenuDemo)

---

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