Skip to content

Let a notification service ask for no alert under a declared filtering policy - #75

Merged
LucaCappelletti94 merged 1 commit into
mainfrom
feat/notification-suppression
Oct 24, 2026
Merged

LucaCappelletti94 merged 1 commit into
mainfrom
feat/notification-suppression

Conversation

@LucaCappelletti94

Copy link
Copy Markdown
Owner

A #[pushups::notification_service] callback now returns Result<Rendering, Error>, where Rendering::Show(Notification) keeps the current behaviour and Rendering::NoAlert asks for no alert. An error or an empty title never means suppression.

iOS has no API to read an extension's signed entitlements, so the extension declares Apple's filtering policy itself with the PushupsNotificationFiltering key in its Info.plist, and RenderingContext::suppression() reports it. Under the declaration NoAlert completes with a fresh empty UNNotificationContent, which is Apple's suppression contract, and settles SuppressionRequested. Without it the original alert stays and the outcome is SuppressionUndeclared. Nothing in the SDK claims the alert actually disappeared, because that depends on Apple granting com.apple.developer.usernotifications.filtering, the extension being signed with it and the sender using apns-push-type: alert.

ios/check-filtering.sh compares the declaration with the signed entitlement in a built .appex and fails when they disagree, for release owners to run before shipping. ci/apple/run.sh runs it against the iOS extension signed in all four combinations, and the native harness now checks both NoAlert cases.

@LucaCappelletti94 LucaCappelletti94 added the enhancement New feature or request label Oct 24, 2026
@coderabbitai

coderabbitai Bot commented Oct 24, 2026

Copy link
Copy Markdown

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Central YAML; Path: .coderabbit.yaml
  • Review profile: ASSERTIVE
  • Plan: Advanced
  • Run ID: e36db293-5e47-4f37-8cb0-1500c9666538
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@codecov

codecov Bot commented Oct 24, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.25%. Comparing base (4c07e68) to head (34dd004).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #75      +/-   ##
==========================================
+ Coverage   94.15%   94.25%   +0.10%     
==========================================
  Files          39       39              
  Lines        4840     4930      +90     
  Branches       58       58              
==========================================
+ Hits         4557     4647      +90     
  Misses        244      244              
  Partials       39       39              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@LucaCappelletti94
LucaCappelletti94 merged commit e4c070b into main Oct 24, 2026
38 checks passed
@LucaCappelletti94
LucaCappelletti94 deleted the feat/notification-suppression branch October 24, 2026 14:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant