Due to hysterical raisins, our Apple Developer Account (2A...FW) has five FairPlay Streaming resources under https://developer.apple.com/account/resources/certificates/list Three of these are certificates (fairplay.cer) and two of them are provisioning packages (fps-bundle.zip). The three certificates all use 1024-bit RSA keys and have creation dates of: Oct 24 23:22:09 2016 (expired Oct 25 23:22:09 2018) 3J Mar 29 19:39:15 2018 (expired Mar 29 19:39:15 2020) 2N Feb 11 00:32:06 2026 (expires Feb 1 00:22:57 2027) LD (I've included the first two characters of the Apple resource ID to help keep these straight.) The key for the first two (same key for both) is lost to the mists of time. The third is a cert I created from a new key, so I have the key for it. (The developer portal will not let us create any more 1024-bit FairPlay certs.) The two FPS bundles each contain an fps_certificate.bin which itself contains a 1024-bit cert and a 2048-bit cert. Looking at this file in each bundle, the bundles include the same 1024-bit cert that I created on Feb 11, but two different 2048-bit certs with creation dates of: Feb 11 00:32:06 2026 (expires Feb 11 00:32:05 2028) YP Feb 11 00:56:22 2026 (expires Feb 11 00:56:21 2028) 9N Both 2048-bit certs use the same key (which I have). Finally, we use a third-party as our streaming provider. With them we shared the first FPS bundle (YP). So, this is a big mess. And I'm unable to delete any of these entries from our developer account. Questions: Does the expiration date on these certs matter or is it ignored for streaming purposes? How do we delete FP certs/bundles we no longer need/use/are expired? With respect to using third-party vendors for streaming (with whom we've shared an FPS bundle): Is it okay to re-use the same FPS bundle if we change vendors? Should we ask Apple to delete an FPS bundle once we stop using a vendor?

Our developer account was granted the com.apple.developer.mail-client by Apple ages ago, which we use for one of our apps. At the time, this entitlement was granted through a special "entitlements" drop-down on the profile creation page. In fact, the entitlement is still available to us in this manner: Unfortunately, applying the entitlement directly to the profile no longer works through the App Store Connect API. Which is a bummer because we periodically use the API to update our development and ad hoc profiles with new UDIDs. I was eventually able to get Apple to migrate the entitlement to a capability that we can instead apply to the app IDs in our account. Great! However, for some reason the "Default Mail App" capability (on the "Edit your App ID Configuration" screen) shows does NOT apply to Ad hoc profiles: Note that "Ad hoc" is missing. This means we still need to update the Ad hoc profile for the app in question manually through the Apple developer portal. This has to be a bug. It makes no sense that this specific capability doesn't apply to Ad hoc profiles. Other capabilities don't have this issue. e.g.: Another strange thing is that on the profile page for the ad hoc profile under "Enabled Capabilities" it shows "Default Mail App" (see screenshot above) but the capability/entitlement is missing from the downloaded profile unless I add it via the drop down menu on the profile page. How do I get Apple to fix this? Multiple support tickets submitted via our developer account have gone unanswered. (It took months just to get the entitlement partially migrated in the first place.)