We need to be comparing the encrypted size to the max payload limit. Otherwise we may still exceed the limit after encryption, which will cause the notif to be ignored

We should generate an APNsDelivery for every delivered notif

Why do we need different APNsDelivery object for each notification? The APNsDelivery object looks like this:

type APNsDelivery = {
  source: $PropertyType<NotificationInfo, 'source'>,
  deviceType: 'ios' | 'macos',
  iosID: string,
  deviceTokens: $ReadOnlyArray<string>,
  codeVersion: number,
  errors?: $ReadOnlyArray<ResponseFailure>,
};

Regardless of whether notifications are encrypted or not, one APNsDelivery gives us complete information on which deviceToken received notifications and which didn't. Why having many APNsDelivery objects with only one deviceToken and at most one error is better for encrypted notifications than one APNsDelivery with many deviceTokens and possibly may errors?

Let me be more specific: by only taking the first notification here, and ignoring the rest, you are failing to record in the notifications DB the full list of notification IDs that have been delivered.

This has a number of negative effects, most notably that are you breaking rescinding, which relies on the iosID being present. (I didn't realize this in the initial feedback, but I certainly suspected that something sketchy was happening here, since you are throwing away all but the first notification.)

Perhaps the easiest solution would be to go back to the old behavior, where there is one delivery for each iosID. That was my initial suggestion. However, I am open to other solutions that do not break notif rescinding.

Separately, some feedback: this sort of thing frankly should not have to be discussed in code review, and certainly should not take two "Request Changes" for you to look into. When you make a change like this (making it so we only look at the first iosID), you should think like a reviewer, and treat this as a "red flag" that warrants significant investigation. It is a sketchy decision and is likely to lead to sketchy consequences, so you should be very sure that it is a correct direction before putting up the diff (and certainly before ignoring review feedback).