The unfortunate thing is we don't have iOS devices on-hand to test. It seems like a frustrating issue though

As for how it works under-the-hood, it's exactly as you imagine, a simple #anchor pointing to an element with the corresponding id (or maybe it's name, I forget now). It should just work.

I also have the same question because I have noticed similar inconsistent navigation behavior in Safari when using pages with multiple sections and shortcut links. Sometimes clicking a shortcut takes me exactly where I expect, while other times nothing happens or the page jumps to a completely different position. It can be difficult to figure out what is causing it, especially when the same functionality works normally in other browsers. Since this issue is appearing in the NodeBB administrator control panel, I wonder whether Safari handles the scrolling or anchor positioning differently, particularly when the submenu is long and the shortcut list remains visible while scrolling.

$('[component="settings/toc"] a[href^="#"]').on('click', function () {
	const href = $(this).attr('href');
	const $target = $(href);
	if (!$target.length) {
		return;
	}
	$target.get(0).scrollIntoView(true);
	window.location.hash = href;
	scrollBy(0, -offset);
	setTimeout(() => {
		tocList.find('a').removeClass('active');
		$(this).addClass('active');
	}, 10);
	return false;
});

It turns out we already use javascript to do the scroll https://github.com/NodeBB/NodeBB/blob/master/public/src/admin/settings.js#L31, so wondering why that code wasn't working but the one I gave you earlier works, one difference is the true paramater passed to scrollIntoView. Let me know if this second version works.

$('[component="settings/toc"] a[href^="#"]').on('click', function (e) {
  const href = $(this).attr('href');
  const $target = $(href);
  if (!$target.length) {
    return;
  }

  $target.get(0).scrollIntoView(true);
  return false;
});

It should replace the default browser behaviour with a JS version that brings the target into view.