Mike/Kordant
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

get to prod tasks

Browse Source
This commit is contained in:
Michael Freno
2026-05-26 16:06:34 -04:00
parent 04e839640f
commit 5214412fff
105 changed files with 7447 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

82
tasks/ios-production/01-app-store-screenshots.md Normal file
View File

@@ -0,0 +1,82 @@
# 01. App Store Screenshots & Metadata
meta:
id: ios-production-01
feature: ios-production
priority: P1
depends_on: []
tags: [app-store, marketing, production]
objective:
- Create and upload all required App Store screenshots and metadata for iOS app submission
deliverables:
- Screenshots for all required device sizes
- App metadata (name, subtitle, description, keywords)
- App Store listing content
- Promotional text and updates
steps:
1. Determine required screenshot sizes:
- iPhone 6.7" (iPhone 14 Pro Max, 15 Pro Max): 1290x2796
- iPhone 6.5" (iPhone 14 Plus, 13 Pro Max): 1284x2778
- iPhone 5.5" (iPhone 8 Plus, SE 3rd gen): 1242x2208
- iPad Pro 12.9" (6th gen): 2048x2732
- iPad Pro 11" (4th gen): 1668x2388
2. Create screenshot content plan:
- Screenshot 1: Dashboard with threat score and alerts
- Screenshot 2: DarkWatch exposure list
- Screenshot 3: VoicePrint enrollment screen
- Screenshot 4: SpamShield call log/filtering
- Screenshot 5: HomeTitle property monitoring
- Screenshot 6: Settings and profile
- Screenshot 7: Family plan management (if applicable)
- Screenshot 8: Push notification example
3. Capture or generate screenshots:
- Use iOS Simulator for precise sizing
- Or use Screenshotting library for programmatic capture
- Ensure status bar shows 9:41 and full battery
- Use clean data (no real user info)
4. Write app metadata:
- App Name: Kordant (30 chars max)
- Subtitle: AI Identity Protection (30 chars max)
- Description: 4000 chars highlighting features, benefits, use cases
- Keywords: identity protection, dark web, spam blocker, voice clone, privacy (100 chars max)
- Support URL, Marketing URL
- Copyright info
5. Prepare App Store listing:
- Primary category: Utilities or Lifestyle
- Secondary category: Productivity or Security
- Content rating: 4+ (no objectionable content)
- Age rating questionnaire completed
6. Upload to App Store Connect:
- Use Transporter app or Xcode upload
- Verify all screenshot sizes present
- Preview metadata in App Store Connect
tests:
- Visual: Review screenshots for quality and consistency
- Content: Verify no placeholder or test data visible
- Compliance: Check content rating accuracy
acceptance_criteria:
- Screenshots for all 5 required device sizes
- 5-8 screenshots per device size showing key features
- App metadata complete and within character limits
- Screenshots show real app UI with clean demo data
- Status bar shows 9:41 time and full battery
- No beta/test labels visible in screenshots
- Content rating accurate and complete
- All assets uploaded to App Store Connect
validation:
- App Store Connect → all screenshot slots filled
- Screenshots reviewed by designer → approved
- Metadata spell-checked and reviewed
- Content rating questionnaire submitted
notes:
- Use screenshot frames (iPhone bezel) for professional look
- Consider localized screenshots for major markets (EN, ES, FR)
- Screenshots are the #1 factor in app store conversion
- Update screenshots with each major UI release

79
tasks/ios-production/02-app-preview-video.md Normal file
View File

@@ -0,0 +1,79 @@
# 02. App Preview Video
meta:
id: ios-production-02
feature: ios-production
priority: P2
depends_on: []
tags: [app-store, marketing, production]
objective:
- Create a compelling App Preview video for the App Store to increase conversion rates
deliverables:
- 15-30 second App Preview video
- Video for required device sizes
- Captions or text overlays
- Professional quality and pacing
steps:
1. Plan the video narrative:
- 0-5s: Hook — identity threat scenario (notification)
- 5-15s: Solution — open app, see dashboard, run scan
- 15-25s: Features — DarkWatch, VoicePrint, SpamShield highlights
- 25-30s: CTA — "Protect your identity today"
2. Record screen capture:
- Use iOS Simulator screen recording (cmd+S)
- Or use QuickTime with connected device
- Record at native resolution (no scaling)
- Use clean demo account with realistic data
3. Edit the video:
- Use iMovie, Final Cut Pro, or CapCut
- Add smooth transitions between scenes
- Add text overlays for feature names
- Add background music (royalty-free, upbeat)
- Ensure pacing feels natural (not too fast)
4. Create required sizes:
- iPhone: 1080x1920 (portrait) or 1920x1080 (landscape)
- iPad: 1200x1600 (portrait) or 1600x1200 (landscape)
- Max file size: 500MB
- Format: MOV, M4V, or MP4 (H.264)
5. Add accessibility:
- Captions/subtitles for all spoken text
- Ensure color contrast for text overlays
- Avoid rapid flashing (photosensitive epilepsy)
6. Test and iterate:
- Show to team members for feedback
- A/B test different versions if possible
- Ensure video loops well (App Store autoplays)
7. Upload to App Store Connect:
- Upload preview video for each device size
- Verify autoplay and thumbnail
tests:
- Visual: Review video quality and pacing
- Technical: Verify format and size requirements
- Content: Ensure no confidential data shown
acceptance_criteria:
- 15-30 second video showcasing core app features
- Video for iPhone and iPad sizes
- Smooth transitions and professional pacing
- Text overlays for feature highlights
- Background music (royalty-free)
- Captions/subtitles included
- No placeholder or test data visible
- File size <500MB per video
- Uploaded to App Store Connect
validation:
- Play video → smooth, engaging, clear features
- Check technical specs → correct resolution, format, size
- Team review → approved by 3+ team members
- App Store Connect → video preview active
notes:
- App Preview videos auto-play muted in App Store
- First 5 seconds are critical for engagement
- Consider creating 3 shorter videos for different features
- Videos can significantly increase conversion rates

84
tasks/ios-production/03-app-store-connect.md Normal file
View File

@@ -0,0 +1,84 @@
# 03. App Store Connect Configuration
meta:
id: ios-production-03
feature: ios-production
priority: P1
depends_on: []
tags: [app-store, configuration, production]
objective:
- Complete all App Store Connect configuration for app submission and distribution
deliverables:
- App record created in App Store Connect
- Bundle ID registered and configured
- Signing certificates and provisioning profiles
- App Review information
- Pricing and availability
steps:
1. Create App Store Connect record:
- App name: Kordant
- Primary language: English
- Bundle ID: com.kordant.app (or existing)
- SKU: kordant-001
- User Access: Full access for team
2. Configure app capabilities:
- Push Notifications (entitlements configured)
- Background Modes (fetch, remote notifications)
- Camera (for document scanning)
- Microphone (for VoicePrint enrollment)
- Face ID / Touch ID (biometric auth)
- Associated Domains (universal links)
3. Set up signing:
- Apple Developer account ($99/year)
- Create Distribution certificate
- Create App Store provisioning profile
- Configure Xcode with correct team and signing
4. Configure pricing:
- Price tier: Free (subscription handled in-app or via web)
- If in-app purchases: configure in App Store Connect
- Subscription groups and tiers
- Introductory offers (free trial)
5. Set availability:
- All countries or selected markets
- Pre-order option (optional)
- Release strategy (manual or automatic)
6. Prepare App Review info:
- Contact information
- Demo account credentials (username/password for testing)
- Notes for reviewer (explain app functionality)
- Attachment: privacy policy, terms of service
7. Configure TestFlight:
- Internal testers (team members)
- External testers (beta group)
- Test information and feedback email
tests:
- Build: Archive and validate app in Xcode
- Upload: Upload build to App Store Connect
- Verification: Confirm build appears in TestFlight
acceptance_criteria:
- App record created in App Store Connect
- Bundle ID registered and matches Xcode project
- Distribution certificate and provisioning profile active
- All required capabilities enabled
- Pricing set (free with subscriptions)
- Availability configured for target markets
- App Review information complete with demo account
- TestFlight configured with internal testers
- Build successfully uploaded and processing
validation:
- Xcode → Product → Archive → Validate → no errors
- Upload build → appears in App Store Connect within 30 minutes
- TestFlight → build available for internal testing
- App Review info → all fields complete
notes:
- Ensure Apple Developer membership is active and paid
- Bundle ID must match exactly across all configs
- Demo account is critical for reviewer testing
- TestFlight builds must be signed with Distribution cert

80
tasks/ios-production/04-testflight-beta.md Normal file
View File

