Mobile apps API push notifications not received on iOS devices

BPM Appian
, , , , , , , ,
1

We’re experiencing issues with push notifications on iOS devices in our approval workflow application. The API calls seem to execute successfully (200 response), but notifications aren’t delivered to devices. Android works fine.

Our APNs payload structure:


{
  "aps": {"alert": "Approval Required"},
  "workflowId": "WF-2024-089"
}

Device tokens are being validated against the registered format, and the mobile plugin configuration appears correct in the admin console. We’re on Appian 22.4 with the latest mobile app version. Has anyone encountered similar issues with APNs integration?

2

Found it! The issue was a combination of problems. Thanks everyone for the suggestions.

3

Check your APNs authentication method. If you switched from certificate-based to token-based authentication (or vice versa), the device tokens need to be re-registered. Also, the topic field in your APNs configuration must match your app’s bundle identifier exactly. I spent two days debugging this exact issue last month. The API returns 200 even when the topic is wrong because it accepts the request, but APNs silently drops it.

4

Another thing to verify: check the Appian mobile plugin logs for any APNs-specific errors. Sometimes the 200 response is from Appian’s API accepting the request, but the actual APNs delivery fails downstream. Look for entries containing ‘APNs delivery failed’ or ‘Invalid device token’. Also ensure your firewall allows outbound connections to api.push.apple.com on port 443.

5

I had this exact problem. The issue was in how we were formatting the device token in the API call. Device tokens from iOS need to be sent as a hex string without spaces or angle brackets. If you’re copying tokens from Xcode logs, they come with ‘<’ and ‘>’ characters that need to be stripped. Also check if your tokens are being stored correctly in the Appian database - sometimes encoding issues during storage cause mismatches.

6

Good point about the certificate. We’re using production certificates, and the device tokens are from production builds. I verified the payload size is only 156 bytes. Still no luck. Could this be related to how the mobile plugin handles token registration?

7

Great to hear you resolved it! For anyone else facing this issue, here’s a comprehensive solution addressing all three critical areas:

APNs Payload Format: The payload structure was actually correct, but you need to ensure the content-available flag is set for background notifications:


{
  "aps": {
    "alert": "Approval Required",
    "content-available": 1
  },
  "workflowId": "WF-2024-089"
}

Device Token Validation: Device tokens must be validated and stored as clean hex strings. Strip all formatting characters:


String cleanToken = deviceToken
  .replaceAll("[<> ]", "")
  .toLowerCase();

Verify token length is exactly 64 characters for modern iOS devices. Tokens shorter than this indicate registration issues.

Mobile Plugin Configuration: In the Appian Admin Console, verify these settings:

  1. APNs authentication method matches your certificate type (token-based vs certificate-based)
  2. Topic field = your app’s bundle identifier (e.g., com.company.appianmobile)
  3. Environment setting matches your certificate (production vs sandbox)
  4. Certificate expiration date is valid

Additional debugging steps:

  • Enable verbose logging in mobile plugin settings
  • Test with Apple’s Push Notification Console to isolate Appian vs APNs issues
  • Verify device timezone and notification permission settings
  • Check that Do Not Disturb isn’t enabled on test devices

Common gotcha: If you regenerated APNs certificates recently, all device tokens need to be re-registered. The old tokens become invalid immediately. Force users to log out and back in to trigger fresh token registration.

For workflow approvals specifically, consider implementing a fallback mechanism (email notifications) for critical approvals in case push delivery fails. APNs has no guaranteed delivery SLA.

8

I’ve seen this before. First thing to check: are you using the production APNs certificate or sandbox? The device token format differs between environments. Also verify that your payload doesn’t exceed the 4KB limit. The structure looks correct, but APNs is very strict about certificate-token environment matching.