I did this several years ago; it was necessary to contact Developer Program Support, who were able to do it reasonably efficiently. I don’t know if things have changed since then.

Is there a known iOS restriction or trick for allowing an extension (share or action) to open its containing app directly? This isn’t allowed. (We don’t know why.) https://developer.apple.com/documentation/foundation/nsextensioncontext/1416791-open This says “Each extension point determines whether to support this method, or under which conditions to support this method. In iOS, the Today and iMessage app extension points support this method. An iMessage app extension can use this method only to open its parent app, and only if the parent app is shown on the iOS home screen.” It would be great if it explicitly said “other extension types do not allow it”; it doesn’t say that, but it is true. If you search StackOverflow you’ll find hacks that bypass this restriction. They seem to involve walking the containing app’s objects to find an unrestricted open() method on the UIApplication. In practice apps that do this do seem to get approved by app review; you may or may not want to risk it. In the case of Safari, you may be able to do it from a Javascript web extension, with some friction. See my recent thread about that.

Custom URL schemes seem to work a bit better than universal links. In all the cases where the universal link attempts to open the web page and adds a page banner saying "Open in APP", the custom URL scheme instead presents a blank grey page with a popup saying "Open in APP?". Although both involve the same number of taps for the user, the latter is much more better in practice as it's obvious what the user has to do.

you need to display the link with an <a href and let the user tap the link. It seems that if I do this within the popup.html, it doesn't work; it opens a new tab, redirected to the web content of the universal link with the "open in app" banner. On the other hand, if I put the <a href="universal-link"> in the content, tapping on it does open the app. Is this a deliberate limitation on what Safari extensions are allowed to do?

Could you please confirm if the link is functioning correctly when accessed through the link embedded within the app’s Notes feature? Yes, the universal links work fine in general, including from the Notes app.

I found this old thread: https://developer.apple.com/forums/thread/684693 which suggests that window.open() might work. It hasn't worked for me yet, but they were discussing custom URL schemes rather than universal links. Might that be significant?

window.open(universal-link) not working for me in 2025. Might a custom URL scheme behave differently than a universal link?

copy my contribution before I submit it I always remember to do that one millisecond after pressing submit.

I suspect that this library is based on BSD Sockets It uses kqueue: https://github.com/boostorg/asio/blob/develop/include/boost/asio/detail/kqueue_reactor.hpp

Posts like yours are quite frequent on the forum. I don't recall anyone ever reporting that their account was re-instated. You are probably doomed. I find this constantly terrifying. The lesson is, don't rely entirely on Apple for your income. Make sure you have your eggs in more than one basket. Don't spend your time specialising in Apple-specific technologies, but make sure you have technical skills that you can redeploy to other jobs when necessary.

I think you're referring to Boost . B e a s t, right? Is that a profanity in Cupertino? Weird. How exactly does it fail? Do you have other ASIO code in the app, and does that work?

Are you seeing this in development or in production?

Does Apple's app validation team use this network mode to test applications? I very much doubt it. I guess there is some other networking problem.

I have an app that includes the original version number in analytics that it sends me. I'm getting this by decoding the receipt in the app, not using AppTransaction. Examples of the version numbers that I get are 4.4.1622388619, 1.2.2 and 2.4. This is an old app. At some point, I started using timestamps as build numbers - hence the 1622388619. At other times I had three-level version numbers, i.e. 1.2.2 is the second bug-fix update for version 1.2. The missing part of the puzzle is what values these versions of the app had in which keys in their info.plists. Looking at just the current version of the app, I have CFBundleShortVersionString = 4.11 and CFBundleVersion = 4.11.1718374078. I believe these are manually set in the info.plist, rather than letting xcode populate them from other fields in the build settings (it's an old app, that's how it used to work). This reports the full 4.11.1718374078 in its analytics. So I guess that the "original version number" that you get from AppTransaction will be the same as the CFBundleVersion in your info.plist - whatever that is. You are probably letting xcode create this field, so check what is actually present in the info.plist in your final app. If I were you, I'd parse the string from the AppTransaction. If it has one component, assume it's a build number; if 2, assume it's a short version number; if 3, assume its version number plus build. (Etc.) Then determine whether it's "new" or "old" based on whatever you have. If you're using revision control versions or checksums, timestamps, or a global counter for your build numbers, this shouldn't be too difficult. It's more problematic if you have incrementing build numbers that you reset for each release. Note there is also the original purchase date, which could be easier to use. (I understand this is different on macOS.)

You may find it in some ARM architecture specs, if you’re lucky.