@@ -0,0 +1,80 @@
# 04. TestFlight Beta Distribution
meta:
id: ios-production-04
feature: ios-production
priority: P1
depends_on: []
tags: [app-store, testing, production]
objective:
- Set up TestFlight beta testing with internal and external testers to validate app before public release
deliverables:
- Internal testing group configured
- External testing group with 20+ testers
- Beta testing feedback process
- Crash reporting for beta builds
steps:
1. Configure internal testing:
- Add all team members to App Store Connect
- Create internal testing group
- Upload first beta build
- Verify team members can install via TestFlight app
2. Recruit external testers:
- Create external testing group "Kordant Beta"
- Invite 20-100 external testers via email or public link
- Target: mix of technical and non-technical users
- Include iPhone and iPad users
- Include different iOS versions (16, 17, 18)
3. Prepare beta testing materials:
- Beta app description and what to test
- Feedback email or link (TestFlight feedback)
- Known issues list
- Testing checklist for testers
4. Set up crash reporting:
- Enable TestFlight crash reporting in Xcode
- Integrate Firebase Crashlytics for detailed crashes
- Configure alerts for crash spikes
5. Distribute beta builds:
- Upload new build → auto-distribute to internal testers
- Submit for external testing review (first build only)
- Distribute to external testers after approval
6. Collect and triage feedback:
- Review TestFlight feedback daily
- Create issues from feedback in task tracker
- Respond to critical feedback within 24 hours
- Track bug reports and feature requests
7. Iterate based on feedback:
- Fix critical bugs within 1 week
- Address UI/UX issues before public release
- Update beta build every 1-2 weeks
tests:
- Distribution: Verify testers receive build notifications
- Feedback: Test feedback submission process
- Crash: Verify crash reports appear in Firebase
acceptance_criteria:
- Internal testing group with all team members
- External testing group with 20+ active testers
- First beta build distributed and installed successfully
- TestFlight feedback channel active
- Crash reporting receiving reports
- Beta testing checklist provided to testers
- Known issues documented and shared
- Iteration cycle: new build every 1-2 weeks
- Zero critical crashes in last 2 beta builds
validation:
- TestFlight app → build available for install
- External tester installs app → no issues
- Submit feedback → appears in App Store Connect
- Simulate crash → report appears in Firebase
notes:
- External testing requires App Review approval for first build
- Public link allows anyone to join without invitation
- Beta testing typically takes 2-4 weeks before release
- Use TestFlight groups to test different features

72
tasks/ios-production/05-certificate-pinning.md Normal file
View File

@@ -0,0 +1,72 @@
# 05. Certificate Pinning & TLS Validation
meta:
id: ios-production-05
feature: ios-production
priority: P1
depends_on: []
tags: [security, networking, production]
objective:
- Implement certificate pinning and TLS validation to prevent man-in-the-middle attacks on API communications
deliverables:
- Certificate pinning implementation in APIClient
- TLS 1.3 enforcement
- Certificate expiration monitoring
- Fallback handling for certificate rotation
steps:
1. Obtain server certificates:
- Export production server certificate or public key
- Include intermediate certificates if needed
- Store certificate hash in app bundle
2. Implement certificate pinning:
- Modify iOS/Kordant/Services/APIClient.swift
- Use URLSessionDelegate with didReceiveChallenge
- Compare server certificate with pinned hash
- Support both certificate pinning and public key pinning
3. Configure TLS settings:
- Enforce TLS 1.3 minimum
- Disable weak cipher suites
- Enable certificate transparency checking
- Configure ATS (App Transport Security) in Info.plist
4. Add certificate rotation support:
- Support multiple pinned certificates (old + new)
- Grace period during rotation (30 days)
- Alert when certificate nearing expiry
5. Implement fallback strategy:
- If pinning fails, allow connection with additional verification
- Log pinning failures for monitoring
- Consider allowing override for enterprise users
6. Add tests:
- Test with correct certificate → connection succeeds
- Test with wrong certificate → connection fails
- Test certificate rotation → seamless transition
tests:
- Unit: Test pinning with mock certificates
- Integration: Test against staging with pinned cert
- Security: Attempt MITM with Charles Proxy → blocked
acceptance_criteria:
- Certificate pinning active on all API requests
- TLS 1.3 enforced for all connections
- MITM attacks blocked (tested with proxy tools)
- Certificate rotation supported with grace period
- Pinning failures logged for monitoring
- ATS configured in Info.plist
- Unit tests covering pinning success and failure
- No hardcoded certificates in source code (use hashes)
validation:
- Run app with correct cert → API calls succeed
- Run app with Charles Proxy MITM → API calls fail
- Check logs → pinning verification logged
- Inspect Info.plist → ATS settings correct
notes:
- Use public key pinning (more stable than full certificate)
- Include backup pin for certificate rotation
- TrustKit is a popular library for iOS certificate pinning
- Certificate expiry alerts prevent unexpected outages

74
tasks/ios-production/06-jailbreak-detection.md Normal file
View File

@@ -0,0 +1,74 @@
# 06. Jailbreak Detection & Runtime Security
meta:
id: ios-production-06
feature: ios-production
priority: P2
depends_on: []
tags: [security, hardening, production]
objective:
- Implement jailbreak detection and runtime security measures to protect the app on compromised devices
deliverables:
- Jailbreak detection implementation
- Runtime integrity checks
- Anti-tampering measures
- Secure enclave usage for sensitive operations
steps:
1. Implement jailbreak detection:
- Check for common jailbreak files (/Applications/Cydia.app, etc.)
- Check if app can write outside sandbox
- Check for suspicious dylibs
- Use multiple detection methods for robustness
- Add to APIClient or AppDelegate
2. Define jailbreak response:
- Option A: Block app usage with warning
- Option B: Degrade functionality (no biometric, no payments)
- Option C: Log and alert backend
- Recommended: Option B + alert backend
3. Implement runtime integrity checks:
- Verify code signature at runtime
- Detect debugger attachment
- Detect code injection attempts
- Verify method swizzling hasn't occurred
4. Use Secure Enclave:
- Store encryption keys in Secure Enclave
- Use biometrics via LocalAuthentication framework
- Protect keychain items with biometry constraint
5. Add anti-tampering:
- Obfuscate sensitive strings (API endpoints, keys)
- Verify bundle identifier hasn't changed
- Check for binary modification
6. Implement backend alerting:
- Send jailbreak detection event to backend
- Include device info (non-identifiable)
- Flag account for additional monitoring
tests:
- Unit: Test detection logic with mock jailbreak indicators
- Integration: Test on jailbroken device (if available)
- Security: Verify debugger detection works
acceptance_criteria:
- Jailbreak detection active with multiple methods
- App degrades gracefully on detected jailbreak
- Backend receives alert when jailbreak detected
- Secure Enclave used for key storage
- Debugger attachment detected and handled
- Runtime integrity checks active
- Sensitive strings obfuscated in binary
- No false positives on non-jailbroken devices
validation:
- Run on normal device → no jailbreak detected, full functionality
- Run on jailbroken device → degraded mode activated
- Attach debugger → app detects and responds
- Check backend logs → jailbreak events received
notes:
- Jailbreak detection is cat-and-mouse — don't rely on it exclusively
- Apple may reject apps that overly aggressively block jailbroken devices
- Degradation is safer than blocking (better user experience)
- Use Swift string obfuscation libraries for sensitive data

76
tasks/ios-production/07-keychain-data-protection.md Normal file
View File

@@ -0,0 +1,76 @@
# 07. Keychain & Data Protection Audit
meta:
id: ios-production-07
feature: ios-production
priority: P1
depends_on: []
tags: [security, data-protection, production]
objective:
- Audit and harden all keychain usage and data protection to ensure sensitive data is stored securely
deliverables:
- Keychain audit report
- Data protection class review
- Secure data deletion
- Encryption audit
steps:
1. Audit keychain usage:
- Review iOS/Kordant/Services/KeychainService.swift
- Verify all sensitive data stored in keychain (not UserDefaults)
- Check keychain accessibility levels:
- JWT tokens: kSecAttrAccessibleWhenUnlockedThisDeviceOnly
- Refresh tokens: kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
- Biometric flag: kSecAttrAccessibleWhenUnlockedThisDeviceOnly
- Verify keychain items migrated to correct accessibility
2. Audit data storage:
- Review CacheManager.swift — should not store sensitive data
- Review UserDefaults usage — only non-sensitive preferences
- Verify no sensitive data in app sandbox documents
- Check Core Data or SQLite encryption if used
3. Implement secure deletion:
- Overwrite sensitive data before deletion
- Clear clipboard after password copy (if applicable)
- Auto-lock app after backgrounding (optional)
4. Review data protection classes:
- File protection: NSFileProtectionComplete for sensitive files
- Keychain: appropriate accessibility per item type
- Backup: exclude sensitive items from iCloud backup
5. Add encryption for local data:
- Encrypt cached API responses containing PII
- Use AES-256 with key from Secure Enclave
- Implement secure key rotation
6. Test data protection:
- Device locked → keychain items inaccessible
- Device backup → sensitive items excluded
- App deletion → all sensitive data removed
tests:
- Unit: Test keychain store/retrieve/delete
- Security: Verify data inaccessible when device locked
- Integration: Test backup exclusion
acceptance_criteria:
- All sensitive data (tokens, passwords) stored in keychain
- Keychain accessibility set to ThisDeviceOnly where possible
- No sensitive data in UserDefaults or app documents
- Cached data encrypted at rest
- Sensitive items excluded from iCloud backup
- Secure deletion overwriting data before removal
- Data inaccessible when device locked (if applicable)
- All keychain operations have error handling
validation:
- Inspect keychain → JWT stored with correct accessibility
- Check UserDefaults → no sensitive data found
- Lock device → keychain items inaccessible
- Backup device → sensitive items not in backup
- Delete app → reinstall → no previous data accessible
notes:
- Keychain persists across app reinstalls — consider this in design
- kSecAttrAccessibleWhenUnlockedThisDeviceOnly is most secure
- Use Data Protection API for file-level encryption
- Consider using CryptoKit for data encryption

79
tasks/ios-production/08-oauth-social-login.md Normal file
View File

