Problem We are implementing an auto-renewing subscription using StoreKit 2 to allow users to unlock Pro features in our application. Prior to this, our users would purchase a non-renewing subscription of 1-year access to Pro features, and would manually renew each year. We want to offer a 2-week free trial to new customers, but exclude the 2-week free trial from users who have already had access to Pro features within the last 3 months (i.e. loyal customers who have been paying for Pro for several years). Introductory Offer Our current plan is to use an Introductory Offer, but as far as we understand this will apply the free trial to any user whose Apple ID has not yet purchased this auto-renewing subscription within the app (which would be 100% of our users), and we cannot define a user's eligibility for an Introductory Offer on our own. Are we mistaken here?/Will users who have purchased a non-renewing subscription still be eligible for the Introductory Offer on the auto-renewing subscription? Promotional Offer We would like to use a Promotional Offer to apply the free trial at our discretion. However, we noticed the following stated under Promotional Offer in the documentation: "Customers who have not subscribed within the app cannot complete this type of offer" Does this mean that we will need to offer the free trial to 100% of our users? Alternatives Another option we are considering would be creating a separate Subscription product within the same Subscription Group that does not include an Introductory Offer. We would allow new customers to purchase the product with the free trial, and only allow existing customers to purchase the product w/o a free trial. We would like to avoid having to maintain multiple Subscription products for what is ultimately the same "product", and worry that this would be a misuse of Subscription Groups. Interested to hear if anyone else has done that, and whether that is allowed by Apple's app review.

We have implemented an auto-renewing subscription as an in-app-purchase for our iOS application. We are consuming the App Store Server Notifications for subscription transactions in order to update the user's account (and thereby maintain their 'Pro' access to our application). Sometimes those notifications never come to our server, and there is no evidence that they were even attempted to be sent to us. We have had some users report to our Customer Support team that they have successfully made a purchase of the subscription, but that they were not granted 'Pro' access. For the large majority of users this is not happening and all is well, but for some users the notifications just never come from the App Store Server API. We keep a record of all notifications that we receive from the App Store, and for these users we never received the "SUBSCRIBED" event. We have checked the Notification History API and there are no reports of any failure to send notifications to our server. We have checked our server logs for any sign of failure to receive incoming web requests, and there is no sign of these missing notifications. We have verified that our server supports ATS. We are keeping the transaction.originalID for all our users who are subscribed to the auto-renewing subscription. We have used this value to do some lookups into the transaction history and subscription status of the users who are being affected. Here is an example of our findings from those lookups: From the transaction history endpoint, we received an error: “Invalid transaction identifier”. From the subscription status endpoint, we received a response with the information for that user's active, valid subscription. We never received any App Store Server Notifications about this user’s subscription, and the transaction history API tells us it is an invalid transaction ID. We believe that the fact that the subscription status API returned the information showing that this user’s subscription is active and valid, and that the notification history API shows no sign of a failure to send us notifications about that subscription, shows that the App Store Server API never attempted to send us any notification for this user’s subscription. The same is true for a significant number of other users of our service. Can anyone help us determine what is going on, and how to best support these customers? It seems as though there was never an attempt to send these notifications to our server, but our users provide proof that they do in fact have an active subscription, for which they have paid (receipt email from Apple with a valid order ID).

Our builds are not successfully processing through App Store Connect, since noon ET today at the earliest. They are successfully uploading to App Store Connect, but they do not appear at all on the TestFlight page. We have Xcode Cloud builds running that should be deploying builds to internal & external testing on TestFlight, and they successfully archive and save the artifacts (green check in the Xcode Cloud log), but are not showing up in the list of downloadable artifacts in the Xcode Cloud build logs. Those builds made on Xcode Cloud are also not showing up in TestFlight, and the Xcode Cloud workflows get stuck and continue running ad infinity, running up our hour usage. We have tried from 2 separate developer machines to manually archive and upload, and those builds successfully uploaded, but have not yet appeared on App Store Connect on the TestFlight page. Really hope this is resolved soon, it is a major inconvenience to our release process.

