“missing package product”

Hello Apple Developer Community, I’m seeking advice regarding a prolonged App Store review that is currently impacting our business. Our app was submitted more than two months ago, and the review process has not progressed since then. During this time, we sent two support emails to Apple Developer Support requesting assistance. We did receive one response stating that the app was “in review”, but unfortunately the message did not provide any useful details, timeline, or further guidance, and there has been no additional update since then. This delay is now blocking our business launch, as the mobile application is a critical component of our product release. Without App Store approval, we cannot proceed with launching our service to customers. Summary of the situation: Submission date: More than 2 months ago Current status: Pending Support requests sent: 2 emails to Apple Developer Support Responses received: 1 reply saying the app was “in review,” but no meaningful information Impact: Blocking our p

In the attached screenshot, we have an NSSplitViewController with three split view items. The first two are viewController split view items, while the third is an inspector split view item. The NSWindow is configured for full screen content so that the inspector split view items is full height itself. However, when we enable full height content view, AppKit is automatically adding a tracking separator into the toolbar when we don't want one. (Neither of the two split views are sidebars.) This tracking separator is out of place, cannot be dragged itself, and is drawn under the center aligned segmented control. We've tried a multitude of permutations to configure the NSWindow, NSToolbar and NSSplitViewItem but to no avail. Surely we're just missing the magic combo but a lot of the properties appear to be no-ops in macOS 26. How do we use an NSSplitViewController, in a full screen content window, such that we get a full height inspector but we don't get tracking separators for the main split view divide

Hello, I’m implementing VoIP calling in an iOS application using PushKit (VoIP pushes) together with CallKit. The standard call flow works correctly: Happy scenario User A initiates a call. Server sends a VoIP push to User B. User B’s device receives the push and reports the incoming call using CallKit. User B answers the call. However, I would like clarification about non-happy scenarios and when it is acceptable to use VoIP pushes to update or stop a CallKit ringing state. Apple documentation warns that VoIP pushes must be used only when they result in a call-related action, so I want to ensure the following cases are compliant. Scenario A — Caller Cancels Before Answer User A calls User B. Server sends a VoIP push to User B. User B’s device starts ringing via CallKit. Before User B answers, User A cancels the call. Question: Is it acceptable to send another VoIP push to User B indicating that the call has been cancelled so the device can: stop the CallKit ringing UI end the call optionally mark it as missed

I’m looking for clarification on how rate limiting works for the App Attest service, especially in production environments. According to the entitlement documentation (https://developer.apple.com/documentation/BundleResources/Entitlements/com.apple.developer.devicecheck.appattest-environment), iOS ignores the environment setting once an app is distributed through TestFlight, the App Store, or Enterprise distribution, and always contacts the production App Attest endpoint. With that context, I have two questions: Rate‑Limiting Thresholds How exactly does rate limiting work for App Attest? Is there a defined threshold beyond which attestation requests begin to fail? The Preparing to Use the App Attest Service documentation (https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service) recommends ramping up no more than 10 million users per day per app, but I’m trying to understand what practical limits or failure conditions developers should expect. Per‑AppID B

I currently have a schema in production (cloudKit and local files) containing non-optional transformable values, e.g. @Attribute(.transformable(by: TestTransformer.self)) var number: TestTransformable = TestTransformable.init(value: 100) Unfortunately, this is preventing any migration from succeeding (documented at length in FB22151570). Briefly summarized, any migration from a Schema containing non-optional transformable values fails between willMigrate and didMigrate with the error Can't find model for source store. This occurs for all migrations, including lightweight with a migration plan, lightweight without a plan, and custom migrations. Worst of all, this also prevents migration to optional transformable values, or the elimination of the transformable value entirely, leaving us completely stuck. (note: optional transformable values only work when they have a default value set to nil, otherwise even these have issues migrating) We already have features being blocked by this issue, and would lik

Apple has introduced the Wireless Insights Service Predictions capability in iOS 26. After prior alignment with Apple engineers, we are working to integrate this capability into the Douyin App, and intend to provide a TestFlight build for Apple engineers to validate and debug the integration. We have encountered a blocking issue with entitlement configuration: We use our Apple Developer Enterprise Program account to build and submit TestFlight builds. When we manually create and configure provisioning profiles via the Apple Developer Portal, the required entitlement key com.apple.developer.wireless-insights.service-predictions is not available for selection or inclusion in the profile's Entitlements. This completely blocks us from enabling, using, and validating the Wireless Insights Service Predictions capability. For comparison, when we use our Apple Developer Program individual account, the entitlement com.apple.developer.wireless-insights.service-predictions is fully available. It is automatically include

I am trying to notarize my first macOS app for direct distribution outside the Mac App Store using Developer ID Application signing. Team ID: 32S6XVAQPY Environment: macOS app distributed via Developer ID notarytool with a saved keychain profile archive exported locally, app zipped with ditto What I already verified locally: The archived app is signed with: Developer ID Application: (32S6XVAQPY) codesign --verify --deep --strict passes spctl shows: source=Unnotarized Developer ID syspolicy_check distribution only reports the expected missing notary ticket Hardened runtime is enabled The app bundle and nested Sparkle executables were re-signed and now have valid Developer ID signatures with secure timestamps Important note: I previously had a real signing issue in nested Sparkle binaries, and Apple rejected that submission quickly as Invalid. I fixed those signatures, and now new submissions no longer fail quickly but remain stuck In Progress. Submission IDs currently stuck: bea6c4b3-b107-4c81-8042-6c