@@ -0,0 +1,79 @@
# 08. OAuth & Social Login Integration
meta:
id: ios-production-08
feature: ios-production
priority: P1
depends_on: []
tags: [auth, security, production]
objective:
- Implement OAuth and social login (Apple Sign-In, Google) to replace the stubbed auth client
deliverables:
- Apple Sign-In integration
- Google Sign-In integration
- Backend OAuth token exchange
- AuthService wired to real API client
steps:
1. Implement Apple Sign-In:
- Configure Sign in with Apple in Apple Developer portal
- Add com.apple.developer.applesignin.customauth entitlement
- Implement ASAuthorizationController in AuthService
- Handle authorization code and identity token
- Send Apple credentials to backend for verification
2. Implement Google Sign-In:
- Configure Google Sign-In in Firebase/Google Cloud Console
- Add URL scheme for Google callback
- Integrate GoogleSignIn SDK
- Handle ID token and send to backend
3. Update backend for OAuth:
- Add OAuth endpoints to tRPC user router
- Verify Apple ID token with Apple public keys
- Verify Google ID token with Google certs
- Create/link user accounts from OAuth providers
- Return session token after OAuth login
4. Replace StubAPIClient:
- Create real API client implementing AuthAPIClientProtocol
- Wire into AuthService initialization in KordantApp.swift
- Remove StubAPIClient from production builds
- Keep StubAPIClient for unit tests
5. Add token refresh:
- Implement refresh token rotation
- Silent token refresh on expiry
- Handle refresh failure (re-authenticate)
6. Add logout for OAuth:
- Revoke OAuth tokens where possible
- Clear all local auth state
- Notify backend of logout
tests:
- Unit: Test OAuth token parsing and validation
- Integration: Test Apple Sign-In flow end-to-end
- Integration: Test Google Sign-In flow end-to-end
- Security: Verify token validation rejects invalid tokens
acceptance_criteria:
- Apple Sign-In working on iOS 13+
- Google Sign-In working with Firebase
- OAuth tokens verified server-side
- User accounts created or linked correctly
- AuthService uses real API client in production
- Token refresh working silently
- Logout clears all auth state and revokes tokens
- Unit tests use mock client, production uses real client
- Error handling for cancelled sign-in attempts
validation:
- Tap Apple Sign-In → native sheet → authenticate → logged in
- Tap Google Sign-In → Google flow → authenticate → logged in
- Check backend → user created with correct provider
- Wait for token expiry → automatic refresh
- Logout → all tokens cleared, login screen shown
notes:
- Apple Sign-In is required if app uses other third-party sign-in
- Apple Sign-In must be primary button if multiple options
- Store Apple user ID for account linking
- Backend must verify Apple JWT with Apple's public key

74
tasks/ios-production/09-image-caching.md Normal file
View File

@@ -0,0 +1,74 @@
# 09. Image Caching & Lazy Loading
meta:
id: ios-production-09
feature: ios-production
priority: P2
depends_on: []
tags: [performance, caching, production]
objective:
- Implement efficient image caching and lazy loading to improve app performance and reduce network usage
deliverables:
- URLSession-based image caching
- Lazy loading for lists and grids
- Image optimization pipeline
- Memory and disk cache limits
steps:
1. Implement image caching:
- Use URLCache with memory (50MB) and disk (100MB) limits
- Or integrate Kingfisher or Nuke for advanced caching
- Configure cache expiration (7 days default)
- Add cache cleanup on low memory warnings
2. Add lazy loading:
- Use LazyVStack and LazyHGrid for lists
- Implement pagination for long lists (alerts, exposures)
- Add prefetching for adjacent items
- Show placeholder while loading
3. Optimize images:
- Request appropriate sizes from backend (thumbnail, full)
- Use WebP or HEIC format where supported
- Compress images before upload (VoicePrint, document scan)
- Implement progressive JPEG loading
4. Add loading states:
- Skeleton placeholders while images load
- Error state with retry button
- Fade-in animation when image loads
5. Implement memory management:
- Clear image cache on memory warning
- Limit concurrent image downloads (max 5)
- Cancel downloads for off-screen images
6. Add offline support:
- Cache images for offline viewing
- Show cached images when offline
- Queue uploads for when online
tests:
- Unit: Test cache hit/miss behavior
- Performance: Test scrolling with 1000 images
- Memory: Verify no memory leaks with image loading
acceptance_criteria:
- Images cached with 50MB memory / 100MB disk limits
- Lazy loading on all lists and grids
- Pagination for lists >50 items
- Image placeholders while loading
- Cache cleared on memory warning
- Offline image viewing working
- Progressive loading for large images
- No memory leaks in image loading pipeline
- Smooth 60fps scrolling on image-heavy screens
validation:
- Scroll through alert list → smooth, no stuttering
- Turn on airplane mode → cached images still visible
- Monitor memory → stable during image browsing
- Check cache directory → images stored with correct expiration
notes:
- Kingfisher is the most popular Swift image caching library
- Nuke is lighter and faster for advanced use cases
- Consider using SwiftUI AsyncImage for simple cases
- Always test on physical device, not just simulator

74
tasks/ios-production/10-memory-leak-audit.md Normal file
View File

@@ -0,0 +1,74 @@
# 10. Memory Management & Leak Audit
meta:
id: ios-production-10
feature: ios-production
priority: P2
depends_on: []
tags: [performance, memory, production]
objective:
- Audit and fix memory leaks and retain cycles to ensure stable app performance over long sessions
deliverables:
- Memory leak audit report
- Fixed retain cycles in ViewModels and Services
- Instruments leak check passing
- Memory usage optimization
steps:
1. Audit ViewModels for retain cycles:
- Review all ViewModels in iOS/Kordant/ViewModels/
- Check for strong references in closures
- Verify cancellables properly stored and cleaned up
- Check for delegate patterns causing cycles
2. Audit Services for leaks:
- Review APIClient, AuthService, CacheManager
- Check singleton patterns don't retain view controllers
- Verify notification observers removed on deinit
- Check timer/interval cleanup
3. Run Instruments leak check:
- Profile app with Leaks instrument
- Perform all critical user journeys
- Record and categorize all leaks
- Fix leaks in priority order (critical first)
4. Optimize memory usage:
- Reduce image cache size if needed
- Limit number of cached API responses
- Clear unused ViewModels from navigation stack
- Optimize large data structures
5. Add memory warnings handling:
- Clear caches on UIApplication.didReceiveMemoryWarningNotification
- Reduce quality of background operations
- Cancel non-essential network requests
6. Test long-running sessions:
- Leave app running for 24 hours
- Monitor memory growth
- Verify no crashes from memory pressure
tests:
- Instruments: Leaks instrument shows 0 leaks
- Performance: Memory stable after 1 hour of use
- Stress: No crashes after extended usage
acceptance_criteria:
- 0 memory leaks detected in Instruments
- No retain cycles in ViewModels or Services
- Memory usage stable over 1 hour session
- Memory warnings handled appropriately
- Caches cleared on low memory
- No strong reference cycles in closures
- Notification observers removed on deinit
- Long-running session (24h) without memory-related crashes
validation:
- Profile with Instruments → 0 leaks after full app navigation
- Monitor memory in Xcode → flat line during idle
- Trigger memory warning → caches cleared, app responsive
- Extended use test → no memory growth over time
notes:
- SwiftUI @StateObject and @ObservedObject can cause leaks if misused
- Use [weak self] in all async closures
- Combine subscribers must be stored in Set<AnyCancellable>
- Test on physical device — simulator behaves differently

76
tasks/ios-production/11-background-fetch.md Normal file
View File

@@ -0,0 +1,76 @@
# 11. Background Fetch & Sync Optimization
meta:
id: ios-production-11
feature: ios-production
priority: P2
depends_on: []
tags: [performance, background, production]
objective:
- Optimize background fetch and data sync to keep app data fresh without draining battery
deliverables:
- Background fetch configuration
- Efficient sync strategy
- Battery usage optimization
- Background task handling
steps:
1. Configure background fetch:
- Enable Background Fetch in Signing & Capabilities
- Set minimum fetch interval (15 minutes)
- Implement application(_:performFetchWithCompletionHandler)
- Or use BGAppRefreshTask for iOS 13+
2. Optimize sync strategy:
- Sync only changed data (delta sync)
- Use If-Modified-Since or ETag headers
- Prioritize critical data (alerts, exposures)
- Defer non-critical sync (reports, historical data)
3. Implement background tasks:
- Use BGProcessingTask for heavy operations
- Schedule periodic dark web scans
- Schedule spam database updates
- Handle task expiration gracefully
4. Optimize battery usage:
- Batch network requests
- Use cellular data efficiently
- Defer sync until WiFi available (optional)
- Respect low power mode
5. Handle push notification sync:
- Silent push notifications for urgent updates
- Content-available: 1 for background processing
- Wake app for critical alerts
6. Add sync status indicators:
- Last sync timestamp in settings
- Sync progress for large operations
- Offline mode indicator
tests:
- Unit: Test background task scheduling
- Integration: Test fetch completion within 30 seconds
- Battery: Verify minimal battery impact over 24 hours
acceptance_criteria:
- Background fetch enabled and configured
- Data syncs every 15 minutes minimum
- Delta sync reducing data transfer by >50%
- Background tasks complete within 30 seconds
- Battery impact <5% per day from background activity
- Silent push notifications trigger data refresh
- Low power mode respected (reduced sync frequency)
- Sync status visible to user in settings
- No background task terminations due to timeouts
validation:
- Simulate background fetch → data refreshed
- Check battery settings → Kordant background activity minimal
- Receive silent push → app updates in background
- Enable low power mode → sync frequency reduced
- Monitor network usage → delta sync working
notes:
- iOS limits background fetch frequency based on app usage patterns
- BGAppRefreshTask is modern replacement for performFetch
- Always call completion handler or setTaskCompleted
- Background processing tasks require specific entitlements

79
tasks/ios-production/12-launch-time.md Normal file
View File