Context: I maintain an app that has a UITabBarController at its root, and the tabs are UIHostingControllers to (mostly) SwiftUI views. I have a UINavigationController I present from that tab bar controller, and the rootViewController of that presented nav is a UIHostingController with SwiftUI views inside (not using NavigationView in there, but I am using .toolbar and NavigationLink). I'm trying to use TipKit in this presented SwiftUI view, and its led to a couple unexpected issues: When I dismiss a tip, the entire presented view controller hierarchy is dismissed (like calling window.rootViewController.dismiss()) somehow, configuring the tooltip inside of a ButtonStyle resolves this issue When I show a tip pointing at a Button inside of the .toolbar sometimes that tip is presented in the top left corner of the window, not pointing to the view properly when the tip is dismissed, that button then stops calling its action and does nothing Has anyone else experienced this/anything like it? Because of this (and other issues from the past) I get the sense that Apple is of the mind that you should either have a fully UIKit application, or a fully SwiftUI application, since issues with bridging between the two are not uncommon and solutions are unclear/undocumented. Curious what others think about this, and about maintaining UIKit/SwiftUI hybrid apps in general.

Since yesterday, we have experienced Xcode Cloud failing to upload our archives to TestFlight/App Store. Unsupported SDK or Xcode version? Here is one of the error messages we see on Xcode Cloud: Unsupported SDK or Xcode version. Your app was built with an SDK or version of Xcode that isn’t supported. Although you can use beta versions of SDKs and Xcode to build and upload apps to App Store Connect, you need to use the latest Release Candidates (RC) for SDKs and Xcode to submit the app. For details on currently supported SDKs and versions of Xcode, visit: https://developer.apple.com/news/releases. All of our Xcode Cloud workflows are configured to use the 'Latest Release' of Xcode and macOS (Currently Xcode 15.3 Release Candidate (15E5202a)), so I'm unsure why we are getting the above error. Invalid Bundle (SPM)? Some other errors that have just started to pop up are related to our Swift Package dependencies. We use Xcode's in-IDE interface for managing package dependencies (no custom Package.swift file). Here's some of the error messages we've seen: Invalid Bundle. The bundle {MyAppName}.app/Frameworks/{FrameworkName}.framework does not support the minimum OS Version specified in the Info.plist. Invalid MinimumOSVersion. Apps that only support 64-bit devices must specify a deployment target of 8.0 or later. MinimumOSVersion in '{MyAppName}.app/Frameworks/{FrameworkName}.framework' is ''. Missing Info.plist value. A value for the key 'MinimumOSVersion' in bundle {MyAppName}.app/Frameworks/{FrameworkName}.framework is required. The bundle 'Payload/{MyAppName}.app/Frameworks/{FrameworkName}.framework' is missing plist key. The Info.plist file is missing the required key: CFBundleShortVersionString. Please find more information about CFBundleShortVersionString at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring I am not sure what to make of these errors, as we have not made any changes to minimum deployment version of any of our project's targets. These errors seemed to start happening out of nowhere, sometime between last Friday and yesterday. Any help would be very appreciated!!

Having an issue today where archives on Xcode Cloud are failing at the Code Signing step. The error reported by Xcode Cloud has been one of the 2 following: 502 error from developerservices2.apple.com Unexpected character 'u' (I assume this is in some way related to the HTTP failure above, but please correct me if I'm wrong) Sometimes they even appear together, with the HTTP error as a warning and the unexpected character as the error I assume this is some kind of Xcode Cloud / developer tools outage. I saw another post on the forum from 3 weeks ago that reported the same errors coming from Xcode Cloud. I also saw that there is a "Resolved Outage" with Xcode Cloud from 8/19 (maybe that is related)? Has anyone found a way around this? Any updates on when this will be resolved? It has been happening for us consistently since the first Xcode Cloud archive that we ran today (around 10AM EDT).

Any Xcode Cloud workflow with 'Pull Request Changes' as one of its start conditions has suddenly stopped working altogether. The workflow is never started. This issue seems to have begun within the last 48 hours. Removing the 'Pull Request Changes' start condition makes the workflows functional again. The test I just ran to confirm this: Created a new Xcode Cloud workflow Selected Start Conditions: 'Pull Request Changes' from/into any branch, when any files are changed Selected Test as the 'Actions' Created a pull request on my github repository The workflow was never started Added 'Branch Changes' to the Start Conditions, specifying branch-a under 'Custom Branches' Pushed to branch-a The workflow was never started Removed 'Pull Request Changes' from the Start Conditions Pushed to branch-a The workflow finally started Curious if others are having this issue? And if so, is there a timeline for when this will be resolved? I have confirmed that our Github actions are configured properly, and believe this is indeed an issue with Xcode Cloud.