“show when run”

Seen this one a lot. Subscription is unavailable in the current storefront almost always comes down to one of these, in order of likelihood: Paid Apps Agreement isn't in Active state for the team. Open App Store Connect > Agreements, Tax, and Banking. If the Paid Apps agreement shows anything other than Active (Action Required, missing bank info, missing tax forms, or a contact who's no longer on the team), every subscription rejects with this exact error until it's resolved. The subscription's price schedule doesn't include the user's storefront. Each subscription has pricing set per country. If you only configured prices for some countries, users outside that list get this error. Check the Price tab on the subscription and confirm the user's country is covered. The app and the subscription are in different availability regions. Even with pricing set, the app itself must also be available in that country. Check App Availability on the main app page. The subscription isn't actually in Ready for Sa

Classic StoreKit 1 to 2 migration pitfall. A few things worth checking: The sandbox account matters more than you'd expect. When you reinstall, make sure you're signed into the same sandbox Apple ID that actually made the SK1 purchase. If it's a fresh sandbox user or a different one, there's literally no transaction to restore. Settings > Developer > Sandbox Apple Account shows who's currently active. For a non-consumable originally purchased via SK1, after AppStore.sync() completes, the transaction shows up in Transaction.currentEntitlements with its original productID, but the id or originalID might be a legacy numeric identifier rather than a UUID. If you're filtering entitlements by anything other than productID, that could be why you don't see it. AppStore.sync() triggers an Apple ID password prompt. If the user cancels that prompt, it returns without throwing but also without actually syncing. Wrap it in try/catch and log so you can distinguish canceled vs successful vs failed. I

When start arrives but updates don't on one specific device, it's almost always one of three things. Walking through them: Wrong push token for updates. The start push uses apns-push-type: liveactivity plus your app's device token. But once the activity is running, each activity has its own token delivered via Activity.pushToken (or pushTokenUpdates as an async sequence). Every update has to go to that per-activity token, not the device token, and not a stale token from a previous activity. Worth logging and diffing the token you're actually sending between 16 Pro and 16 Pro Max. stale-date already in the past. iOS silently drops updates whose stale-date is before now on the device. Small clock drift or a timezone mismatch is enough. Try pushing with stale-date explicitly far in the future and see if that changes anything. content-state schema mismatch. If your ContentState decoder throws on the update payload (new field, wrong type, enum case removed), the update is dropped with no user-visible sign

Sounds like a frustrating regression. Before chalking it up to a bug, a few things worth trying: The transaction cache in Xcode's StoreKit environment gets into weird states after major version upgrades. From Xcode, open Debug > StoreKit > Manage Transactions, delete everything in there, then clean build folder (Shift-Cmd-K), nuke DerivedData, and restart Xcode. On the running target, delete the app entirely before re-running. Second, check your scheme's StoreKit configuration setting. The Xcode 16 to 26 migration has been resetting StoreKit Configuration to None on some projects. Edit Scheme > Run > Options, confirm your .storekit file is still selected. Third, when purchases silently fail without even showing the confirmation sheet, it's usually the store failing to resolve the product ID. Open the .storekit file, hit the refresh/sync icon, and confirm every product identifier matches what your code requests exactly (it's case-sensitive). Did macOS also update

@dser Thanks for the post, 26.5 beta 2 should also be fixed as showing the fix in the release notes. Will be great to get to the bottom of this and why does not work for you on 26.5 beta 2. If there is any way you can provide the information and the sysdiagnose, we could go ahead and file a bug? Albert
  Worldwide Developer Relations.

Hello.. if you edit the scheme to run the app as root, then the menu works.. this is a risky workaround that you can use only when testing the menu, after that, better go back to the previous setting.

Hey , Hoping you might be able to share some of your wisdom with me. I’m an iOS dev with around 9 years experience and this past year have finally started shipping my own apps. For me the biggest thing I’m struggling with is distribution. Primarily, I’m posting on TikTok as that’s where a majority of my audience seem to be. Im running search ads for specific keywords but I’m remaining conservative with the bids as it just doesn’t have the ROI. how have you handled marketing or has it been mostly ASO? A self sustaining indie dev life is the goal in the next 3-5 years for me. So would love to hear more from you about your experience!

Bah, again, I’ve just not had time to get back to this. If I were in your shoes I would: Create a minimal test project that illustrates the issue. That’ll ensures that there isn’t some other part of your app that’s causing problems. Run it on two devices connected over infrastructure Wi-Fi. If that doesn’t work, there’s something wrong with your code. Run it again with the devices not on infrastructure Wi-Fi, and thus relying on peer-to-peer Wi-Fi to carry the packets. If that fails, file a bug with your results. Make sure to include: Your test project. Sysdiagnose logs taken on both devices shortly after reproducing the problem… … with additional logging enabled per the Network Diagnostics for iOS/iPadOS instructions on our Bug Reporting > Profiles and Logs. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t think there’s an actual problem here, largely due to the magic of Objective-C. Consider the small test code at the end of this reply. It declares the requestedMountOptions property without any availability, and I think that’s just fine. Lemme explain… I put this in an Xcode command-line tool project, set the deployment target to macOS 26.0, and compiled it. I then dumped its imports: % otool -L MyTool | grep FSKit % It doesn’t import any symbols from FSKit at all. That’s because FSKit is an Objective-C framework and all the stuff used by the class is either found at runtime by name or is a C-style declaration that has no runtime impact [1]. This doesn’t mean that it isn’t connected to the Objective-C runtime. If you run this command: % otool -o -v MyTool … stuff … you’ll see lots of connection points. However, Objective-C is super dynamic, so that stuff all gets resolved by name when your class is loaded. And the runtime on macOS 26.0 will happily ignore the fact that you’re claiming to imple