@@ -0,0 +1,79 @@
# 12. App Launch Time Optimization
meta:
id: ios-production-12
feature: ios-production
priority: P2
depends_on: []
tags: [performance, launch, production]
objective:
- Optimize app launch time to under 2 seconds for cold starts and under 1 second for warm starts
deliverables:
- Launch time measurement and baseline
- Optimized app initialization
- Lazy loading of heavy components
- Reduced binary size
steps:
1. Measure current launch time:
- Use Xcode Metrics Organizer
- Use os_signpost for custom timing
- Measure cold start (first launch after reboot)
- Measure warm start (subsequent launches)
- Establish baseline metrics
2. Optimize app delegate:
- Minimize work in application(_:didFinishLaunchingWithOptions)
- Defer non-critical initialization
- Move heavy setup to background threads
- Avoid blocking main thread
3. Lazy load heavy components:
- Defer VoicePrint model loading until needed
- Defer document scanner initialization
- Lazy load WebView components
- Load dashboard data after UI appears
4. Optimize storyboards/XIBs:
- Remove unused storyboards
- Minimize view controller initialization
- Use code-based UI where faster
5. Reduce binary size:
- Strip debug symbols from release builds
- Remove unused resources and assets
- Compress images in asset catalog
- Enable dead code stripping
6. Optimize framework loading:
- Link frameworks statically where possible
- Reduce dynamic framework count
- Prelink common frameworks
7. Add launch screen optimization:
- Simple, static launch screen
- Match first screen of app
- No animations or complex layouts
tests:
- Performance: Measure launch time on iPhone 12
- Stress: Launch app 100 times, average time <2s
- Memory: No memory spikes during launch
acceptance_criteria:
- Cold launch time <2 seconds on iPhone 12
- Warm launch time <1 second on iPhone 12
- Launch screen visible for <500ms
- No blocking operations on main thread during launch
- Binary size <100MB (App Store limit is much higher)
- Heavy components loaded lazily after launch
- Launch time measured and tracked in CI
- No crashes during launch under memory pressure
validation:
- Xcode Metrics → cold start <2s, warm <1s
- Instruments Time Profiler → no long blocking calls on main thread
- Physical device test → feels instant
- App Store Connect → binary size acceptable
notes:
- Launch time is critical for App Store review and user retention
- iOS may terminate apps with launch times >20 seconds
- Use pre-warmed launches for more accurate measurement
- Test on oldest supported device (iPhone SE 2nd gen or similar)

79
tasks/ios-production/13-callkit-spamshield.md Normal file
View File

@@ -0,0 +1,79 @@
# 13. CallKit Integration for SpamShield
meta:
id: ios-production-13
feature: ios-production
priority: P1
depends_on: []
tags: [native-features, spamshield, production]
objective:
- Integrate SpamShield with CallKit to identify and block spam calls at the system level
deliverables:
- CallKit extension for call identification
- Spam database sync
- Real-time caller lookup
- User-managed block list
steps:
1. Create CallKit extension:
- Add Call Directory Extension target in Xcode
- Implement CXCallDirectoryProvider
- Handle reloadExtensionRequests
- Add to app group for shared data
2. Implement caller identification:
- Lookup incoming numbers against spam database
- Display caller ID label ("Spam: Telemarketer")
- Use local cached database for speed
- Fall back to API lookup for unknown numbers
3. Implement call blocking:
- Block known spam numbers
- Block user-defined patterns
- Sync block list from app settings
- Handle block list updates
4. Sync spam database:
- Download updated spam numbers periodically
- Store in shared app group container
- Update Call Directory on sync
- Respect user privacy (hashed numbers where possible)
5. Add user controls:
- Settings toggle for call identification
- Settings toggle for call blocking
- Manage blocked numbers list
- Report false positives
6. Handle permissions:
- Request Call Directory extension enablement
- Guide user to Settings → Phone → Call Blocking
- Check extension status on app launch
tests:
- Unit: Test number lookup against spam database
- Integration: Test Call Directory update
- Device: Test with actual spam call (simulated)
acceptance_criteria:
- CallKit extension installed and enabled
- Incoming spam calls identified with label
- Known spam numbers automatically blocked
- Spam database synced daily
- User can enable/disable identification and blocking
- Block list manageable from app settings
- Extension updates without app restart
- False positive reporting mechanism
- Privacy: number lookups local where possible
- App guides users to enable extension in Settings
validation:
- Enable extension in Settings → calls identified
- Receive call from known spam number → blocked/identified
- Update spam database → Call Directory refreshed
- Disable in app → extension stops working
- Report false positive → number removed from block list
notes:
- Call Directory extensions have strict memory limits (17MB)
- Apple reviews CallKit extensions carefully
- Extension runs separately from main app
- Use app groups for sharing data between app and extension
- Users must manually enable extension in Settings

77
tasks/ios-production/14-siri-shortcuts.md Normal file
View File

@@ -0,0 +1,77 @@
# 14. Siri Shortcuts & Intents
meta:
id: ios-production-14
feature: ios-production
priority: P2
depends_on: []
tags: [native-features, siri, production]
objective:
- Implement Siri Shortcuts and custom intents for common Kordant actions
deliverables:
- Custom intents for Kordant actions
- Siri Shortcuts support
- Intent handling in app
- Suggested shortcuts
steps:
1. Define custom intents:
- CheckThreatScoreIntent: "What's my threat score?"
- RunSecurityScanIntent: "Run a security scan"
- CheckAlertsIntent: "Do I have any security alerts?"
- AddWatchlistItemIntent: "Add email to dark web watchlist"
- CheckSpamNumberIntent: "Is this number spam?"
2. Create intent definition file:
- Add SiriKit intent definition to project
- Define parameters for each intent
- Add response templates
- Localize for supported languages
3. Implement intent handling:
- Create IntentHandler extension
- Handle each custom intent
- Call TRPCBridge to fetch data
- Return formatted response to Siri
4. Add shortcuts support:
- Donate shortcuts after user performs actions
- Add NSUserActivity for eligible actions
- Support Add to Siri button in app
- Handle intent parameters from shortcuts app
5. Implement suggested shortcuts:
- Suggest "Check my threat score" on first launch
- Suggest "Run security scan" after onboarding
- Suggest "Check alerts" when new alert received
6. Add UI for shortcuts:
- Settings section for Siri Shortcuts
- List of available shortcuts
- Instructions for adding to Siri
tests:
- Unit: Test intent parameter parsing
- Integration: Test Siri response formatting
- Device: Test voice commands with Siri
acceptance_criteria:
- 5+ custom intents defined and working
- Siri can respond to "What's my threat score?"
- Siri can respond to "Run a security scan"
- Shortcuts app can create workflows with Kordant actions
- Intents donated after relevant user actions
- Suggested shortcuts appear in Siri suggestions
- Intent responses formatted naturally
- All intents work without opening app (where possible)
- Shortcuts settings UI in app
- Intents localized for English (expand to other languages later)
validation:
- Ask Siri "What's my threat score?" → responds with current score
- Say "Run a security scan" → scan initiated, confirmation spoken
- Create shortcut in Shortcuts app → Kordant actions available
- Check Siri suggestions → Kordant shortcuts suggested
notes:
- SiriKit intents require app to be in foreground for some actions
- Custom intents work best for read-only or simple actions
- Donate intents frequently so Siri learns user patterns
- Test on physical device — simulator Siri support is limited

77
tasks/ios-production/15-home-screen-widgets.md Normal file
View File

@@ -0,0 +1,77 @@
# 15. Home Screen Widgets
meta:
id: ios-production-15
feature: ios-production
priority: P2
depends_on: []
tags: [native-features, widgets, production]
objective:
- Implement home screen widgets to display threat score and recent alerts at a glance
deliverables:
- Widget extension target
- Small, medium, and large widget sizes
- Widget configuration intent
- Timelines with refresh strategy
steps:
1. Create widget extension:
- Add Widget Extension target in Xcode
- Configure app group for data sharing
- Set up widget bundle with multiple widgets
2. Design widgets:
- Small widget: Threat score gauge only
- Medium widget: Threat score + 2 recent alerts
- Large widget: Threat score + alert list + quick actions
- Use SwiftUI for widget UI
- Match app design system colors
3. Implement widget timeline:
- Create TimelineProvider
- Fetch data from shared UserDefaults or App Group
- Update every 15 minutes (widget limit)
- Handle placeholder, snapshot, and timeline entries
4. Add widget configuration:
- Intent for selecting widget type (if multiple variants)
- Intent for filtering alerts by severity
- Configuration UI in widget gallery
5. Share data with widget:
- Write threat score and alerts to shared container
- Update shared data when app refreshes
- Use WidgetCenter to reload timelines after app update
6. Add deep linking:
- Tap widget → open app to relevant screen
- Tap alert in widget → open alert detail
- Tap threat score → open dashboard
tests:
- Unit: Test timeline provider data formatting
- UI: Test widget rendering in all sizes
- Integration: Test data sharing between app and widget
acceptance_criteria:
- Widget extension building and running
- Small widget showing threat score
- Medium widget showing threat score + recent alerts
- Large widget showing full alert summary
- Widgets update every 15 minutes
- Data shared correctly between app and widget
- Deep links from widget to correct app screens
- Widgets match app design system
- Placeholder and snapshot states look good
- Widgets work in dark mode
- No crashes when widget data is missing
validation:
- Add widget to home screen → displays current threat score
- Receive new alert → widget updates within 15 minutes
- Tap widget → app opens to dashboard
- Tap specific alert in widget → alert detail opens
- Check widget in dark mode → colors correct
notes:
- Widgets cannot make network requests directly
- App must write data to shared container for widgets to read
- Widget memory limits are strict (especially for small widgets)
- Use WidgetCenter.reloadTimelines(ofKind:) to force updates

