Open-source project
LGLibs/LGSideMenuController avatar
LGLibs/LGSideMenuController

LGSideMenuController: iOS side panel navigation via UIViewController subclass

iOS view controller which manages left and right side views

2,044 stars330 forksSwiftMIT

At a glance

What is it?
LGSideMenuController is a Swift UIViewController subclass that adds left and right sliding panels to iOS apps. 4 installation paths are documented, but several integration details including the current platform floor and programmatic toggle API are not in the README.
Who is it for?
LGSideMenuController is a workable fit for iOS projects that need left or right sliding panels without writing the gesture and animation layer from scratch. Skip it if you need programmatic toggle documentation, accessibility notes for VoiceOver focus during panel transitions, or confirmed platform requirements for the current builds, since none of those appear in the README.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 21 days ago.
What is it written in?
Mainly Swift, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 11, 2026, and from our analysis. They are not legal advice.

Editorial analysis

LGSideMenuController sits in the UIViewController hierarchy, not beside it

LGSideMenuController inherits from UIViewController, placing it inside the standard iOS view controller containment model. An iOS developer can use it as the window's root view controller, embed it inside a UINavigationController, or slot it wherever a standard UIViewController fits. One of the 4 named preview demos is labeled Slide Aside + Usage: Inside UINavigationController, confirming that the embedded case is explicitly supported.

What the controller manages is the side panel, and nothing else. Root view content, routing between destination screens, and app-level state are left to the surrounding application. Its properties accept a root view or view controller for the main content, plus optional left and right views that appear when the panel opens.

The repository root holds 8 top-level entries: .gitignore, Demo/, Framework/, LGSideMenuController.podspec, LGSideMenuController/, LICENSE, Package.swift, and README.md. The Demo directory contains 3 subdirectories: NonStoryboard/, Storyboard/, and _shared_files/. Those demo projects are the clearest path for understanding how the controller fits into a larger application, since the README usage section was truncated before the content was complete.

4 installation paths for CocoaPods, SPM, Carthage and direct source

Direct source inclusion is the lowest-friction option. Download the repository archive, add the LGSideMenuController directory to your Xcode project, and no package manager runs. Updates are then a manual replacement of that directory.

CocoaPods is the second path. Add this to your Podfile:

ruby
platform :ios, '9.0'
use_frameworks!
pod 'LGSideMenuController'

After running pod install, add the import in each Swift file that uses the library:

swift
import LGSideMenuController

Carthage accepts this Cartfile entry:

ruby
github "LGLibs/LGSideMenuController"

Swift Package Manager is available starting with Xcode 9.0. Package.swift sits at the repository root, and integration follows Apple's standard package documentation. No additional steps appear in the README for this path.

CocoaPods remains the most fully documented of the 3 package-manager options: the README includes the complete Podfile block and the import statement. The Carthage and SPM sections give only the starting configuration with links to external documentation.

3 initialization patterns for assigning root and side views

3 initialization patterns exist for configuring the controller. Pass all 3 as named parameters at construction:

swift
let sideMenuController =
    LGSideMenuController(rootViewController: UIViewController(),
                         leftViewController: UIViewController(),
                         rightViewController: UIViewController())

Or pass raw views instead of view controllers:

swift
let sideMenuController =
    LGSideMenuController(rootView: UIView(),
                         leftView: UIView(),
                         rightView: UIView())

Or assign properties after initialization:

swift
let sideMenuController = LGSideMenuController()
sideMenuController.rootViewController = UIViewController()
sideMenuController.leftViewController = UIViewController()
sideMenuController.rightViewController = UIViewController()

UIViewController() and UIView() in the code examples are placeholders; you substitute your actual view controllers or views. A left panel, a right panel, or both are valid configurations: supplying only 1 of the 2 side views is explicitly supported, and the controller adapts to whichever sides are configured.

4 named presentation styles, 2 described in text and 2 in preview animations only

4 presentation styles appear as labeled preview animations in the README: Scale From Big, Slide Above Blurred, Slide Below Shifted, and Slide Aside. 2 of them have accompanying text descriptions.

With scaleFromBig, the side view sits below the root view and scales from a large size down to normal as it appears. The root view shrinks and moves to the side simultaneously. With scaleFromLittle, the direction reverses: the side view starts small and grows to normal size, while the root view again shrinks and moves aside.

Text descriptions for Slide Above Blurred, Slide Below Shifted, and Slide Aside are not present in the README. Presentation styles are described as highly customizable and creating a custom style is possible, but the customization API is not documented in prose. That information lives in the NonStoryboard and Storyboard demos under Demo/.

