In our product, we are submitting app into appstore and testflight using Appstore connect api. We need information about status of the app submission both in appstore and testflight. I was hoping that any notification might be sent through webhook, but couldnt find any way. My requirement is keeping the app status of an app up-to-date (in our product). There are two ways to do that, 1- Regularly check status of the app using rest service (for example every 10 minutes) and update it. 2- Subscribe a service or create a webhook that can be used to notified about status changes. Is there any suggestion, or any guidence how can second way work? Is there any such options?

We've recently submitted an App to be Unlisted. The email suggests it takes up to 3 business days to process. We received and are reviewing your request for unlisted app distribution. Please note that we respond to requests in the order we receive them and will respond to your request within three business days. We haven't seen any progress on the Unlisted submission and have not seen an email notifications after the 3 business days has elapsed. Occasionally, the App will get a store page URL around the time of a completed Unlisted app submission, this has yet to happen. Previous Apps of ours that are unlisted got an email with a ticket number, the most recent submissions do not have a ticket number, only an acknowledgement of the form submission. Would it be possible to know if there is an additional wait time? Are others experiencing a similar delay?

Hello, I have a multi-platform app that is split across two organizations: One is on iOS, and is distributed using the App Store with bundle ID X with team ID A. One is on macOS, and is distributed using Developer ID with bundle ID Y with team ID B. Once again, these are in two separate organizations. To consolidate these accounts we'd like to transfer ownership of Y to team ID A. However, according to the app transfer criteria, it appears that that's not possible: Both the transferor and recipient accounts can’t be in a pending or changing state, and the latest version of their paid and free agreements must be accepted. [...] The app must have had at least one version that's been approved for distribution. Given the context from the rest of the page, it seems valid to assume (and I've confirmed this through speaking with technical support) that apps are only eligible for transfer if they've been submitted to the App Store, so I'm considering looking into it just for the purposes of this transfer. This app has a fairly large user base and if possible we want to avoid any user disruption (and any cost inflicted on our API) as a result of a forced logout due to losing access to the previous keychain. As a bonus, it would be nice, though not necessary, if the macOS app could ship under the same entry as the iOS app. As I understand it, this would require changing the macOS app to use bundle ID X. Before going down this road, I'd like to confirm if the following plan is a sane one for accomplishing a complete app transfer that satisfies the above requirements: Distribute the app on the macOS App Store under team ID B. Transfer the app, and continue distribution on the macOS App Store under team ID A. Obtain a new Developer ID certificate for using bundle ID Y with team ID B. Resume distribution of the Developer-ID-signed app with team ID B, without loss of keychain access. If loss of keychain access is not possible, can someone confirm if it is at least possible to keep the same bundle ID after performing the steps above? Many thanks in advance for your help - there is much conflicting information online and in this forum, and little documentation when it comes to Developer ID transfers. I've even spoken to several Apple employees who have directed me here.

I am wondering if there is an issue with screenshot uploading, I am logged in with passkey, and using latest beta of OSX. Process completes, the images appear with blur, then immediately disappear...but a refresh shows them with "this file has not yet been uploaded" and a cloud icon. Have tried multiple times.

