missing package product

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 tha

When I used to do Migrations, I always used ETL and then push to a dev system to review/test before going production. The migration support is SwiftData is fine for a little tweak. I might as well just just use new schema and context and write the custom code than use the SwiftData migration support.

Hello everyone, I am writing to seek help with a critical App Review issue for a new application. My app has been in the In Review status for 29 consecutive days (since October 1st) without any change or feedback. This is on an experienced developer account with 5 other apps already live on the App Store. Here is the timeline of the current submission: Sep 30: Submitted new binary. Oct 1: Status changed to In Review. Oct 9: After inquiring about the long delay, Developer Support kindly granted an expedited review (Case ID 102702095699). Oct 30 (Today): The app is still In Review. It has now been 21 days since the expedited review was applied, and 29 days total. The core problem: My primary concern is that based on our server metrics, there has not been a single login attempt or health check from the App Review team since October 1st. This strongly suggests the app is technically stuck in the queue and has not even been opened or tested by a reviewer. We have been in constant contact with Developer Support, wh

This is probably a silly question, but I couldn't find the answer to it in the forums or in the documentation, though I may be missing something. I currently have an app with a deployment target of iOS 16 and a watchOS app (not independent) with a deployment target of watchOS 7. I understand what happens when I change the deployment target on the iOS app (e.g., users with iOS/iPadOS versions less than 16 will just never see the updates in the App Store). But what happens if I change the deployment target of the watchOS dependent app to something like watchOS 8? Will users who have iOS 16 and watchOS 7 (iOS meets deployment target/watchOS does not) get the app update, and it'll just uninstall the watchOS app automatically? Will they just not see the update? Does the old version of the Watch app somehow stay on their watch while the iOS app gets updated?

We have the following step before running any tests on CI machine: xcrun simctl shutdown all && xcrun simctl erase all It was working perfectly before Xcode 26.1. On Beta 3 it was doing it for 15 min every time. When updated to RC1, the tests with cached build are fast (clean goes up to 10 sec), but the package tests clean is still going up to 15 min every time. We did xcrun simctl runtime dyld_shared_cache update --all as advised but it's helping only temporarily. Is this going to be fixed in the official release?