This document captures all open threads from the iOS notification / Spring Boot work that ran from 2026-05-09 → 2026-05-18, so a fresh Claude session (or human) can resume without re-deriving context.
fix/ios-notifications branch — 6 clean commits, based on main, contains only the iOS notification fix arc and supporting CI/docs. All tests pass (420/420), analyze is clean.archive/spring-boot-backend (identical to claude/issue-379-20260304-1459). Will be resumed later.| Branch | Purpose | Status |
|---|---|---|
| main | Production-ish baseline | Untouched in this session |
| fix/ios-notifications | Clean notification fix, 6 commits on top of main | Pushed, ready for PR against main |
| archive/spring-boot-backend | Preservation of the entire Spring Boot migration | Pushed; identical to claude/issue-379-20260304-1459 |
| claude/issue-379-20260304-1459 | The 45-commit feature branch where all the debugging happened | Untouched. Same content as the archive branch above. PR #428 still open against main from this. |
The fix/ios-notifications branch is ready for review and merge against main.
gh pr create \
--base main \
--head fix/ios-notifications \
--title "fix(notifications): make iOS notification prompt actually appear + UX cleanup" \
--body-file /dev/stdin <<'EOF'
## Summary
Six logically-grouped commits that fix the long-standing iOS bug where
the notification permission prompt never appeared on Roomy Staging
(symptom: no Notifications row under iOS Settings → Roomy). Root
cause was a missing `PERMISSION_NOTIFICATIONS=1` preprocessor macro in
`ios/Podfile`; with it absent, `permission_handler` compiled in stub
mode and `Permission.notification.request()` returned `denied`
without ever calling `UNUserNotificationCenter.requestAuthorization`.
## Commits
- `88ee0f7b` fix(notifications): create preferences document on first consent
- `33d26635` fix(notifications): close 11 push notification gaps + UX polish
- `af7dba7f` fix(ios): enable permission_handler PERMISSION_NOTIFICATIONS + CI guard
- `1bd24eae` fix(posthog): require manual setup via AUTO_INIT=false
- `40805f77` ci: commit pubspec.lock so CI uses pinned plugin versions
- `6d316285` docs: changelog the iOS notification + permission fix arc
## What's documented
- `docs/ios-notifications.md` — full setup contract (8 preconditions),
local verification, historical context.
- `scripts/check_ios_permission_notifications.sh` — CI guard that fails
the build with a reproducing snippet if the macro disappears.
- `codemagic.yaml` staging-internal-testing — runs the guard before
pod install.
## Test plan
- [ ] Install staging build from TestFlight on a fresh iPhone.
- [ ] First launch shows consent sheet ~1s after home view.
- [ ] Tapping "Allow" shows the iOS system permission dialog.
- [ ] After granting, Settings → Roomy Staging shows the Notifications row.
- [ ] In-app toggle becomes interactive; toggling off/on persists.
- [ ] Adding a shopping item from a second account in the same household
delivers a push notification within ~30s.
- [ ] Logging out clears the FCM token so the device stops receiving pushes.
## CI verification
- `flutter analyze` — only pre-existing deprecation warnings on `font_weight_extension.dart`, no new errors.
- `flutter test` — 420/420 pass.
- `flutter build web --dart-define=env=staging` — succeeds.
- `./scripts/check_ios_permission_notifications.sh ios/Podfile` — passes.
EOF
I prepared a close list but did NOT execute it. Close (not delete) so they can be reopened later.
| # | Title | Status |
|---|---|---|
| #379 | 🚀 Epic: Full Firebase replacement with Spring Boot + PostgreSQL + WebSockets + MinIO | Pause — preserved on archive/spring-boot-backend |
| #376 | ✨ [Backend] POST /api/households/{householdId}/members/remove | Sub-task of #379 |
| #398 | 🔐 Integrate 1Password MCP server for secret management | Was added for Spring Boot deploy secrets |
| #403 | [RMY-380] Flutter: add REST API client layer for Spring Boot backend | Client half of #379 |
| #405 | [RMY-405] Backend: transactional mail service | Sub-task of #406 |
| #406 | [RMY-406] Backend: custom accounts service to replace Firebase Authentication | Sub-task of #379 |
| #411 | [RMY-INFRA] Set up TransIP VPS to host Spring Boot backend (staging) | Infra for #379 |
| #426 | security: implement automated database and MinIO credential rotation | DB + MinIO = #379-only |
| # | Title | Status |
|---|---|---|
| #402 | [RMY-379] Backend: combined Java implementation | The Spring Boot PR itself |
| #428 | fix(notifications): create preferences document when none exists on consent | Head branch contains all Spring Boot work; superseded by fix/ios-notifications which is clean |
Paused for now; work preserved on the archive/spring-boot-backend branch.
Re-open when ready to resume.
These are open threads we identified but didn't fully close because they need someone to act in a console / external system.
fix/ios-notifications
(which goes much further — also fixes the iOS prompt).vars.FIREBASE_PROJECT_ID in repo settingsdeploy-firebase-hosting.yml and deploy-website.yml both fire on
push: main and target whichever Firebase project that variable
points to.gh variable list --repo mahmoudholding/roomy-mobile | grep FIREBASE_PROJECT_ID
and either confirm it's the staging project or gate those workflows
behind a tag like the production-firebase workflow.fix/ios-notificationscodemagic.yaml (line 599, staging-internal-testing)
uses Codemagic API Key 20241205. We discovered on the feature
branch that the .p8 for that integration is stale and altool's JWT
auth fails silently.archive/spring-boot-backend we switched staging-internal to
code_magic_new (the freshly-rotated App Manager key).fix/ios-notifications also use
code_magic_new for staging-internal? Probably yes — otherwise the
staging TestFlight upload from this branch will hit the same altool
error we already debugged. The other workflows (beta, ios-beta,
android-beta, release-draft) can keep using Codemagic API Key 20241205
for now since they're triggered by tags, not branch pushes — but
whoever cuts the next production tag will need to rotate that one too.staging-internal-testing. The same Podfile is shared by all
workflows, so technically only one workflow needs the guard for it
to catch regressions. Worth considering whether to also add it to
the beta and release-draft workflows for redundancy.ios/Podfile post_install block.lib/notifications/services/push_notification_handler.dart,
lib/households/views/home/home_view_model.dart,
lib/auth/services/auth_service.dart,
ios/Runner/AppDelegate.swift.roomy-firebase/functions/src/notifications/services/NotificationService.ts.ios/Runner/Info.plist, android/app/src/main/AndroidManifest.xml
both have AUTO_INIT=false.docs/ios-notifications.md — full setup contract.~/projects/prive/docs/roomy-mobile/decisions/decisions/20260517-1530-ios-notification-permission-macro.md —
why we treat PERMISSION_NOTIFICATIONS=1 as load-bearing.~/.claude/projects/-Users-sarkout-projects-prive-roomy-mobile/memory/project_ios_notifications.md.6757333336, bundle app.theroomy.mobile.staging) is alive and accepting TestFlight uploads via the rotated code_magic_new App Manager API key.v*.*.* or *-release).gh pr create --base main --head fix/ios-notifications (see above for body).fix/ios-notifications's codemagic.yaml staging-internal app_store_connect to code_magic_new (one-line edit, push). Then CI should go fully green.vars.FIREBASE_PROJECT_ID in repo settings; decide whether to leave hosting deploys on main or gate them behind a tag.v1.3.0 to trigger the production-firebase + Codemagic release-draft workflows. Note: production App Store / Play Store get the new build as a draft, not auto-published.
Reacties