APNS与FCM令牌服务端管理方案及相关技术疑问

First off, let me say your current approach is already a solid, privacy-conscious take on a notoriously tricky problem—push token management across uninstalls and updates is a pain point Apple and Google have intentionally left vague to protect user privacy, so your focus on building trust is spot-on. Let’s break down your questions one by one:

1. Is step 4 (using collapse IDs) reliable? #

Collapse IDs are reliable for cutting down duplicate notifications on the same active device, but they have a key limitation: they only work within the context of a single push token and topic. If a user uninstalls/reinstalls your app and gets a new token, Apple/Google have no way of linking the old and new tokens to the same device—so collapse IDs can’t cross those token boundaries to prevent duplicates across different token records for the same user/device.

That said, within the constraints of not being able to uniquely identify devices across reinstalls, this is still the best tool you have to avoid spamming users with identical notifications on the same active token. Just make sure your collapse IDs are consistent for the same notification intent (e.g., order-updated-1234 for an order update, not a random string) to maximize their effectiveness.

2. Are there better implementation approaches? #

Your core logic is strong, but here are a few tweaks to make it more robust:

• Fix your iOS keychain assumption: Storing a custom device UUID in the iOS keychain does not require user permissions. As long as your app is signed with the same developer account, the keychain entry will persist across uninstalls and updates. This gives you a far more stable device identifier than the vendor ID, which cuts down on duplicate APUD ID records from reinstalls.
• Android stability hacks: For Android, while ANDROID_ID resets on reinstall, you can use a combination of the app’s signature hash and a stored UUID in internal storage (no permissions needed) to create a semi-stable identifier. If the user enables cloud backup for your app, this UUID will persist across reinstalls too—no extra permissions required.
• Force periodic syncs: Have your app call the upsert API every time it launches, not just when the token changes. This ensures your server always has the latest token and device identifier for active users, reducing the number of stale records.

3. Can cron jobs be used to proactively manage expired tokens? #

Absolutely, but you need to use them strategically to avoid wasting resources:

• Batch validation with caution: Both APNS and FCM offer ways to validate tokens in bulk, but these APIs have rate limits and aren’t real-time. For APNS, the legacy feedback service is slow—better to rely on push failure responses first, then use a cron job to validate tokens that haven’t been used in 30+ days. For FCM, use the batchCheck API to test stale tokens periodically.
• Clean up soft-deleted records: Run a cron job every 3-6 months to permanently delete soft-deleted tokens that are past a retention window (e.g., 6 months). This keeps your database lean without losing debugging data.
• Flag inactive tokens: Mark tokens that haven’t been updated via upsert in 90+ days as "inactive" and exclude them from push campaigns unless the user reactivates the app.

4. Will this approach lead to token bloat with few expirations? #

It can, especially if users frequently uninstall/reinstall your app. But you can mitigate this:

• Deduplicate per user/device: If you implement stable device identifiers (iOS keychain UUID, Android internal storage UUID), you’ll drastically reduce duplicate APUD ID records from the same device.
• Prune stale records: In your upsert API, when a new token is added for a user/device, you can soft-delete older tokens for the same APUD ID (since the new token is the active one). For users with multiple devices, keep all active tokens, but prune any that have failed push attempts or haven’t been synced in months.
• Monitor token health: Track metrics like push success rates per token—if a token has a 100% failure rate over a week, soft-delete it immediately instead of waiting for a cron job.

5. Are there standard/industry-proven implementations? #

Your approach is actually aligned with most industry best practices, but here’s the "standard" recipe major apps use:

1. Client-side token sync: On every app launch, register for push notifications, fetch the latest token, and send it to the server with a stable device identifier (iOS keychain UUID, Android internal storage UUID) and user ID.
2. Server-side upsert: Use an upsert endpoint to create/update token records, linking them to user IDs and device identifiers.
3. Push with collapse IDs: When sending notifications to a user, target all their active tokens and use a consistent collapse ID for the same notification type.
4. Failure-driven cleanup: Immediately soft-delete tokens when APNS returns a 410 Gone (token invalid/unregistered) or FCM returns InvalidRegistration.
5. Periodic maintenance: Use cron jobs to validate stale tokens, clean up old soft-deleted records, and flag inactive tokens.

The biggest difference between your current plan and the standard approach is leveraging stable device identifiers (via keychain/internal storage) to reduce duplicate token records—this is a game-changer for keeping your database clean and avoiding unnecessary push attempts.

内容的提问来源于stack exchange，提问作者Jordan