Reduce the gap under category pills on the Discover category page

[mdrockwell]

📘 Part of: #

Fixes PCIOS-193

On a selected-category Discover page (e.g. after tapping Comedy), the "Most Popular in …" list title sat 30pt below the category pills, leaving a large empty band. This reduces that title's top padding to 16pt in the selected-category context, so it matches the pills-to-content spacing on the root Discover screen — where the pills carry a 16pt bottom inset that drops to 0 once a category is selected.

The change is scoped to the selected-category context (category != nil in LargeListSummaryViewController), so large lists elsewhere in the Discover feed keep their existing spacing.

Before

After

To test

1. Open the Discover tab.
2. Tap a category pill (e.g. Fiction or Society & Culture).

• Verify the "Most Popular in …" heading sits snugly under the pills — roughly the same gap as between the pills and the featured carousel on the root Discover screen, not a large empty band.
• Scroll the category page and confirm the list/sections below look unchanged.
• Tap ✕ to return to the root Discover screen and confirm large lists there are unchanged (still the default spacing).

Checklist

• I have considered if this change warrants user-facing release notes and have added them to CHANGELOG.md if necessary.
• I have considered adding unit tests for my changes.
• I have updated (or requested that someone edit) the Event Horizon schema to reflect any new or changed analytics.

[claude]

Claude finished @mdrockwell's task in 1m 26s —— View job

---

Code Review: Reduce gap under category pills

• Read the PR diff and surrounding file
• Trace how category is populated to confirm scoping
• Cross-check the 16pt value against CategoriesPillsView insets
• Post review

---

Nice, focused change. The logic is correct and the scoping via category != nil is sound — I traced it and selectedCategory is only threaded into a cell's populateFrom(...category:) from the category-page path (DiscoverCollectionViewController+Categories.swift), and is explicitly nil'd for the categories selector itself. On the root Discover feed no category is passed, so large lists there keep the xib default. 👍 The doc comment is genuinely helpful too.

A few minor, non-blocking notes:

1. category has no didSet → possible stale constraint (minor robustness)

category is a plain stored property (LargeListSummaryViewController.swift:32), and populateFrom(...) sets it without triggering a layout pass. Contrast with padding, whose didSet calls view.setNeedsLayout(). If viewDidLayoutSubviews happens to run its last pass before category is assigned, the title constraint would be left at the xib default until some other event forces a relayout.

In practice you're almost certainly saved by the subsequent reloadData() / height-constraint changes and viewWillAppear, so this likely never shows in the wild — but it's a latent ordering assumption. Mirroring padding's behavior would make it explicit and self-documenting:

private var category: DiscoverCategory? {
    didSet {
        view.setNeedsLayout()
    }
}

Fix this →

2. The 16pt is a manual copy of CategoriesPillsView.Constants.buttonInsets.bottom

The comment does a great job documenting the coupling, so this is acceptable as-is. Worth noting the value can't be referenced directly today because CategoriesPillsView.Constants is fileprivate (CategoriesSelectorView.swift:90) — so wiring them together would require widening that access. Not worth it for a single constant; just flagging that if the pill inset ever changes, this value must be updated by hand.

3. Fixed padding doesn't scale with Dynamic Type

categoryPageTitleTopPadding is a fixed 16pt and won't grow at accessibility text sizes (unlike cellExtraHeight, which scales). This matches the intent — it's a spacing gap meant to mirror the pills-to-content gap, which is itself fixed — so I don't think it needs to change. Just calling it out since the file otherwise takes care with UIFontMetrics.

Summary: Looks good to merge. The didSet in note 1 is the only thing I'd consider tightening up, and even that is defensive rather than a known bug. Nothing here is a correctness, security, or performance concern.
• pcios-193-fix-and-reduce-spacing-under-category-pills-on-ios

[CLAassistant]

All committers have signed the CLA.

[dangermattic]

	1 Error
🚫	PR requires at least one label.

	1 Warning
⚠️	PR is not assigned to a milestone.

Generated by 🚫 Danger

[claude]

Claude finished @mdrockwell's task in 1m 35s —— View job

---

Code Review: Reduce gap under category pills

• Read the diff and surrounding file (LargeListSummaryViewController.swift)
• Trace how category is threaded through to confirm scoping
• Verify the 16pt value against CategoriesPillsView insets
• Check the category-page layout for other affected large lists
• Post review

---

Focused, well-documented change — I re-traced it and it holds up. Verified findings:

✅ Correctness & scoping. viewDidLayoutSubviews (LargeListSummaryViewController.swift:93-97) now uses Self.categoryPageTitleTopPadding (16) when category != nil, otherwise falls back to the existing padding / 2. category is only non-nil on the selected-category path: DiscoverCollectionViewController.populateFrom explicitly nils it for the categoriesSelector cell (DiscoverCollectionViewController.swift:129) and only the category reload passes a selectedCategory (DiscoverCollectionViewController+Categories.swift:22). Root Discover large lists get no category → unchanged. 👍

✅ The 16pt is the right value. Confirmed against CategoriesSelectorView.swift:91 — buttonInsets = EdgeInsets(top: 2, leading: 16, bottom: 16, trailing: 16), so .bottom == 16. The doc comment documenting this coupling is genuinely helpful, since CategoriesPillsView.Constants is fileprivate and can't be referenced directly today.

✅ Targets exactly the intended element. On a category page the "Most Popular in …" large_list is inserted at index 1, directly under the pills at index 0 (DiscoverCollectionViewController+Categories.swift:49-61); the full category grid below is a different cell type (category_podcast_list). So the tightened padding lands on the one list sitting under the pills — not the grid.

One thing to keep in mind (not a bug): the branch keys on category != nil, not on list position. So any large list tagged with the selected categoryID would get 16pt. In today's layout that's just the single "Most Popular" item, so there's no regression — but if a future category layout ever surfaces a second large_list, it would inherit the tighter spacing too. Fine given the current design; just worth knowing the scope is "all category large lists," not "the first one."

Minor / non-blocking:

category is a plain stored property (LargeListSummaryViewController.swift:32) with no didSet, unlike padding which calls view.setNeedsLayout() on change (:36-40). populateFrom sets category without forcing a relayout, so it relies on a later pass (reloadData() / viewWillAppear / height-constraint change) to re-run viewDidLayoutSubviews. In practice that always happens here, so this is defensive rather than a real bug — but mirroring padding's didSet would make the intent explicit:

private var category: DiscoverCategory? {
    didSet {
        view.setNeedsLayout()
    }
}

Fix this →

Summary: Correct, well-scoped, and the fixed 16pt (rather than a Dynamic-Type-scaled value) is appropriate since it mirrors a fixed spacing gap. No correctness, security, or performance concerns. Good to merge — the didSet is the only optional tightening.
• Branch: pcios-193-fix-and-reduce-spacing-under-category-pills-on-ios

[kean]

Thank you for the PR! The code looks good. I'm going to assign to the design team to confirm it.

Unrelated to the PR, it would be nice to figure out why the text gets clipped here.

[kean]

Let's remove this comment.

[mdrockwell]

Is that something I'll need to take care of and resubmit or can it be handled another way?

[kean]

I'll take care it. Claude tends to over-document. This is something you typically put in the commit message instead.