I'm encountering an issue with the App Store Server API where the appAccountToken is not preserved when users migrate their Apple ID email addresses. I've submitted Feedback Assistant ticket FB18709241 but wanted to check if anyone else has experienced this and get community input on best practices. The Issue When a user migrates their Apple ID from one email to another (e.g., from olduser@example.com to newuser@icloud.com), the App Store creates a new subscription transaction with a different originalTransactionId, but the appAccountToken is not carried forward from the original transaction. What I'm Seeing note: these values are fake When querying /inApps/v1/subscriptions/{originalTransactionId} with the either post-migration transaction ID or the pre-migration transaction ID, the API returns both transactions: Pre-migration transaction (status: 2 - inactive): originalTransactionId: "12345678910111" Contains: "appAccountToken": "abc123-def456-ghi789" Post-migration transaction (status: 1 - active): originalTransactionId: "67891011121314" Missing: appAccountToken entirely The Problem The appAccountToken is our only way to link App Store subscriptions to user accounts. Without it on the new transaction: Users lose access to premium features despite having valid subscriptions Server-side renewal notifications can't be matched to user accounts Manual support intervention is required for each affected user Questions for the Community Has anyone else encountered this issue with Apple ID migrations? What's the recommended approach for handling this scenario? Is there an alternative mechanism to maintain the subscription-to-user linkage across migrations? Questions for Apple Engineers Is this the expected behavior, or should the appAccountToken be preserved? Are there any planned improvements to handle this migration scenario? What's the best practice for developers to handle this case? Interestingly, both the old and new transaction IDs return the same JSON response from the App Store Server API, suggesting Apple maintains internal linkage between these transactions, but the appAccountToken isn't carried forward to the active transaction. Any insights or similar experiences would be greatly appreciated! Thank you!! Feedback Assistant: FB18709241

All of a sudden, after iOS 18.4 was released, I am having tons of navigation problems in my app in production. Buttons navigating to empty pages, views seeming to 'freeze', top navigation bar mismatched with the content of the page. It seems that iOS 18.4 broke a critical piece of UIKit + SwiftUI bridging functionality that my project relies on. ** Originally posted in 'Core OS' topic but realized 'UI Frameworks > General' made more sense. My bad. ** My application is written with both UIKit and SwiftUI components. Here is a breakdown of my setup: UIApplicationDelegate > UIWindow > rootViewController of window is a UITabBarController > each tab is a UINavigationController rootViewController of nav controller is a UIHostingController > rootView of the hosting controller is a SwiftUI View In my SwiftUI views, I have been using NavigationLink for horizontal 'push' style navigation in my SwiftUI views. I do not use NavigationView, I only rely on the bridging capabilities of UINavigationController to action on my NavigationLinks. This has never been an issue, until iOS 18.4 was released. Now, when running iOS 18.4, I am having all sorts of unexpected behavior in the UI. I will break down 2 of these use cases here: Use case A: In one of my SwiftUI views, I have a ForEach for which each element's view is a NavigationLink. This is using the NavigationLink(_ destination:,label:) initializer. Navigating forward from here works/looks normal. However, once I try to navigate backward from that destination (tap the 'Back' button in top left), the view goes blank and the navigation bar at the top of the page (which is maintained by the UINavigationController instance) does not change. If I call popToRootViewController on that nav controller, the navigation bar at the top of the page returns to its normal state, but the view is still blank. It is not until after I have called popToRootViewController, and then navigate to a different tab of the UITabBarController and return to the initial tab, does the SwiftuI content view (the one with the ForEach) finally redraw and the view hierarchy is restored. Here is a warning that is logged in the console when I tap the 'Back ' button: Top view controller's view unexpectedly not in window for navigation transition. Skipping layout. nav = <UINavigationController: 0x1110bbe00>, topVC = <TtGC7SwiftUI19UIHostingControllerV5MyApp10MyPage: 0x106814e00> EDIT: If I replace the NavigationLink with a call to UINavigationController.pushViewController, I am still seeing the exact same behavior. Pressing back button makes the view empty > need to pop to root view controller and switch tabs in order to restore the view. Use case B Another instance of this issue happens whenever I try to use a NavigationLink inside of a view that itself was the destination of a NavigationLink in its parent view (i.e.: Root view > detail view > sub-detail view). For example, take the detail view destination in use case A. I have tapped a NavigationLink from the ForEach and landed on the detail view. Again, so far things work/look normal. Now, if I tap on another NavigationLink from that detail view, the view does not transition to the new page. The top navigation bar does transition, and shows the title and actions associated with this second destination. However, the view of this second destination is not displayed. It is worth noting that the same warning I mentioned above is also logged when I tap the NavigationLink to navigate to this second destination. Top view controller's view unexpectedly not in window for navigation transition. Skipping layout. nav = <UINavigationController: 0x109859400>, topVC = <TtGC7SwiftUI19UIHostingControllerVVS_19BridgedPresentation8RootView: 0x300ab8000> Strangely, if I switch to a different tab of the UITabBarController and back to the initial tab, this second destination's view is successfully rendered. It seems that switching tabs in this UITabBarController is calling something in either SwiftUI or UIKit that is redrawing my views. Conclusion This is a serious issue with UIKit + SwiftUI bridging support. I have never had problems like this until devices started running iOS 18.4, and there is nothing in the iOS 18.4 changelog that suggests this was an intentional change. All of a sudden, after updating to the latest iOS version, my app is totally broken. I want to be clear that I'm not using deprecated NavigationLink methods in these instances. My app's minimum deployment target is iOS 16. I know that there are more modern navigation APIs like navigation stack, etc. I am looking for answers about my use case: whether it is officially unsupported as of iOS 18.4, whether this setup should be supported and this is indeed some sort of bug in iOS, or anything in-between. I'm happy to provide formatted code if needed for discussion purposes. This is about my entire app's view hierarchy so there are a lot of disparate lines of code that make up this problem.