75
tasks/ios-production/16-app-clips.md Normal file
View File

@@ -0,0 +1,75 @@
# 16. App Clips
meta:
id: ios-production-16
feature: ios-production
priority: P3
depends_on: []
tags: [native-features, app-clips, production]
objective:
- Create an App Clip to allow users to preview Kordant functionality without downloading the full app
deliverables:
- App Clip target
- Lightweight onboarding flow
- Core feature preview (threat score check)
- App Clip invocation via QR code, NFC, or Safari
steps:
1. Create App Clip target:
- Add App Clip target in Xcode (max 15MB)
- Share code with main app where possible
- Configure associated domains for invocation
2. Design App Clip experience:
- Threat score check (no auth required, demo mode)
- Basic spam number check
- Signup prompt to unlock full features
- Clear CTA to download full app
3. Implement lightweight UI:
- Reuse SwiftUI components from main app
- Remove features requiring auth
- Simplify navigation (single screen or wizard)
- Fast load time (<2 seconds)
4. Configure invocation:
- Associated domain: appclips.kordant.com
- QR code generation for marketing
- Safari App Banner on website
- NFC tag support (optional)
5. Add App Clip card:
- Design card image (300x300 or 600x600)
- Configure in App Store Connect
- Include title, subtitle, action button
6. Handle App Clip to full app transition:
- Preserve state when user installs full app
- Transfer any entered data
- Deep link to relevant screen after install
tests:
- Size: Verify App Clip <15MB
- Performance: Launch time <2 seconds
- Invocation: Test QR code and Safari banner
acceptance_criteria:
- App Clip target building and <15MB
- App Clip shows threat score demo without auth
- App Clip includes spam number check
- Clear CTA to download full app
- Invocation via QR code, Safari banner, and associated domains
- App Clip card configured in App Store Connect
- Smooth transition to full app with state preserved
- App Clip loads in <2 seconds
- Works on iOS 14+
validation:
- Scan QR code → App Clip launches
- Check threat score → demo data displayed
- Tap "Get Full App" → App Store opens
- Install full app → previous state preserved
- Check size → binary <15MB
notes:
- App Clips are optional but great for user acquisition
- 15MB limit is strict — may need to strip features
- Focus on one compelling use case (threat score)
- App Clips cannot use Apple Sign-In or in-app purchases

88
tasks/ios-production/17-ui-test-expansion.md Normal file
View File

@@ -0,0 +1,88 @@
# 17. UI Test Suite Expansion
meta:
id: ios-production-17
feature: ios-production
priority: P1
depends_on: []
tags: [testing, ui-tests, quality]
objective:
- Expand UI test coverage to include all critical user journeys across the iOS app
deliverables:
- UI tests for auth flows
- UI tests for dashboard and services
- UI tests for settings
- Accessibility testing integration
steps:
1. Audit existing UI tests:
- Review iOS/KordantUITests/KordantUITests.swift
- Identify gaps in coverage
- Plan test scenarios
2. Create auth flow tests:
- Launch app → onboarding screen visible
- Sign up with valid credentials → dashboard
- Login with valid credentials → dashboard
- Login with invalid credentials → error shown
- Forgot password flow → confirmation shown
- Biometric prompt → enable/skip options
3. Create dashboard tests:
- Dashboard loads with widgets
- Pull to refresh updates data
- Tap alert → detail view opens
- Threat score updates correctly
4. Create service tests:
- Navigate to DarkWatch → watchlist loads
- Add watchlist item → appears in list
- Navigate to VoicePrint → enrollment screen
- Navigate to SpamShield → rules list
- Navigate to HomeTitle → property list
- Navigate to RemoveBrokers → listings shown
5. Create settings tests:
- Open settings → all options visible
- Toggle notifications → preference updated
- Update profile → changes saved
- Logout → returns to login screen
6. Add accessibility tests:
- Verify VoiceOver labels on all elements
- Test dynamic type support
- Test color contrast
7. Configure test data:
- Mock API responses for consistent tests
- Reset app state between tests
- Use test account credentials
8. Add CI integration:
- Run UI tests on pull requests
- Test on multiple simulators (iPhone SE, 14, 15 Pro Max)
- Upload test results and screenshots
tests:
- UI: All critical paths covered
- Accessibility: VoiceOver tests passing
- CI: Tests run automatically on PR
acceptance_criteria:
- 20+ UI test cases covering critical flows
- Auth flow fully tested (signup, login, forgot password)
- All 5 services have UI tests
- Settings and profile tested
- Tests run on iPhone SE, 14, and 15 Pro Max simulators
- Tests complete in <5 minutes
- Screenshots captured on failure
- Accessibility labels verified
- Mock API used for consistent test data
- CI runs UI tests on every PR
validation:
- Run UI tests → all pass
- Introduce UI bug → test fails
- Check test report → screenshots for all tests
- CI pipeline → UI tests green
notes:
- Use XCTest framework for UI tests
- Mock network layer for consistent, fast tests
- Tests should be independent (no shared state)
- Consider using Accessibility IDs for reliable element finding

76
tasks/ios-production/18-performance-testing.md Normal file
View File

@@ -0,0 +1,76 @@
# 18. Performance Testing (XCTestMetric)
meta:
id: ios-production-18
feature: ios-production
priority: P2
depends_on: []
tags: [testing, performance, quality]
objective:
- Implement performance testing using XCTestMetric to ensure consistent 60fps and fast response times
deliverables:
- Performance tests for critical flows
- XCTMetric measurements
- Baseline performance documentation
- Performance regression detection in CI
steps:
1. Set up performance tests:
- Create XCTestCase with measure blocks
- Use XCTClockMetric for time measurements
- Use XCTCPUMetric for CPU usage
- Use XCTMemoryMetric for memory usage
2. Test critical flows:
- App launch time (cold and warm)
- Dashboard scroll performance (60fps)
- Alert list scroll performance
- Service screen transitions
- API response time (with mocked data)
- Image loading performance
3. Establish baselines:
- Run tests 10 times to establish baseline
- Document expected ranges for each metric
- Set performance budgets
4. Add regression detection:
- Configure XCTest to fail on 10% regression
- Add to CI pipeline
- Alert on performance degradation
5. Test on physical devices:
- iPhone SE (2nd gen) — minimum supported device
- iPhone 12 — mid-range target
- iPhone 15 Pro — high-end target
6. Document performance:
- Create docs/PERFORMANCE.md
- List all measured metrics and baselines
- Document optimization techniques used
tests:
- Performance: All metrics within budget
- Regression: 10% regression triggers failure
- Device: Tests pass on physical devices
acceptance_criteria:
- 10+ performance test cases
- App launch time measured and baselined
- Scroll performance tested (target 60fps)
- API response time measured
- Memory usage tracked during key flows
- Baselines established for iPhone SE, 12, and 15 Pro
- 10% regression threshold configured
- Performance tests run in CI
- Performance budget documented
- No performance regressions in release builds
validation:
- Run performance tests → all within budget
- Introduce slow animation → test fails
- Check CI → performance tests passing
- Review docs → baselines documented
notes:
- Performance tests should run on physical devices, not simulators
- Simulators don't reflect real-world performance accurately
- Use Xcode's Metrics tab to track performance over time
- Consider using Firebase Performance Monitoring for real-world data

80
tasks/ios-production/19-accessibility-audit.md Normal file
View File

@@ -0,0 +1,80 @@
# 19. Accessibility Audit (VoiceOver)
meta:
id: ios-production-19
feature: ios-production
priority: P2
depends_on: []
tags: [testing, accessibility, compliance]
objective:
- Ensure the iOS app is fully accessible with VoiceOver and meets WCAG 2.1 AA mobile guidelines
deliverables:
- VoiceOver audit report
- Accessibility labels on all elements
- Dynamic Type support
- Color contrast verification
steps:
1. Audit all screens with VoiceOver:
- Turn on VoiceOver (Settings → Accessibility)
- Navigate every screen using swipe gestures
- Verify all interactive elements have labels
- Verify logical reading order
- Test with eyes closed
2. Add missing accessibility labels:
- Add .accessibilityLabel to all buttons
- Add .accessibilityHint where helpful
- Add .accessibilityValue for dynamic content
- Group related elements with .accessibilityElement(children:)
3. Test Dynamic Type:
- Enable Larger Text in Settings
- Test all screens at largest text size
- Verify no truncation or overlap
- Use ScrollView where content may overflow
4. Verify color contrast:
- Test all text/background color combinations
- Ensure 4.5:1 ratio for normal text
- Ensure 3:1 ratio for large text and UI components
- Test in both light and dark mode
5. Test Switch Control:
- Enable Switch Control
- Verify all actions reachable
- Test with external switch device if available
6. Test Reduce Motion:
- Enable Reduce Motion
- Verify app still functional without animations
- Respect prefersReducedMotion
7. Add accessibility tests:
- XCTest checks for accessibility labels
- Verify no unlabeled elements
- Test with accessibility inspector
tests:
- Manual: Full VoiceOver navigation of all screens
- Automated: XCTest accessibility label checks
- Visual: Color contrast verification
acceptance_criteria:
- All interactive elements have accessibility labels
- VoiceOver reads logical description for every element
- Dynamic Type supported at all sizes (AX5)
- Color contrast ≥4.5:1 for all text
- Reduce Motion respected
- Switch Control navigable
- No accessibility warnings in Xcode
- Accessibility audit report completed
- Screenshots at largest text size showing no layout issues
validation:
- Turn on VoiceOver → navigate entire app without visual
- Enable largest text size → all screens readable
- Check contrast → all combinations pass
- Xcode accessibility inspector → 0 warnings
notes:
- SwiftUI has good accessibility by default but custom views need attention
- Use .accessibilityElement(children: .combine) for complex views
- Test on physical device — simulator VoiceOver is limited
- Consider hiring accessibility consultant for thorough audit

