“missing package product”

Hello - In reviewing your account, it appears that the required Paid Apps Agreement has not been signed and is not yet in the Active state. Because of this, your In-App Purchase products are not available for testing in Sandbox or for purchase in Production. Please direct the Account Holder to accept the Paid Apps Agreement, complete both the Banking and Tax information, and ensure the status of this agreement is updated to ACTIVE. We also recommend completing a successful Sandbox purchase in your app. Please let us know if you have any additional questions or need further assistance. Thank you.

Hi Macho Man Randy Savage, Your diagnosis is essentially right, and I dug deeper than I expected after reproducing it. The situation is worse than just one wrong selector — NSBrowser's Cocoa Bindings layer doesn't compose with the item-based delegate API at all, regardless of cell class. I built a small test project (item-based NSBrowser, an NSTextFieldCell subclass installed as cellPrototype, and selectionIndexPaths bound to a property). With the binding in place, the app crashes during draw with: *** -[NSTextFieldCell setLeaf:]: unrecognized selector sent to instance ... The actual selector is setLeaf:, not setIsLeaf: (worth knowing if you grep for it). The stack tells the rest of the story: 0 CoreFoundation __exceptionPreprocess 1 libobjc.A.dylib objc_exception_throw ... 5 AppKit -[NSBrowserBinder browser:willDisplayCell:atRow:column:] + 156 6 AppKit -[_NSBindingAdaptor browser:willDisplayCell:atRow:column:] + 288 7 AppKit -[NSBrowser _sendDelegateWillDisplayCell:atRow:column:] + 64 When you bind selection

Thanks for posting the crash log. The stack you've shown isn't enough on its own to point at a specific cause — the WebKit frames are still , and there's no information about the WebView itself or what triggers the crash. Before going further, could you share the following? The WebView setup — how you create, configure, and present or dismiss the WebView. The relevant view controller code, your WKWebViewConfiguration, and the navigation flow that leads to the crash. Reproduction steps — what does someone do (or what does the app do) right before the crash? The frame _UIContextMenuAnimator performAllCompletions suggests a long-press preview menu may be involved. Does the crash require a context menu to have opened first? Frequency and conditions — does this happen in your own testing, or only in production via crash analytics? Specific iOS version (26.0, 26.1, 26.4)? Specific devices? Any particular network or content state? The original crash report, not a forwarded copy — those WebKit frames are us

You've narrowed this down well, and the corroborating reply confirms it isn't device-specific. What you're describing isn't expected behavior — third-party MusicKit clients shouldn't lose access to playback because the native Apple Music app has a pending post-update onboarding modal. Shared service initialization (account readiness, subscription state, and so on) should happen independently of the native app's UI state, and the fact that a single Apple Music launch + modal dismiss restores everything to working order points to some shared component lazy-initializing only when Apple Music itself runs. A few things: On a force service initialization API: there isn't one in public MusicKit, and adding one wouldn't be the right fix — the underlying services shouldn't get into a broken state in the first place. That's the bug. Please file a Feedback Report. Even if other developers have already filed, duplicates matter — independent reports count as a signal of impact, so each FB from an affected app rai

Thanks for the clear writeup and screenshots — they made this easy to reproduce. With a 3-column NSSplitViewController + PDFView in macOS 26, I confirmed exactly what you're seeing. With detailItem.automaticallyAdjustsSafeAreaInsets = true, the detail view's frame extends under the panels and safeAreaInsets reports correct values — but PDFView's autoScales math positions and scales the page based on the full bounds, ignoring the safe-area region. The page anchors at the left of the bounds, partly under the sidebar, regardless of where the visible gap is. I tested the workarounds that look like they should help, and none of them work: Setting pdfView.additionalSafeAreaInsets to mirror the safe area — PDFView's scaling math doesn't read it. Setting contentInsets on the internal scroll view (pdfView.documentView?.enclosingScrollView) with automaticallyAdjustsContentInsets = false — works for one layout pass, then autoScales recomputes against the full bounds on resize and reverts. Disabling autoScales and comput

Followup: filed FB21570087 per Quinn's suggestion. Digging into the behavior for the write-up turned up something my original report missed. The check in xcrun / clang is on the basename of the developer path, not the full path: basename CommandLineTools -> accepted as a CLT install path matches *.app/Contents/Developer -> tried as Xcode (also needs Info.plist + xcodebuild) anything else -> rejected with the unable to find Xcode installation error The parent directory isn't checked. My attempt with /Library/Developer/CommandLineTools-26.2.0 failed because of the basename, not the location. Since DEVELOPER_DIR is a per-process env var, not the global xcode-select selection, parallel multi-version CLT actually works: DEVELOPER_DIR=/opt/clt/17/CommandLineTools clang --version # 17.x DEVELOPER_DIR=/opt/clt/16/CommandLineTools clang --version # 16.x Two shells can run these concurrently and each sees its own CLT. /Library/Developer/CommandLineTools can still point at one of them as the default fo

Adding the direct App Store link for easy verification by readers and Apple staff: https://apps.apple.com/jp/app/zenterm/id6760935103 Clicking the link opens the product page normally — yet searching zenterm in the App Store app returns zero results. This split between direct link works and search returns nothing is the core symptom and the reason this needs investigation at the indexing layer.