---
title: "Verify iOS notification denial keeps inbox updates usable"
description: "Check that an iOS app with externally denied notification permission still presents new sandbox activity through its in-app inbox and read state."
canonical_url: "https://vostride.com/agent-library/ios-flows/notification-denial-in-app-inbox.md"
md_url: "https://vostride.com/agent-library/ios-flows/notification-denial-in-app-inbox.md"
content_kind: "recipe"
topic: "ios-flows"
---

# Verify iOS notification denial keeps inbox updates usable

Check that an iOS app with externally denied notification permission still presents new sandbox activity through its in-app inbox and read state.

## Risk

Push permission and in-app activity delivery are separate product concerns. Verify inbox synchronization directly so the absence of an operating-system notification is not confused with absence of the underlying event.

## Fixtures

- An iOS sandbox device with notifications denied by an external permission fixture and use.mobile.appState explicitly selected to retain the prepared state.
- A test account with an empty unread inbox and an external sandbox event producer capable of generating one task-assignment event.
- A project-owned activity oracle exposing event identity and per-user read status without relying on push delivery receipts.

## Steps

1. Open notification settings inside the app and verify the denied-permission explanation is consistent with the external device fixture.
2. Trigger the prepared sandbox assignment through the external event producer and verify its report contains the expected activity identifier.
3. Open or refresh the in-app inbox and verify the new activity title, task identifier, and unread marker appear despite denied push permission.
4. Open the activity and verify it routes to the assigned task; return to the inbox and verify the item is now read.
5. Inspect the independent activity oracle and verify this user has one event and one read transition for the expected task, without changing device permission.

## Expected results

- The in-app activity exists independently of operating-system push authorization.
- The activity opens the intended task and becomes read for the test user.
- The external permission fixture remains denied throughout the run.

## False-pass traps

- A stale inbox item with the same task title can masquerade as the newly generated event.
- Enabling permission during setup silently bypasses the intended denied-permission path.

## Cleanup

- Remove the sandbox activity and assignment, then reset the test inbox fixture.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa mobile testing](/docs/agent-qa/guides/mobile-testing.md)
- [agent-qa test](/docs/agent-qa/configuration/test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)

- [iOS application QA recipes](/agent-library/ios-flows.md)
- [Software factory QA library](/agent-library.md)