Choosing between styles requires looking at those demos or at the source files in LGSideMenuController/, not just the README.

Objective-C builds and Swift builds share no API surface

Older builds of this library were written in Objective-C. Current builds are Swift. Those 2 generations share no API surface: updating from any older Objective-C copy to the current Swift code means rewriting every call site from scratch.

No migration guide appears in the repository for this transition, so a team that maintained a vendored copy of the Objective-C code and now wants to move to the current Swift code faces a full integration replacement, not a diff to apply.

Platform requirements also changed between the 2 eras. Current Swift builds require a higher iOS deployment target than the older Objective-C code did. Apps targeting older iOS will not be able to use the current Swift code, and Package.swift at the repository root is where the current iOS floor is stated.

The Demo directory has both Storyboard and NonStoryboard examples that reflect the Swift API, and those are the starting point for understanding the current integration model.

Two claims in the installation section about SPM compatibility point in opposite directions

One entry in the installation section contradicts another in the same section. Swift Package Manager support is documented as beginning at version 2.3.0, while the installation compatibility table in the same section identifies version 2.3.0 as an Objective-C release. SPM can build packages containing Objective-C source when Package.swift declares the appropriate source targets, but whether the Package.swift at the repository root was written to include the historical Objective-C code or only covers the current Swift builds is not explained.

Those 2 statements sit adjacent in the installation section without resolution. For a developer adding this library via SPM today, the authoritative source is Package.swift at the repository root, which gives the current platform configuration directly rather than through a note that disagrees with its neighboring table.

Programmatic toggle, accessibility behavior and iPad layout are undocumented

Several integration requirements for a shipping app have no documentation in the README. A method for opening or closing the side panel without a user gesture is not documented, so developers who need a hamburger button to trigger the panel must inspect the source files in LGSideMenuController/ directly.

Accessibility is not mentioned. VoiceOver focus during an open or close transition, reduced-motion alternatives for the scale and slide animations, and how the panel interacts with Dynamic Type are all open questions. The repository topics include ios but nothing accessibility-specific.

Rotation and iPad split-view behavior are also absent. No claim about split-view compatibility appears in the README, and how the panel width adapts to device orientation or multitasking configurations is unspecified.

Delegate or notification hooks for panel state changes are not documented either. An app that needs to update a navigation bar button or pause audio when the side panel opens or closes has no documented path in the README for receiving those events. All of these gaps require reading the source in LGSideMenuController/ rather than relying on any written documentation.

Editorial conclusion

LGSideMenuController is a workable fit for iOS projects that need left or right sliding panels without writing the gesture and animation layer from scratch. Skip it if you need programmatic toggle documentation, accessibility notes for VoiceOver focus during panel transitions, or confirmed platform requirements for the current builds, since none of those appear in the README. Before committing to it, read Package.swift at the repository root to confirm the current iOS floor, and work through the Storyboard or NonStoryboard demo in the Demo directory to see the presentation-style API that the README's usage section did not reach.

Frequently asked questions

Does LGSideMenuController support both a left and a right side menu at the same time?

Both a left and a right side view can be assigned to a single LGSideMenuController instance. Providing only 1 side is also valid; the controller adapts to whichever sides are configured.

What iOS version does LGSideMenuController require?

Package.swift at the repository root is where the current iOS floor is stated. The README's installation section does not give the specific iOS minimum for current builds, so that file is the authoritative check.

Can LGSideMenuController be used inside a UINavigationController?

One of the 4 named preview demos is labeled Slide Aside + Usage: Inside UINavigationController, showing that embedding the controller inside a UINavigationController is a supported and demonstrated pattern.

Is LGSideMenuController compatible with CocoaPods, Carthage and Swift Package Manager?

All 3 are documented alongside direct source inclusion. The Podfile entry is pod 'LGSideMenuController', the Cartfile entry is github "LGLibs/LGSideMenuController", and SPM integration follows Apple's standard package documentation from Xcode 9.0 onward.

Is LGSideMenuController still maintained?

The repository is not archived and the last push was on 2026-09-20. Activity has been intermittent, so checking the GitHub project page directly gives the most current picture.

Official sources

  1. Issues
  2. LGLibs/LGSideMenuController on GitHub
  3. License: MIT
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/lglibs-lgsidemenucontroller.svg)](https://hysenlabs.com/projects/lglibs-lgsidemenucontroller)