All of a sudden, after iOS 18.4 was released, I am having tons of navigation problems in my app in production. Buttons navigating to empty pages, views seeming to 'freeze', top navigation bar mismatched with the content of the page. It seems that iOS 18.4 broke a critical piece of UIKit + SwiftUI bridging functionality that my project relies on. My application is written with both UIKit and SwiftUI components. Here is a breakdown of my setup: UIApplicationDelegate > UIWindow > rootViewController of window is a UITabBarController > each tab is a UINavigationController rootViewController of nav controller is a UIHostingController > rootView of the hosting controller is a SwiftUI View In my SwiftUI views, I have been using NavigationLink for horizontal 'push' style navigation in my SwiftUI views. I do not use NavigationView, I only rely on the bridging capabilities of UINavigationController to action on my NavigationLinks. This has never been an issue, until iOS 18.4 was released. Now, when running iOS 18.4, I am having all sorts of unexpected behavior in the UI. I will break down 2 of these use cases here: Use case A: In one of my SwiftUI views, I have a ForEach for which each element's view is a NavigationLink. This is using the NavigationLink(_ destination:,label:) initializer. Navigating forward from here works/looks normal. However, once I try to navigate backward from that destination (tap the 'Back' button in top left), the view goes blank and the navigation bar at the top of the page (which is maintained by the UINavigationController instance) does not change. If I call popToRootViewController on that nav controller, the navigation bar at the top of the page returns to its normal state, but the view is still blank. It is not until after I have called popToRootViewController, and then navigate to a different tab of the UITabBarController and return to the initial tab, does the SwiftuI content view (the one with the ForEach) finally redraw and the view hierarchy is restored. Here is a warning that is logged in the console when I tap the 'Back ' button: Top view controller's view unexpectedly not in window for navigation transition. Skipping layout. nav = <UINavigationController: 0x1110bbe00>, topVC = <TtGC7SwiftUI19UIHostingControllerV5MyApp10MyPage: 0x106814e00> EDIT: If I replace the NavigationLink with a call to UINavigationController.pushViewController, I am still seeing the exact same behavior. Pressing back button makes the view empty > need to pop to root view controller and switch tabs in order to restore the view. Use case B Another instance of this issue happens whenever I try to use a NavigationLink inside of a view that itself was the destination of a NavigationLink in its parent view (i.e.: Root view > detail view > sub-detail view). For example, take the detail view destination in use case A. I have tapped a NavigationLink from the ForEach and landed on the detail view. Again, so far things work/look normal. Now, if I tap on another NavigationLink from that detail view, the view does not transition to the new page. The top navigation bar does transition, and shows the title and actions associated with this second destination. However, the view of this second destination is not displayed. It is worth noting that the same warning I mentioned above is also logged when I tap the NavigationLink to navigate to this second destination. Top view controller's view unexpectedly not in window for navigation transition. Skipping layout. nav = <UINavigationController: 0x109859400>, topVC = <TtGC7SwiftUI19UIHostingControllerVVS_19BridgedPresentation8RootView: 0x300ab8000> Strangely, if I switch to a different tab of the UITabBarController and back to the initial tab, this second destination's view is successfully rendered. It seems that switching tabs in this UITabBarController is calling something in either SwiftUI or UIKit that is redrawing my views. Conclusion This is a serious issue with UIKit + SwiftUI bridging support. I have never had problems like this until devices started running iOS 18.4, and there is nothing in the iOS 18.4 changelog that suggests this was an intentional change. All of a sudden, after updating to the latest iOS version, my app is totally broken. I want to be clear that I'm not using deprecated NavigationLink methods in these instances. My app's minimum deployment target is iOS 16. I know that there are more modern navigation APIs like navigation stack, etc. I am looking for answers about my use case: whether it is officially unsupported as of iOS 18.4, whether this setup should be supported and this is indeed some sort of bug in iOS, or anything in-between. I'm happy to provide formatted code if needed for discussion purposes. This is about my entire app's view hierarchy so there are a lot of disparate lines of code that make up this problem.

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.

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).

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!!

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.

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.

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).

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.