Procurement mobile app push notifications not triggered for approval requests on iOS devices

Our procurement managers aren’t receiving push notifications on iOS devices when PO approval requests are submitted through the workflow engine. The approval requests show up fine when users manually open the app, but the push notifications that should alert them aren’t being delivered.

This is causing significant delays in our PO approval process since managers don’t know there are pending requests until they happen to check the app. We’re on MASC 2023.1 with the iOS SDK integrated.

I’ve verified that device notifications are enabled in iOS settings and the app has permission. The issue seems to be with APNs certificate setup or device token registration not working correctly. The notification payload might also not be formatted properly for iOS requirements. Has anyone successfully configured push notifications for procurement approval workflows?

Good point. I checked and we are using the production certificate, and it’s valid until next year. The app is distributed through the App Store, so that should be correct. Could this be a device token registration issue where tokens aren’t being sent to the Manhattan server properly?

Let me walk through the complete solution for procurement workflow push notifications:

APNs Certificate Setup: Your production certificate is valid, which is good. However, verify it’s properly installed on your Manhattan server with the correct private key. Test the certificate using a tool like Knuff or manual curl command:


curl -v -d '{"aps":{"alert":"test"}}' \
  --cert apns-cert.pem:password \
  --http2 https://api.push.apple.com/3/device/[token]

If this fails, your certificate configuration has issues even if it appears valid.

Device Token Registration: This is likely your main problem. The iOS app needs this implementation:


func application(_ application: UIApplication,
  didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
  let token = deviceToken.map { String(format: "%02.2hhx", $0) }.joined()
  ManhattanSDK.registerDeviceToken(token, userId: currentUser.id)
}

The Manhattan SDK must send this token to the procurement module’s notification service. Check server logs for POST requests to /api/notifications/register or similar endpoint. If tokens aren’t arriving, the SDK registration call is failing.

Payload Format Validation: Manhattan’s procurement workflow should generate payloads like:


{
  "aps": {
    "alert": {
      "title": "PO Approval Required",
      "body": "PO-12345 awaits your approval"
    },
    "badge": 1,
    "sound": "default"
  },
  "poId": "12345",
  "workflowType": "approval"
}

Common mistakes: Missing “aps” wrapper, incorrect alert structure, or exceeding 4KB limit with custom data.

Debugging Steps:

  1. Enable APNs logging on Manhattan server to see delivery attempts and responses
  2. Use Xcode Console to monitor device-side registration and notification receipt
  3. Verify the workflow engine is triggering notification events - check procurement module configuration
  4. Test with a known-good device token using manual API call

Configuration Check: In Manhattan’s procurement module, verify notification triggers are enabled for approval workflow states. The workflow might be executing but not configured to send notifications.

Token Lifecycle Management: Implement token refresh logic. iOS regenerates tokens after app reinstall or OS updates. Your app should re-register tokens on each launch, and the server should update its database accordingly.

Most likely, your device tokens aren’t reaching the Manhattan server due to SDK integration issues. Fix the registration flow first, then validate payload format.

First thing to check - are you using the production APNs certificate or the sandbox one? If you’re testing with TestFlight or development builds but using production certificate (or vice versa), notifications will fail silently. Also verify the certificate hasn’t expired.

Carlos makes a great point about payload validation. Also check if your server is handling APNs feedback service responses. When tokens become invalid, APNs tells you, but if you’re not listening to that feedback, you’ll keep trying to send to dead tokens and wonder why nothing works.

I’d also look at the notification payload format. APNs is very strict about payload structure. If your alert dictionary isn’t formatted correctly or you’re exceeding the 4KB payload limit, notifications will fail without error on the client side. The server might think it sent successfully but APNs rejected it.