85
tasks/ios-production/20-device-farm-testing.md Normal file
View File

@@ -0,0 +1,85 @@
# 20. Device Farm Testing
meta:
id: ios-production-20
feature: ios-production
priority: P2
depends_on: []
tags: [testing, device-farm, quality]
objective:
- Test the iOS app on a diverse range of physical devices using a device farm service
deliverables:
- Device farm test configuration
- Tests running on multiple iOS versions and devices
- Test results and reports
- Bug fixes from device-specific issues
steps:
1. Choose device farm service:
- AWS Device Farm
- Firebase Test Lab (limited iOS support)
- BrowserStack App Live
- Sauce Labs
- Or manual testing on physical devices
2. Configure test suite:
- Upload IPA build
- Configure XCTest UI test bundle
- Select device matrix:
- iPhone SE (3rd gen) — iOS 17
- iPhone 12 — iOS 16
- iPhone 14 Pro — iOS 17
- iPhone 15 Pro Max — iOS 18
- iPad Pro 12.9" — iOS 18
- iPad mini — iOS 17
3. Define test scenarios:
- Install and launch
- Complete onboarding
- Login and dashboard navigation
- Run security scan
- View alerts and details
- Settings navigation
- Background/foreground transitions
4. Run tests and collect results:
- Execute automated test suite
- Collect screenshots and videos
- Gather performance metrics
- Document device-specific issues
5. Fix device-specific bugs:
- Notch/safe area issues on different models
- Dynamic Island interactions
- iPad multitasking support
- Performance on older devices
6. Add device farm to CI:
- Trigger tests on release builds
- Block release on critical failures
- Archive results for compliance
tests:
- Device: All selected devices pass core tests
- Regression: No new failures compared to previous run
- Performance: App responsive on all devices
acceptance_criteria:
- Tests run on 6+ different iOS devices
- Tests cover iOS 16, 17, and 18
- All critical flows pass on all devices
- Screenshots and videos from all test runs
- Device-specific issues identified and fixed
- Device farm integrated into release CI
- Test results archived for 1 year
- No crashes on any tested device
- Performance acceptable on oldest supported device
validation:
- Run device farm tests → all devices pass
- Review screenshots → UI looks correct on all sizes
- Check videos → no stuttering or crashes
- Compare with previous run → no regressions
notes:
- AWS Device Farm is most comprehensive for iOS
- Physical device testing is ideal but expensive
- Focus on edge cases: small screens, old iOS versions
- Test cellular vs WiFi behavior if possible

78
tasks/ios-production/21-real-api-client.md Normal file
View File

@@ -0,0 +1,78 @@
# 21. Real API Client Wiring (Replace StubAPIClient)
meta:
id: ios-production-21
feature: ios-production
priority: P1
depends_on: []
tags: [backend, api, production]
objective:
- Replace the StubAPIClient with a real API client that connects to the production backend
deliverables:
- Real API client implementing AuthAPIClientProtocol
- Backend OAuth endpoints for iOS
- AuthService wired to real client in production
- Environment-based client selection
steps:
1. Create real API client:
- Create iOS/Kordant/Services/RealAPIClient.swift
- Implement AuthAPIClientProtocol methods:
- login(email:password:) → POST /api/trpc/user.login
- signup(name:email:password:) → POST /api/trpc/user.signup
- resetPassword(email:) → POST /api/trpc/user.forgotPassword
- Use existing APIClient for network layer
- Handle tRPC response format (batch input, result wrapper)
2. Add OAuth support:
- Apple Sign-In token exchange endpoint
- Google Sign-In token exchange endpoint
- Social account linking
3. Configure environment-based client:
- Debug builds: use RealAPIClient pointing to staging
- Release builds: use RealAPIClient pointing to production
- Unit tests: continue using StubAPIClient or MockAPIClient
4. Update AuthService initialization:
- Modify KordantApp.swift to inject RealAPIClient
- Keep dependency injection pattern
- Add build configuration for base URL
5. Add error handling:
- Map API errors to user-friendly messages
- Handle network errors gracefully
- Retry on transient failures
6. Test integration:
- Test login against staging backend
- Test signup flow
- Test token persistence
- Test session restoration
tests:
- Unit: Test RealAPIClient with mock URLSession
- Integration: Test against staging backend
- E2E: Complete auth flow on physical device
acceptance_criteria:
- RealAPIClient implements all AuthAPIClientProtocol methods
- Login works against production backend
- Signup creates user in production database
- Password reset sends email
- Apple Sign-In and Google Sign-In tokens exchanged correctly
- Auth token persisted in keychain
- Session restored on app relaunch
- Debug builds use staging, release builds use production
- Unit tests still use mock clients
- All auth errors mapped to user-friendly messages
validation:
- Build debug → login to staging → success
- Build release → login to production → success
- Run unit tests → all pass with mocks
- Check keychain → token stored after login
- Kill and relaunch app → still authenticated
notes:
- This is critical — currently StubAPIClient throws notImplemented for everything
- Must be done before any backend integration tasks
- Coordinate with backend team on OAuth endpoint contracts
- Use APIConfig.swift for base URL configuration

77
tasks/ios-production/22-token-refresh.md Normal file
View File

@@ -0,0 +1,77 @@
# 22. Token Refresh & Session Management
meta:
id: ios-production-22
feature: ios-production
priority: P1
depends_on: [ios-production-21]
tags: [backend, auth, production]
objective:
- Implement automatic token refresh and robust session management to prevent unexpected logouts
deliverables:
- Token refresh interceptor in APIClient
- Silent re-authentication flow
- Session expiry handling
- Concurrent request queue during refresh
steps:
1. Implement token refresh:
- Add refresh token endpoint to backend if not exists
- Modify APIClient to detect 401 responses
- On 401, attempt token refresh with refresh token
- Retry original request with new token
2. Handle concurrent requests:
- Queue requests while refresh in progress
- Don't duplicate refresh requests
- Use Combine or async/await for coordination
3. Add silent re-authentication:
- If refresh fails, try biometric re-auth
- If biometric fails, prompt for password
- If all fail, logout user
4. Implement session expiry:
- Parse JWT expiry claim
- Proactively refresh before expiry (5 min buffer)
- Schedule background refresh
5. Add session monitoring:
- Track session age
- Alert user when session nearing expiry
- Auto-refresh on app foreground
6. Handle edge cases:
- Refresh token also expired → full re-auth
- Network unavailable during refresh → queue and retry
- Multiple tabs/apps refreshing simultaneously
7. Update AuthService:
- Expose session state
- Handle refresh failures gracefully
- Notify UI of re-authentication needs
tests:
- Unit: Test token refresh logic
- Integration: Test concurrent request handling
- E2E: Test session expiry and refresh
acceptance_criteria:
- Token refresh automatic and transparent to user
- Concurrent requests queued during refresh, not failed
- Proactive refresh 5 minutes before expiry
- Biometric re-auth offered if refresh fails
- Session restored on app relaunch (if tokens valid)
- Graceful logout if all auth methods fail
- No duplicate refresh requests
- Background refresh on app foreground
- Unit tests covering all refresh scenarios
validation:
- Wait for token expiry → app refreshes automatically
- Trigger 401 → refresh attempted, request retried
- Revoke refresh token → app prompts re-auth
- Background app → foreground → token refreshed if needed
- Check logs → no duplicate refresh requests
notes:
- Current APIClient has retry logic but no token refresh
- Backend must support refresh token endpoint
- Consider using OAuth 2.0 refresh token flow
- Store refresh token with higher security than access token

83
tasks/ios-production/23-offline-sync.md Normal file
View File

@@ -0,0 +1,83 @@
# 23. Offline Mode & Sync Conflict Resolution
meta:
id: ios-production-23
feature: ios-production
priority: P2
depends_on: [ios-production-21]
tags: [backend, offline, production]
objective:
- Implement robust offline mode with sync conflict resolution for all user actions
deliverables:
- Offline queue improvements
- Sync conflict resolution strategy
- Offline UI indicators
- Data consistency guarantees
steps:
1. Audit existing offline support:
- Review iOS/Kordant/Services/OfflineQueue.swift
- Review CacheManager.swift
- Identify gaps in offline handling
2. Improve offline queue:
- Support all mutation types (add, update, delete)
- Add request deduplication
- Add request ordering (dependencies)
- Increase max retry count with exponential backoff
3. Implement conflict resolution:
- Define strategy per data type:
- Server wins for most data (alerts, exposures)
- Last write wins for user preferences
- Merge for watchlist items
- Add conflict detection (version numbers or timestamps)
- Show conflict UI for manual resolution (if needed)
4. Add offline UI:
- Offline indicator in status bar
- Disabled actions when offline
- "Sync pending" badges on modified items
- Pull-to-refresh with offline state
5. Implement data consistency:
- Optimistic updates (update UI immediately, sync in background)
- Rollback on sync failure
- Verify server state after sync
- Handle partial sync failures
6. Add background sync:
- Process queue on app foreground
- Process queue on network restoration
- Schedule periodic sync attempts
7. Test offline scenarios:
- Create watchlist item offline → syncs when online
- Delete exposure offline → syncs when online
- Modify settings offline → syncs when online
- Conflicting edits on multiple devices
tests:
- Unit: Test queue ordering and deduplication
- Integration: Test sync after offline period
- E2E: Test conflicting edits resolution
acceptance_criteria:
- All mutations queued when offline
- Queue processed automatically when online
- Optimistic updates show immediately
- Failed operations roll back UI changes
- Conflict resolution strategy defined per data type
- Offline indicator visible in UI
- Sync pending badges on modified items
- No data loss during sync failures
- Background sync on app foreground and network restore
- Unit tests for all offline scenarios
validation:
- Enable airplane mode → create watchlist item → badge shows
- Disable airplane mode → item syncs → badge clears
- Edit same item on web and iOS → conflict resolved correctly
- Kill app during sync → queue persists, resumes on relaunch
notes:
- Current OfflineQueue exists but may need enhancement
- CRDTs (Conflict-free Replicated Data Types) are ideal for sync
- Consider using Realm or Core Data with sync for complex cases
- Simple server-wins strategy is acceptable for MVP

