Introduction

A UIPageViewController created with the scroll transition style uses an internal scroll view to handle swiping between pages. If you want to disable the swipe gesture, the usual solution is to disable scrolling on that internal view. The important part is that you are not disabling page changes entirely. You are disabling the user's swipe interaction while keeping programmatic navigation available.

Find the Internal Scroll View

For the .scroll transition style, UIPageViewController embeds a UIScrollView internally.

1import UIKit
2
3final class PagerController: UIPageViewController {
4    func setSwipeEnabled(_ enabled: Bool) {
5        for view in view.subviews {
6            if let scrollView = view as? UIScrollView {
7                scrollView.isScrollEnabled = enabled
8            }
9        }
10    }
11}

Calling setSwipeEnabled(false) disables the swipe gesture because the internal scroll view no longer scrolls.

Programmatic Page Changes Still Work

Disabling the scroll gesture does not prevent you from changing pages in code.

let next = UIViewController()
setViewControllers([next], direction: .forward, animated: true, completion: nil)

This is often exactly what you want for onboarding flows, wizard steps, or any sequence where navigation should be controlled by buttons instead of free swiping.

Gesture Recognizers Are Another Possible Layer

UIPageViewController also exposes gesture recognizers, but disabling them directly is usually a rougher tool than disabling the embedded scroll view. The scroll view approach is typically simpler and more predictable for the scroll transition style.

That said, if your setup uses a different transition style or extra custom gesture interactions, you may need to inspect which recognizers are active and whether they conflict with other views.

In other words, disable the mechanism that is actually driving page changes rather than guessing at every recognizer you see attached.

Reapply the Setting at the Right Time

If the page view controller is recreated, reconfigured, or embedded in a more dynamic container, make sure the swipe-disable logic runs after the internal subviews exist.

In practice, that usually means doing it in or after viewDidLoad, not before the page view controller's view hierarchy has been created.

Be Clear About the UX Tradeoff

Disabling swipe changes the feel of the interface. That is sometimes exactly the goal, but it means you should provide an obvious alternative way to move between pages.

If the user cannot swipe, they should still be able to understand how to continue. Buttons, progress indicators, and clear affordances matter more once the default gesture is gone.

This keeps the controller intentional instead of merely restrictive.

That small UX detail often matters more than the gesture code itself.

Users should never feel trapped on a page.

Clear exit paths matter.

This Applies Mainly to .scroll

The common "disable swipe" technique targets the internal scroll view, which is relevant to the .scroll transition style. If you are using .pageCurl, the internals and interaction model are different.

That is why understanding the transition style matters before copying a gesture-disabling snippet blindly.

Common Pitfalls

• Disabling the wrong view instead of the internal UIScrollView.
• Assuming programmatic page changes will stop working after swipe is disabled.
• Running the logic before the view hierarchy exists.
• Forgetting to provide another navigation mechanism once swipe is removed.
• Applying the scroll-view solution without checking which transition style is in use.

Summary

• For a scroll-style UIPageViewController, disabling swipe usually means disabling the embedded UIScrollView.
• Programmatic page changes can still work normally.
• Apply the change after the internal view hierarchy has been created.
• Be intentional about the UX when the default swipe gesture is gone.
• Check the transition style before assuming the same internal approach will apply.