Hello atul109,You will need to do some pre-work and create an App Store signed IPA file, but once you have that, the tool that you will want to use is altool. You can get more information on it by typing the below into terminal.man altoolYou can get the same information by running.man xcrun altoolYou will eventually end up with something like the below.xcrun altool --upload-app -f <PathToFile>.ipa -u <Username> -p <Password>I usually run this with a few extra options, but this will get you started and learning.Hopefully this helps!

Hello keech,Can you provide more information on what you mean by "transferred" your application?Was the application existing in App Store Connect and then you transferred ownership to a different organizational developer account?Thanks in advance!

Hello VyomDev,Unfortunately, it is not possible to do this at this time. A common approach to this is putting either "iPhone" or "iPad" in your name and leveraging the subtitle field for additional information, but it is not possible for two App Store listings to have the same name.Hopefully this helps!

Hey Alexey Sh,Apple does noit currently provide a solution to this. However, what I have done to solve this problem is have a standard process for certificate management (which is best practice anyways) and at a high level, put all of the certificates you would like into a keychain and then on whatever basis you would like have a script go through them, check their expiration date and hit an email API to notify whoever you would like with the certificate information.Our solution is much more complex due to the amount of certificates that we manage, but any push solution that would notify you is also having to manually read when the certificate is going to expire in order to notify you.Hopefully this helps!

Hello swiftBank,This is a great question to post on here as it is something that Apple will need to consider as they continue to improve the developer experience for testing with large number of users for controlled applications such as yours pointing to internally protected environments.Our organization currently has this approach with a large number of applications and environments due to certain Apple functionality only being available for real testing using an App Store signed application instead of an Enterprise signed application.To answer your first question, there is nothing preventing you from continuing with your operations as is until Apple provides additional clarity on what will happen with the Enterprise program and what that means for regular developers. For example, MDM platforms still require an Enterprise certificate untill ABM and DEP are adopted widely across the globe so Apple will need to provide guidance or a timeline on when developers will be forced to change distribution models. Your model also sounds like it fits within the original Terms of the Enterprise Developer Agreement.To answer the second question, I would recommend preparing yourself for TestFlight as certain functionality that provides additional security on the iOS platform simply does not exist for Enterprise Signed applications. If it is not possible for Apple to connect to your internal testing networks managed by your organization, then they will most likely ask for a video demonstrating the features of your application much like they do with Bluetooth applications. Apple does a great job working with developers on this and long as you are transparent with the App Review Team.Best of luck and hopefully this helps!

Hey @timothy-sutton, The Apple documentation on this subject is incorrect I believe (but could be wrong). If you are code signing from the command line you will need to include the below as an option where [options] and [more options] should be replaced with the options you would use. codesign [options] --options runtime [more options] Once you include this you will see the Code Directory updated to the latest one available for your Xcode version. I have had a Feedback open for Apple to correct the Documentation at the below URL for some time now but it hasn't been addressed. https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format Hopefully this helps!

Hello @buffon_georges, It looks like this might be related to the Intermediate Certificates that you have installed on the machine. Apple recently made some modifications here so Xcode might have created a new certificate without having the proper Intermediate Certificate installed. You can verify this by looking at your Singing Certificate in Keychain Access, reviewing the "Authority Key Identifier" then ensuring that you have the correct "Apple Worldwide Developer Relations Certification Authority" certificate that has the matching "Subject Key Identifier". If this does not exist, you will not be able to Codesign. New certificates can be found at the below Apple site. https://www.apple.com/certificateauthority/ I am not positive this is the issue without more information, but with what is available I would start searching here and share if this is not the issue. Hopefully this helps!

Hey @leonwu21, Unfortunately I do not believe Apple has provided a way to do this the way that you (or I) are thinking about this. Make sure to file Feedback so they understand your use case and build more tools for the community! With that being said, your approach is in line with what I have been doing. I query for betaGroups, then I query the betaTesters and create a consolidated list and remove any duplicates so I only have a list of unique betaTesters. I then hit the betaTesterInvitations API for all of the testers even though I do not know who has been sent an invitation and who has not. This is where you can programmatically determine who has accepted the invitation based off of the API response. Apple returns a 409 for users who have already accepted the invitation and are testing the application along with additional information in the response body for us to process as developers. Make sure to file Feedback but hopefully this helps! Have a great day!

Hey @bring10, I would strongly suggest opening a Feedback for this if you have not already! Below is the Feedback that I opened at the beginning of April this year. FB9072695 Apple has communicated with me on this but has indicated the system is working as designed and that we should slow down our requests to their service. Due to this I have put all of the API requests into loops with pre-determined attempt and wait counts based off of the API and my experiences along with adding support for understanding how to handle each new error code and message once they are encountered. Make sure to file a Feedback for this but I encounter the same issue all of the time when working with the API and unfortunately have not been able to find a resolution with Apple.

