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!

Hey @backbetterapp, Would it be possible to share a bit more detail around specifically what you are trying to accomplish so the community can help? It is not clear where you are getting the stated error and the activity that you are attempting to complete. Looking forward to helping you find a solution!

Hey @tngacker, Do you happen to know how large the IPA file is that is attempting to be pushed by the MDM to the mobile client? Is it possible that you are hitting a size limit for installing over cellular? Hopefully this helps!

Hey @Zaszko, I personally have not run into this issue. What I did notice when I moved to my iPhone 13 is that my Enterprise applications were NOT transferred and I was required to go back to the source of truth and install them again. Even though I could search for and see the applications on my new device, I could not open them and re-installed them which then gave me the ability to "Trust" the Enterprise certificate. In theory, you would imagine that as a part of the backup Apple includes Enterprise applications but maybe they don't? I also checked MDM pushed Enterprise applications and I am not running into issues with these. Could you share what iOS version you are running on the exact hardware? Are you able to install the IPA successfully through Xcode or OTA? If you run into issues installing my first go to is always to open "Console" and start sifting though the logs and looking for errors. Hopefully this helps!

Hey @sienchoo, Thanks for posting this! This is a very common error that we see on our account as we are uploading hundreds of IPA files to Apple on a monthly basis. This will happen even when all of the Apple System Status shows green on their monitoring site. This is indicative of a problem on the Apple side and we have not been able to find anything to help resolve the issue as it is intermittent. When interacting with Apple, we use the command line and we have actually wrapped our upload command into a while loop and will retry to upload an application up to 5 times if we get this error and while we still encounter it, that is enough tries to get the application to go through for this specific error. Hopefully this helps!

Hey @MoHindi, Thanks for posting this question! In our teams experience, if the App Reviewer needs additional context or information on how to login to the application or leverage its functionality, the Review Notes section inside of TestFlight is the right place for this (at least it has worked for our teams). I have to imagine that Apple at least attempts to protect demo account credentials and so the statement is really geared towards trying to keep passwords in protected fields in their databases where the Review Notes could be read by anyone. Not sure if that is true but just a thought. You should be good to put this information in the Review Notes field. Hopefully this helps and happy coding!