Silent push throttling prevents consistent background delivery for Swift notifications

When designing a Swift notification strategy that balances useful alerts with minimal user noise, silent pushes using content-available:1 appear attractive because they avoid visible banners or sounds. However, iOS background execution limits can throttle these pushes, leading to inconsistent delivery of application(_:didReceiveRemoteNotification:fetchCompletionHandler:) callbacks.

Complicating this, if a user denies authorization after a UNUserNotificationCenter.requestAuthorization call, later attempts return granted:false without re-prompting unless the user manually changes Settings. Repeated requests can also trigger system rate-limiting, which silently drops further alerts until the app is opened.

Given these constraints, what is the recommended pattern for scheduling low-noise alerts that remain reliable? Should silent pushes be paired with local notifications and UNNotificationCategory.customDismissAction to reduce perceived noise, or does the risk of throttling make that combination unreliable? How should an app detect that it has entered a throttled or denied state without prompting the user repeatedly?