We develop an SDK that is distributed as a statically linked, closed source Swift Package. Our customers have reported an issue when attempting to ship an application to the App Store using Xcode 15.3 that is preventing them from uploading the application: Asset validation failed Invalid Bundle. The bundle <AppName>.app/Frameworks/<Framework>.framework does not support the minimum OS Version specified in the Info.plist. (ID: 9cec9306-80a4-4503-a9bf-bd6e367f9679) Our SDK has a minimum deployment target of iOS 13.0 and the customer has a deployment target of 15.2. During local testing, I find that if my application and framework BOTH share the same deployment target of 13.0, then the App Store validation passes. If the application minimum version is greater than the framework minimum version, then the check fails. Researching on the internet, other people have suggested making the minimum deployment version of these Swift Packages to be GREATER than the app version. For instance, a handful of the Google SDKs shipped as binary packages on SPM are setting their minimum deployment version to 100.0 to work around this issue. I have tried this locally and found that if my app minimum deployment target is 15.2 and I set the MinimumOSVersion in the framework’s Info.plist file to 100, it passes the AppStore validation. It would appear that the check is inverted on App Store validation process. It is expected that an application can be submitted to the AppStore using a framework that works with older deployment targets. This issue appears to be related to the fact that Xcode 15.3 now embeds a .framework for statically linked framework dependencies. This is presumably done so that third party SDK's PrivacyInfo.xcprivacy can be included in the app package that it distributed to the app store. The binary portion of the statically linked library turns out to be much smaller (approx 35k) than the binary portion distributed in the .xcframework and appears to just be a small placeholder that does nothing since the actual code from the library is statically linked into the resulting application. The problem with the workaround that the other framework vendors have taken is that eventually (hopefully)  will fix this check and then these frameworks will appear to target a no existing iOS version. The other workaround that I spoke to our customer about was also extremely hackish and not really recommended was to resolve the Swift Package, then manually modify the contained Info.plist file to set the MinimumOSVersion in there to match what they are targeting for their application. This, however, then breaks the code signing of the SDK. So they then need to delete the _CodeResources folder from the resolved .xcframework. None of these work arounds are really sustainable and violate all the things right in the world. I have created feedback FB13704428 for this issue, but am hoping to raise further awareness as this is causing customers to not be able to ship applications using our, and many other, third party SDKs. Additional reading: https://github.com/google/GoogleSignIn-iOS/issues/375 https://github.com/google/abseil-cpp-binary/pull/6/files (If you examine the info.plist files in the two versions, you can see the minimum version set to 100 in the latest) https://github.com/AppsFlyerSDK/AppsFlyerFramework/issues/263 https://www.reddit.com/r/swift/comments/1bd7kxj/swift_ios_cannot_upload_to_testflight/

After uploading an iOS app for peer testing, users got 'invitation expired' errors. The next day I'm attempting to fix this problem. The uploaded app no longer appears anywhere in the app's TestFlight pages. What happened? Ho do I fix it? I can't re-upload, of course I get 'that version already uploaded'.

Hello. My MacOS application has been regularly notarized for 12 weeks to allow people test the beta version, without any problem. Now the application is ready for Appstore submission. Unfortunately, the uploading process ends with an error: "Bad CFBundleExecutable. Cannot find executable file that matches the value of CFBundleExecutable in the nested bundle ApplicationHelp [fr.application.pkg/Payload/Application.app/Contents/Resources/ApplicationHelp.help] property list file." In the ApplicationHelp target, no CFBundleExecutable key is set. But if I read the Info.plist of the built help bundle, I can see that such key has been added during the build process. What can explain the presence of this key that seems to create the error when trying to upload the application package to the Appstore? The only keys set in the help bundle info.plist are: HPDBookAccessPath HPDBookIndexPath HPDBookTitle HPDBookType CFBundleDevelopmentRegion CFBundleIdentifier CFBundleSignature CFBundleVersion CFBundlePackageType CFBundleInfoDictionaryVersion Using Xcode 15.2 on Sonoma, application built for MacOS ≥ 12 (Apple Silicon only) Thanks

I am about to remove the app from the Apple store. Before App removal, we are planning to have an App update which shows only the pop up saying that "the app is not functional anymore' and it will redirect to the website. Will Apple review team accept this app update? Wil there by any rejection? Kindly let me know your feedback? Anyone experienced before?

Hello, I'm create an app using QT on MacOs with Generate to Xcode, when submitting it to the App Store the upload process was successful but I got email feedback with the message containing the following: ITMS-90238: Invalid Signature - The main app bundle Tren at path Tren.app has following signing error(s): a sealed resource is missing or invalid . Refer to the Code Signing and Application Sandboxing Guide at http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html and Technical Note 2206 at https://developer.apple .com/library/mac/technotes/tn2206/_index.html for more information. ITMS-90296: App sandbox not enabled - The following executables must include the 'com.apple.security.app-sandbox' entitlement with a Boolean value of true in the entitlements property list: [[Tren.app/Contents/MacOS/Tren ]] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app. I've done the methods available in the community, but it still doesn't work. I hope someone will provide a solution, thank you

Can someone please confirm in this case whether I need a privacy manifest in BOTH my app, and the third party SDK. One of the Firebase SDKs we are using uses UserDefaults. As such we are now getting warning emails from Apple about using restricted APIs. Google have said that they will be releasing a privacy manifest that will get rid of this error. However, the app itself does, like most, use UserDefaults itself. With Firebase already declaring the usage of UserDefaults, is it necessary to then re-state it, in a privacy manifest for the app? Or is this simply the third party SDK provider's problem? Thank you