82
tasks/ios-production/24-push-deep-links.md Normal file
View File

@@ -0,0 +1,82 @@
# 24. Push Notification Deep Linking
meta:
id: ios-production-24
feature: ios-production
priority: P2
depends_on: [ios-production-21]
tags: [native-features, push-notifications, production]
objective:
- Ensure push notifications correctly deep link to relevant screens with proper handling of app state
deliverables:
- Deep link routing for all notification types
- Cold start handling
- Background notification processing
- Notification analytics
steps:
1. Audit existing push handling:
- Review iOS/Kordant/Services/PushNotificationService.swift
- Review KordantApp.swift handleNotificationNavigation
- Identify gaps in deep linking
2. Implement deep link routes:
- Alert notification → AlertDetailView
- Exposure notification → DarkWatchView
- Scan complete notification → DashboardView
- Family invite → Settings/Family
- Subscription renewal → Settings/Billing
- Marketing → Landing or specific feature
3. Handle app states:
- App closed (cold start): launch → process notification → navigate
- App background: wake → process → navigate
- App foreground: show in-app toast → navigate on tap
4. Add notification categories:
- Actionable notifications (Resolve Alert, Dismiss)
- Rich notifications with images
- Grouped notifications by type
5. Implement analytics:
- Track notification delivery
- Track notification open rates
- Track conversion from notification to action
- A/B test notification copy
6. Add notification preferences:
- Allow user to customize notification types
- Respect system notification settings
- Update backend preferences
7. Test all scenarios:
- Cold start from each notification type
- Background tap on notification
- Foreground notification handling
- Action button taps
tests:
- Unit: Test deep link route mapping
- Integration: Test notification handling in all states
- Device: Send test notifications via Firebase Console
acceptance_criteria:
- All notification types deep link to correct screens
- Cold start from notification opens correct screen
- Background notification tap navigates correctly
- Foreground notifications show in-app toast
- Actionable notification buttons work
- Notification preferences respected
- Analytics tracking delivery and open rates
- Rich notifications with images render correctly
- No crashes from malformed notification payloads
- Unit tests for all deep link routes
validation:
- Send alert notification → tap → AlertDetailView opens
- Send exposure notification → app closed → DarkWatchView opens
- Receive notification in foreground → toast shown
- Tap action button → correct action performed
- Check analytics → open rate tracked
notes:
- Current KordantApp.swift has basic routing but needs expansion
- Use UNUserNotificationCenter for modern notification handling
- Test on physical device — simulator push notifications are limited
- Coordinate with backend on notification payload format

82
tasks/ios-production/25-privacy-manifest.md Normal file
View File

@@ -0,0 +1,82 @@
# 25. Privacy Manifest & Nutrition Labels
meta:
id: ios-production-25
feature: ios-production
priority: P1
depends_on: []
tags: [compliance, app-store, privacy, production]
objective:
- Create and configure the required privacy manifest and App Privacy nutrition labels for App Store submission
deliverables:
- Privacy manifest file (PrivacyInfo.xcprivacy)
- App Privacy nutrition labels in App Store Connect
- Third-party SDK privacy manifests
- Data usage disclosure documentation
steps:
1. Create privacy manifest:
- Add PrivacyInfo.xcprivacy to project
- Declare all collected data types:
- Contact Info (name, email)
- User Content (voice recordings for VoicePrint)
- Identifiers (user ID, device ID)
- Usage Data (analytics)
- Diagnostics (crash logs)
- Declare required reason APIs:
- File timestamp APIs (if used)
- Disk space APIs (if used)
- System boot time APIs (if used)
- Active keyboard APIs (if used)
- User defaults APIs (used for preferences)
2. Configure App Privacy nutrition labels:
- Log into App Store Connect
- Navigate to App Privacy section
- Select all data types collected by app
- Mark each as linked to user identity or not
- Mark each as used for tracking or not
- Specify purposes (analytics, app functionality, etc.)
3. Audit third-party SDKs:
- Check Firebase SDK privacy manifest
- Check any analytics SDK privacy manifest
- Ensure all SDKs have updated manifests for iOS 17+
- Update SDKs if manifests missing
4. Document data usage:
- Create docs/IOS_PRIVACY.md
- List all data collection and purposes
- Explain user controls and opt-out options
- Document data retention periods
5. Test manifest validation:
- Build app in Xcode
- Check for privacy manifest warnings
- Validate with App Store Connect upload
tests:
- Build: No privacy manifest warnings in Xcode
- Upload: App Store Connect accepts privacy labels
- Review: Privacy labels match actual data collection
acceptance_criteria:
- PrivacyInfo.xcprivacy file in project
- All collected data types declared
- Required reason APIs documented
- App Privacy nutrition labels complete in App Store Connect
- All third-party SDKs have privacy manifests
- Privacy labels accurate and honest
- No Xcode warnings about missing privacy manifests
- Documentation of data usage available
- User-facing privacy policy linked
validation:
- Build app → no privacy manifest warnings
- Upload to App Store Connect → privacy section complete
- Review data types → all actual collection declared
- Check SDK versions → all include privacy manifests
notes:
- Apple requires privacy manifests for all apps starting 2024
- Nutrition labels must be accurate — false claims can lead to rejection
- Third-party SDKs without manifests may cause build warnings
- Update manifests when adding new data collection features

78
tasks/ios-production/26-app-tracking.md Normal file
View File

@@ -0,0 +1,78 @@
# 26. App Tracking Transparency (ATT)
meta:
id: ios-production-26
feature: ios-production
priority: P1
depends_on: []
tags: [compliance, privacy, app-store, production]
objective:
- Implement App Tracking Transparency to comply with iOS privacy requirements for analytics and advertising
deliverables:
- ATT permission request
- Analytics gated behind ATT consent
- Tracking description in Info.plist
- Fallback for denied tracking
steps:
1. Add ATT framework:
- Import AppTrackingTransparency
- Add NSUserTrackingUsageDescription to Info.plist
- Description: "Your data will be used to improve app experience and measure marketing effectiveness"
2. Implement permission request:
- Request tracking authorization on first launch (after onboarding)
- Show explanation before system dialog
- Handle all authorization states:
- .notDetermined → request permission
- .restricted → disable tracking
- .denied → disable tracking
- .authorized → enable tracking
3. Gate analytics behind ATT:
- Check tracking status before initializing analytics
- If denied: use anonymous analytics only (no IDFA)
- If authorized: full analytics with IDFA
- Respect user's choice across app sessions
4. Update third-party SDKs:
- Configure Firebase Analytics to respect ATT
- Configure PostHog/Plausible to respect ATT
- Disable ad network tracking if denied
5. Handle state changes:
- Monitor for settings changes
- Update tracking status if user changes in Settings
- Re-initialize analytics accordingly
6. Add UI for tracking preferences:
- Settings toggle for analytics (if user previously denied)
- Explanation of what data is collected
- Link to system Settings for ATT changes
tests:
- Unit: Test ATT status handling
- Integration: Test analytics initialization gating
- Device: Test permission flow on physical device
acceptance_criteria:
- ATT permission requested after onboarding
- System dialog shows with accurate description
- Analytics initialize only after authorized or denied
- If denied: no IDFA collection, minimal anonymous analytics
- If authorized: full analytics collection
- Third-party SDKs configured to respect ATT
- Settings UI allows users to change preference
- App complies with Apple's ATT guidelines
- No tracking before permission granted
- Unit tests covering all authorization states
validation:
- Fresh install → onboarding → ATT dialog appears
- Deny tracking → analytics uses anonymous mode
- Authorize tracking → full analytics active
- Change in Settings → app respects new choice
- Check Info.plist → NSUserTrackingUsageDescription present
notes:
- ATT is required if app collects IDFA or shares data for tracking
- If only using first-party analytics, ATT may not be required
- Be honest in description — Apple reviews these carefully
- Consider making analytics fully anonymous to avoid ATT entirely

81
tasks/ios-production/27-data-usage-descriptions.md Normal file
View File

