I have 6 Mac App Store apps. They're all upfront paid, with no IAP, and they've all used the same on-device Mac App Store receipt validation code for years, which returns 173 in main() if there's not a valid receipt. Incidentally, the apps are entirely Objective-C. I've just learned that if I compile an app with Xcode 16 and the macOS 15 SDK, I get the alert "exit(173) Not Available" when the app returns 173 on macOS 15 Sequoia. The rest of the alert text says, "The exit(173) API is no longer available. You can use Transaction.all or AppTransaction.shared to verify in-app purchases instead." I have several questions: Why was this done? Where is this behavior change documented? What are my options, given the above description of my apps?

My Safari extension has a WKWebView in the main app and an HTML popup window in Safari. For some reason, both are in dark mode on visionOS, even though the device environment is light and Safari tabs are also showing light mode. Why does this happen, and how can I change it?

I want my Mac app to receive silent push notifications from a CKSubscription while the app is not running. Is that possible? Does the following apply to macOS apps too, or only to iOS apps? That flag causes the system to wake or launch an app that isn’t currently running. The app then receives background execution time to download any data for the push notification, such as the set of changed records. https://developer.apple.com/documentation/cloudkit/cksubscription/notificationinfo/1515110-shouldsendcontentavailable

I have Xcode 15.0 beta (15A5160n) and the iOS 17.0 beta (21A5248u) simulator installed on macOS 13.4 (22F66). I have iPadOS 17.0 (21A5248v) installed on my 8th generation iPad, and developer mode is enabled. Whenever I connect via USB and attempt to pair in the Xcode Devices and Simulator window, I get the error "Unable to locate a valid DDI for the iOS platform." I've tried unpairing and repairing multiple times. I've rebooted the iPad and my Mac. Nothing works.

I want to set a minimum Safari version of 17 for my upcoming Mac App Store Safari extension, while still supporting Monterey and Ventura. Is that possible?

For the sake of the Safari extension community, I've posted all of my Safari extension issues from Feedback Assistant on GitHub. You're welcome to post yours there too! Together we can create a publicly searchable bug database, which currently doesn't exist. I hope this helps to improve the quality of Safari extensions across the board. Here's the list on GitHub: https://github.com/lapcat/SafariExtensions/issues

Suppose I have 3 paid apps: A1: iOS App Store only A2: Mac App Store only A3: Universal Purchase and 2 bundles: B1: A1 and A3 B2: A2 and A3 (As far as I can tell, it's impossible to have a bundle with A1 and A2.) Is it possible for a customer to buy and/or complete both B1 and B2, and if so, how much money will the customer end up paying relative to the prices of the apps and bundles?

I just want to notify everyone of a bad bug in Safari Technology Preview 141 that affects Safari web extensions and Safari app extensions. The bug is that JavaScript instanceof returns the wrong value in MutationObserver callbacks. I suspect that a lot of extension developers use MutationObserver, so make sure to test in Safari Technology Preview 141 to see whether you're affected. The bug does not exist in Safari 15.4, released yesterday. Hopefully we can stop this bug from shipping in regular Safari, or it could be a giant mess for extension developers! WebKit bug link

Hi. I've started a Slack for Safari extension developers! Email me for an invitation: slack at lapcatsoftware.com The purpose of this Slack is mutual support for Safari extension development on iOS and/or macOS. Apple engineers who work on Safari extensions are welcome too!

Hi. I'm trying to port my Safari app extension with an injected content script to a Safari web extension on iOS. Content scripts in a macOS Safari app extension always behave as if run_at document_start were specified in the manifest of a Chrome extension. This is crucial to my extension for several reasons: I need to load my JavaScript before any of the page scripts load, and I need to start fetching my site-specific preferences ASAP. Unfortunately, document_start doesn't work right with Safari web extensions in Safari 14 or Safari 15 on macOS. This is made even worse if Preload Top Hit is enabled in Safari, but document_start is unreliable even with Preload Top Hit disabled. I've been testing with Safari on the iOS 15 beta, and I've noticed that document_start does seem to work right (unlike Safari Mac) with Preload Top Hit disabled. However, enabling Preload Top Hit still causes it to be unreliable on iOS. This is all in contrast to Safari app extensions, which just always load at the start, regardless of whether Preload Top Hit is enabled. Though of course Safari app extensions do not exist on iOS. I'm wondering if Apple's Safari engineers could comment about this. Are there differences in web extension implementation between iOS and macOS? Can I depend on iOS document_start working right with Preload Top Hit disabled? Is there any way that you could fix the Preload Top Hit behavior? (In my testing, document_start seems to work with preload in Google Chrome.) The developer forums don't see to allow me to attach a zip file (is this possible?) but I've got a sample Xcode project that can demonstrate this behavior.