I submitted a review, but soon after I removed the build from review because some bugs were found. Normally, the status should go 'Developer rejected'. But this time, in App Review, it stuck in 'Processing' for a long time. And App Store Connect says 'You have an App Review submission cancellation in progress. You can resubmit items for review again after the cancellation is complete.' I contacted the app review team but have not got reply so far. How can I deal with this problem?

Hi, we have an old cordova/phonegap app that we are trying to upload through Transporter, but suddenly we started getting the following error: "Missing Info.plist value. A value for the key “WKApplication”, or “WKWatchKitApp” if your project has a WatchKit App Extension target, is required in “.app/.app” bundle. For details, see:" We don't support Apple Watch and there is no target for Apple Watch, there does not seem to be anything to do with Apple Watch in our XCode project, yet we are getting the above complain. We using the following versions: XCode 15.0 Cordova: 12.0.0 cordova-ios: 6.3.0 There has been no change to our provisioning profile. Any idea why we are getting the above complain?

Since yesterday (03/22/24) we are unable to upload new or existing builds to AppStoreConnect. We get the following error - “Error ITMS-90432 Unexpected file found in Frameworks. MyApp.app/Frameworks/Configurations” file is in the Frameworks directory, but the Swift runtime libraries are the only files permitted in that directory. Please remove this file and upload a new build. (ID: 57e219ea-d27e-465d-9e9b-ec41d3a0b1f7). We have tried rebuilding targerts with no changes for Builds that use to upload ok and they now get the same error too. Is this an appstoreconnect bug? If not where is the Frameworks directory and how do we remove the file?

I'm encountering an issue with the age rating of my app in App Store Connect and would greatly appreciate your insights. Initially, when setting the age rating for my finance management app, I misunderstood the requirements and selected an age rating of +17 under the assumption that I had to choose either "Made for Kids" or "+17." Realizing that the content of my app is suitable for a broader audience, I am attempting to adjust the age rating to 4+. However, despite not selecting the "Made for Kids" or "Restrict to 17+" options, and intending to proceed with a 4+ rating, the changes don't seem to be registering. Clicking "Done" after modifying the age rating doesn't appear to have any effect. Here's a snapshot of the page where I'm stuck (see attached image). Thank you in advance for your time and assistance.

Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage To resolve this issue, it would be appropriate to take the following steps: If you are authorized to provide this service in the app, please provide evidence of your relationship with the institutions or organizations associated with the app. If you do not have authorization, the app needs to be published under a seller name and company name that reflects the app name. If you have developed this app on behalf of a client, you may resubmit the app through their account, if they have one. You may also request an update to the company name on your account by having the Account Holder edit the account information. Resources Learn how to transfer apps between accounts. Request a fee waiver for nonprofit organizations, accredited educational institutions, or government entities. Support Reply to this message in your preferred language if you need assistance. If you need additional support, use the Contact Us module. Consult with fellow developers and Apple engineers on the Apple Developer Forums. If you think your submission follows the guidelines or feel the review was unfair, you can request an appeal with the App Review Board. Help improve the review process or identify a need for clarity in our policies by suggesting guideline changes.

We have version 1.0 of our app which was published for a preorder. We recently pushed some updates, created a version 2.0, and it went through review and was accepted. Now we'd like to retire the version 1.0 and use the 2.0 for the preorder. Is it possible to keep the people who have already pre-ordered the app or do we have to throw version 1.0 and re-publish a new pre-order?

Am tired of asking my boss to forward me the emails they get from Apple with the subject "The uploaded build for XXXX has one or more issues." I am trying to debug issues such as ITMS-91053: Missing API declaration as we deal with our 3rd party package usage. What permissions, privileges do I need to get those emails?

We are getting warnings from Apple, ITMS-91053 Missing API declaration, for categories Disk Space, Timestamp, and more. But we've checked our source code to make sure we are not making any of the entry points at issue. We suspect they are being called from one of the 3rd party frameworks we use, some of them are binary xcframeworks. Is Apple planning on extending their warnings to provide more information about where the usages are? Are we left to find it ourselves? Do we need to resort to adding those reasons to our app's manifest? Which seems hacking since we probably don't know when of the allowed reasons are accurate.