@@ -0,0 +1,81 @@
# 27. Data Usage Descriptions
meta:
id: ios-production-27
feature: ios-production
priority: P1
depends_on: []
tags: [compliance, privacy, app-store, production]
objective:
- Add all required permission usage descriptions to Info.plist for camera, microphone, location, and other sensitive APIs
deliverables:
- Info.plist permission descriptions
- Localized descriptions for supported languages
- In-app permission rationale dialogs
- Permission handling in all features
steps:
1. Audit all permissions used:
- Camera (document scanning, VoicePrint enrollment)
- Microphone (VoicePrint enrollment)
- Photo Library (document upload)
- Push Notifications (alerts)
- Face ID / Touch ID (biometric auth)
- Location (not currently used — verify)
- Contacts (not currently used — verify)
2. Add Info.plist descriptions:
- NSCameraUsageDescription: "Camera is used to scan documents for identity verification"
- NSMicrophoneUsageDescription: "Microphone is used to enroll your voice for VoicePrint protection"
- NSPhotoLibraryUsageDescription: "Photo library access is used to upload identity documents"
- NSFaceIDUsageDescription: "Face ID is used to securely access your account"
- NSUserTrackingUsageDescription: (from task 26)
- UIBackgroundModes: fetch, remote-notification
3. Localize descriptions:
- Add translations for Spanish, French (if supporting)
- Create InfoPlist.strings for each language
- Keep descriptions concise but informative
4. Add in-app rationale dialogs:
- Show custom dialog before system permission request
- Explain why permission is needed
- Include example of feature benefit
- Add "Don't Allow" and "Allow" buttons
5. Handle permission denials:
- Show guidance to Settings if permission denied
- Degrade functionality gracefully
- Don't crash if permission unavailable
6. Test all permission flows:
- First request → rationale → system dialog
- Deny → feature degraded → Settings guidance
- Allow → feature fully functional
- Revoke in Settings → app handles gracefully
tests:
- Unit: Test permission state handling
- Integration: Test rationale dialog flow
- Device: Test all permissions on physical device
acceptance_criteria:
- All required Info.plist descriptions present
- Descriptions accurate and user-friendly
- Localized for all supported languages
- In-app rationale dialogs before system requests
- Graceful degradation when permissions denied
- Settings guidance for denied permissions
- No crashes from missing permissions
- All permission flows tested on physical device
- App Review will approve descriptions
validation:
- Check Info.plist → all NS*UsageDescription keys present
- Test camera permission → rationale dialog → system dialog
- Deny permission → app shows Settings guidance
- Check localization → descriptions in correct language
- App Review → no rejections for permission descriptions
notes:
- Apple rejects apps with generic permission descriptions
- Descriptions must explain specific feature usage
- Always show rationale before system dialog
- Test on physical device — simulator doesn't show permission dialogs realistically

88
tasks/ios-production/28-review-compliance.md Normal file
View File

@@ -0,0 +1,88 @@
# 28. App Review Guidelines Compliance
meta:
id: ios-production-28
feature: ios-production
priority: P1
depends_on: []
tags: [compliance, app-store, production]
objective:
- Ensure the iOS app fully complies with Apple App Review Guidelines to pass review on first submission
deliverables:
- App Review Guidelines compliance checklist
- All guideline requirements met
- Reviewer demo account and notes
- Rejection risk mitigation
steps:
1. Review App Store Review Guidelines:
- Safety: no objectionable content, no physical harm
- Performance: complete app, no crashes, accurate metadata
- Business: no scams, proper IAP if digital goods
- Design: minimum functionality, proper use of system features
- Legal: privacy policy, data collection disclosure
2. Check specific requirements:
- App is complete and functional (no placeholders, no "coming soon")
- All buttons and features work
- No broken links
- No test data visible to users
- No beta/test labels
3. Verify business model:
- If subscriptions: use StoreKit or web billing (document choice)
- If digital goods: must use in-app purchase
- No external purchase links (unless reader apps exception)
- No misleading pricing
4. Check content guidelines:
- No spam, no excessive ads
- No misleading claims about security
- Accurate description of AI features
- No harassment or hate speech content
5. Verify technical requirements:
- App launches within reasonable time
- No excessive battery drain
- Proper use of background modes
- No private API usage
- No beta SDKs or frameworks
6. Prepare for review:
- Create demo account with realistic data
- Write detailed review notes
- Include video of app usage (optional but helpful)
- Document any complex features for reviewer
7. Handle common rejection reasons:
- Guideline 2.1 (App Completeness) → all features working
- Guideline 4.2 (Minimum Functionality) → not just a wrapper
- Guideline 5.1.1 (Data Collection) → proper disclosures
- Guideline 5.6 (Developer Code of Conduct) → no manipulation
tests:
- Review: Internal review using Apple guidelines checklist
- Functionality: All features tested end-to-end
- Content: Review all user-facing text for accuracy
acceptance_criteria:
- All App Store Review Guidelines requirements met
- App is complete with no placeholder content
- All features functional and tested
- Demo account created with realistic data
- Review notes prepared explaining app functionality
- Privacy policy and terms of service linked
- No test data, labels, or beta markings visible
- Business model compliant with IAP guidelines
- No private APIs or undocumented features
- App passes internal review checklist with 0 issues
validation:
- Internal review checklist → all items checked
- Test every button and flow → all work correctly
- Review all text → accurate, no typos, no placeholders
- Check for test data → none visible
- Verify no private APIs → scan with otool or similar
notes:
- Apple reviewers test on physical devices with various iOS versions
- First submission often takes 1-2 days for review
- Have a plan for addressing rejections quickly
- Consider using App Review acceleration for critical launches
- Document any complex authentication flows for reviewers

89
tasks/ios-production/README.md Normal file
View File

@@ -0,0 +1,89 @@
# iOS Production Readiness
Objective: Prepare the SwiftUI iOS application for App Store submission with hardened security, optimized performance, comprehensive testing, and full native feature integration.
Status legend: [ ] todo, [~] in-progress, [x] done
## Tasks
### App Store Preparation
- [ ] 01 — App Store Screenshots & Metadata → `01-app-store-screenshots.md`
- [ ] 02 — App Preview Video → `02-app-preview-video.md`
- [ ] 03 — App Store Connect Configuration → `03-app-store-connect.md`
- [ ] 04 — TestFlight Beta Distribution → `04-testflight-beta.md`
### Security Hardening
- [ ] 05 — Certificate Pinning & TLS Validation → `05-certificate-pinning.md`
- [ ] 06 — Jailbreak Detection & Runtime Security → `06-jailbreak-detection.md`
- [ ] 07 — Keychain & Data Protection Audit → `07-keychain-data-protection.md`
- [ ] 08 — OAuth & Social Login Integration → `08-oauth-social-login.md`
### Performance Optimization
- [ ] 09 — Image Caching & Lazy Loading → `09-image-caching.md`
- [ ] 10 — Memory Management & Leak Audit → `10-memory-leak-audit.md`
- [ ] 11 — Background Fetch & Sync Optimization → `11-background-fetch.md`
- [ ] 12 — App Launch Time Optimization → `12-launch-time.md`
### Native Features
- [ ] 13 — CallKit Integration for SpamShield → `13-callkit-spamshield.md`
- [ ] 14 — Siri Shortcuts & Intents → `14-siri-shortcuts.md`
- [ ] 15 — Home Screen Widgets → `15-home-screen-widgets.md`
- [ ] 16 — App Clips → `16-app-clips.md`
### Testing & QA
- [ ] 17 — UI Test Suite Expansion → `17-ui-test-expansion.md`
- [ ] 18 — Performance Testing (XCTestMetric) → `18-performance-testing.md`
- [ ] 19 — Accessibility Audit (VoiceOver) → `19-accessibility-audit.md`
- [ ] 20 — Device Farm Testing → `20-device-farm-testing.md`
### Backend Integration
- [ ] 21 — Real API Client Wiring (Replace StubAPIClient) → `21-real-api-client.md`
- [ ] 22 — Token Refresh & Session Management → `22-token-refresh.md`
- [ ] 23 — Offline Mode & Sync Conflict Resolution → `23-offline-sync.md`
- [ ] 24 — Push Notification Deep Linking → `24-push-deep-links.md`
### App Store Compliance
- [ ] 25 — Privacy Manifest & Nutrition Labels → `25-privacy-manifest.md`
- [ ] 26 — App Tracking Transparency (ATT) → `26-app-tracking.md`
- [ ] 27 — Data Usage Descriptions → `27-data-usage-descriptions.md`
- [ ] 28 — App Review Guidelines Compliance → `28-review-compliance.md`
## Dependencies
- 01, 02, 03, 04 can be done in parallel (App Store prep)
- 05, 06, 07, 08 can be done in parallel (security)
- 09, 10, 11, 12 can be done in parallel (performance)
- 13, 14, 15, 16 can be done in parallel (native features)
- 17, 18, 19, 20 can be done in parallel (testing)
- 21 must be done before 22, 23, 24 (backend integration foundation)
- 22, 23, 24 depend on 21
- 25, 26, 27, 28 can be done in parallel (compliance)
- All groups can proceed independently
## Exit Criteria
- App Store listing complete with screenshots for all supported devices
- App preview video uploaded (15-30 seconds)
- TestFlight build distributed to internal testers
- Certificate pinning active on all API endpoints
- Jailbreak detection implemented with graceful degradation
- Keychain items secured with appropriate accessibility levels
- OAuth and social login flows working (Google, Apple Sign-In)
- Image caching with 50MB disk limit and LRU eviction
- Memory leaks resolved (0 leaks in Instruments leak check)
- Background fetch refreshing data every 15 minutes
- Cold launch time under 2 seconds on iPhone 12
- CallKit extension filtering spam calls in real-time
- Siri shortcuts for common actions (check alerts, run scan)
- Home screen widgets showing threat score and recent alerts
- App Clip allowing preview without full download
- UI tests covering all critical user flows
- Performance tests confirming 60fps scrolling on all lists
- VoiceOver labels on all interactive elements
- Device farm tests passing on iPhone SE, 12, 14 Pro, 15 Pro Max
- StubAPIClient fully replaced with real APIClient
- Token refresh automatic with silent re-authentication
- Offline queue syncing correctly with conflict resolution
- Push notifications deep linking to correct screens
- Privacy manifest accurately declaring all data collection
- ATT prompt shown before any analytics tracking
- All permission descriptions localized and accurate
- App passes App Review with no rejections on first submission