Hey @Krishnatrea, What App Store Connect API are you trying to post data to? Could you please share a link to the API documentation? I am able to post data successfully and will see if I can post an example of a successful cURL request. Thanks!

Hey @RSGDev, This is a great question! I will do my best to provide some information, but I would also strongly suggest opening up a Feedback request if there is functionality that you would like to see that does not exist today. In general, an API endpoint does not exist for what you are looking for with all of the information. Below are some suggestions on how to generate a report that you are looking for. Is it possible to get the install status for a TestFlight user? SORT OF While the API does not tell you the "Status" of a tester like the console does, if you attempt to send each tester another TestFlight invitation using the below API, you will get a 409 response with the reason why the invitation was not sent. One of these reasons will be: STATE_ERROR.TESTER_INVITE.ALREADY_ACCEPTED. You could use this to determine if a user has at least accepted the invitation and thus has the ability to install the application. https://developer.apple.com/documentation/appstoreconnectapi/send_an_invitation_to_a_beta_tester Is it possible to find out which "Version" of an application a user has installed? NOT THAT I KNOW OF Not sure if this would be helpful, but I have a tool that goes through and generates a report on every application in our App Store Connect account and which builds each tester has access to and dumps that out to a CSV file. The way that I do this is through the below steps. Capture the App ID (https://developer.apple.com/documentation/appstoreconnectapi/list_apps) Request ALL TestFlight Beta Groups (https://developer.apple.com/documentation/appstoreconnectapi/list_beta_groups) Request ALL TestFlight Beta Testers for each Beta Group (https://developer.apple.com/documentation/appstoreconnectapi/list_all_beta_testers_in_a_beta_group) Attempt to resend ALL TestFlight Beta Testers an invitation to the application (https://developer.apple.com/documentation/appstoreconnectapi/send_an_invitation_to_a_beta_tester) The above steps will give you all of the information that you need in order to generate a table with each tester, the builds they have access to along with whether or not they have accepted the invitation and are attempting to use the application. One major note on the above steps. If you are not dealing with thousands of testers, I would not worry about this, but once you are testing with thousands of users, I would strongly suggest sorting by user email and NOT by the tester ID. I actually include that as a part of my results due to the App Store Connect API creating multiple "users" for the same email. I know this doesn't answer the direct question you are looking for information on but hopefully this helps and make sure to fill out a Feedback so Apple can help provide what you are looking for!

Hello @Ty_yqs, Are you still encountering this problem? Are you able to successfully generate an App Store profile? I would recommend starting with that in order to make sure that your code works for a simpler profile rather than a development one. Inside of the small code sample that you provided, it looks like there is an extra , in the JSON that is being provided to the API at the end of the certificates section, but I am not sure if that is contributing to the issue. Looking forward to helping if you are still running into this issue!

Hey @limengke, I have not yet run into a "timeout" on the server side, nor do I recall seeing a timeout header provided by the API for any of the endpoints (maybe there is on some of them?). I make hundreds if not thousands of requests to the App Store Connect API every day and I have not run into an issue with the server failing to return data in a timely manner. I would personally set a timeout on the client side to something that is reasonable for what you are trying to accomplish and have a failure or fallback loop. For the API requests that I make to Apple I have my timeout set at 10 seconds and a retry of 5. I have never encountered an experience where if the first 3 requests failed the 4th or 5th worked. Usually there is something broken with the App Store Connect API service and it needs to be investigated. Hopefully this helps!

Hey @limengke, Thanks for pointing this out! It looks like Apple made a change on the backend between late Wednesday the 13th and early Thursday the 14th which now has multiple App Store Connect API endpoints returning "null" values for build specific information. At least this is when I started noticing the changes. I have attempted to call Apple Developer Support along with opening up a TSI / DTS ticket on this and was turned away both times. I am not currently sure what the proper way to report outages bugs is to Apple regarding the App Store Connect API, but if you find a way please post here and I will report this again as well! Hopefully this helps!

Hey @ebrowkin, Would it be possible to share a code sample so that we can see how you are generating and replacing the token? Just enough to let the community help you find the problem? One way to test this locally in a debug environment is to disable the API calls to Apple and log your token every time you run the application so that you can see when it changes (if it does). Depending on your implementation you might want to unset / delete / undefined the variable before trying to store a new value in it depending on its scope. This will also help make it abundantly clear if you are able to remove the value and not generate a new token for some reason. Hopefully this helps!