Hey @iTie, Thanks for posting! What I would suggest is turning off "Automatically Manage Signing" in Xcode and then manually selecting the profile after downloading it to you local machine and then double clicking it to open it and install it (CMD + O will also do the trick). You are most likely running into issues since the profile that you are showing in the portal was created by Xcode (XC in the front of the name), but if you have manually modified it Xcode sometimes runs into problems. Once you have done this you should be able to switch back to Automatically Manage Signing and have Xcode take ownership of the profile again. At least this works for me. Hopefully this helps!

Hello musmanzpak, Thank you for asking this question on the Apple Developer Forums! There are many ways to accomplish what you are looking to do, some including Apple tooling, but nothing out of the box that the Enterprise Developer Account provides to accomplish this. Below are some thoughts on how to go about accomplishing this along with protecting your Enterprise Developer Account to ensure that it does not get used outside of the Terms and Conditions. Use an MDM Solution The best way to accomplish what you are looking to do in my opinion would be to use an MDM solution. It will provide you with authentication and protection of company resources on top of sharing a link for employees to access the IPA file for installation (not sure if you are using OTA based off of what you have shared). If you go down the route of MDM, I would at that point suggest also switching from Enterprise applications to Custom Apps as that will save you copious amounts of time in the long run from a management and ensure your development teams are not building technical debt. Use Push Notifications A simple way to do this would be to leverage Push Notifications if they exist in the application and sending a Push Notification that says something like "New App Version! Tap to Download!" and having the notification open a URL where your OTA file is waiting to install the application. I have some of this implemented and it works well because you should be able to target users based off of their installed application version. Build a Custom Solution (Caution) Another option would be to build a custom solution that "lists" internal content that can be downloaded by Employees (Read Apple Enterprise Developer Terms and Conditions). I would make sure that this is a protected site or application as while it is not against the Apple Terms and Conditions, it can be depending on how you use the technology. However, with the above options, using Custom Apps in the long run will be the best option for your organization in my opinion as your company will not be able to leverage the latest security entitlements from Apple by using Enterprise signed applications. Hopefully this helps and happy coding!

Hey @jamfshome, I do not have much experience with Mac applications, but are you using an export options plist that has the UUID of a profile that should be found in the local store during the export process or some other method? Is the goal to have Xcode 100% automate everything on its own, or are you able / willing to have something like a helper script running in the local environment? Using the API Key approach assumes that you have the API Key in every environment where builds would be happening, but don't want to make any assumptions. Thanks!

Hey @IntelJohnny, Is it possible that the answer is as simple as changing the "destination" in your Export Options from "upload" to "export". It sounds like by "package up", that is where you are looking to take the application file, put it into an installer and then use the notarization service, but if you can share more information on what the goal is we will do what we can to help! Hopefully this helps!

Hey @joestone, What happens when you remove the Content Type header and the body data from the request to look like the below? curl --request DELETE "https://api.appstoreconnect.apple.com/v1/appInfoLocalizations/{APP_INFO_LOCALIZATION_ID}" \ --header 'Authorization: Bearer {TOKEN}' \ I am able to successfully hit the API and remove a localization when making the above request. I think it could be due to the fact that when you are making a DELETE request, the endpoint is not expecting to receive any data as a part of the request and interpreting it as something that is not supported (specific to Apple where other endpoints may support data in the body). Hopefully this helps and we can keep digging in if this does not solve it! Happy Coding!

Hey @DanDudeDev, Thanks for posting on the developer forums! Would it be possible for you to indicate how you are attempting to install the application on the device? Is this directly through Xcode, or via an exported Archive? It would also help to know the version of iOS installed on the mobile device in which you are trying to install the application so that we can attempt to replicate the issue. The first thing this makes me think of is the below post from Apple. https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format However, if you are using Xcode, Xcode SHOULD be leveraging the latest code signature when signing. If you have multiple versions of Xcode installed, this may not be the case though depending on the Xcode Command Line tools selected. You can check this by going to Xcode --> Preferences --> Locations --> Command Line Tools and making sure that 13.4 (13F17a) is also selected here. If this does not help, we might want to look at each of your project targets and the Signing section under Build Settings to determine if there is anything set that could be causing the issue. Hopefully this helps and looking forward to your feedback! Good luck!

Hello @anveshkamboj, Thank you for posting on the developer forums! If you are able to gain access to the iPhone and a Mac computer, you would be able to open the "Console" application and read the console logs as to why the application is unable to be installed. While I am not a Windows user, I recently saw an article that talks about how to get logs from an iPhone using a Windows machine. Below is the link to that article (as long as it does not get redacted). I cannot guarantee that this works so try at your own risk (I would suggest getting a Mac personally). https://emm.how/t/how-to-capture-ios-console-logs-on-windows-pc-ios-11-compatible/627 However, the error message that you are receiving generally relates to a code signing error. It is hard to know the exact error without being able to confirm through the logs, ut the below Apple article talks about how to leverage the latest code signing format if you are signing the application outside of Xcode. https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format If you are leveraging Xcode to generate the IPA file and you are leveraging a legacy version of Xcode, you may need to code sign the application AFTER your export from Xcode, install a more recent version of the Command Line Tools for use, or change the settings in the "Signing" section of the "Build Settings" for the target inside of Xcode before exporting. Hopefully this helps and happy coding! Looking forward to any feedback!

Hey @adriannanin, Thanks for posting on the Apple Developer Forums! I would suggest leveraging altool which is installed as a part of the Xcode Command Line Tools. As long as Xcode is installed, you will be able to find out more information on how to leverage this using the man page by opening Terminal and entering the below command. This one command line tool has so much power and should have a wealth of information to learn from along with search the internet on various implementation models. man altool I would recommend leveraging the App Store Connect REST API authentication method instead of user tokens, but user tokens are still valid if you would like to leverage them. I would also recommend always validating your applications before uploading them, but this is a legacy practice and not a hard and fast rule. If you have not heard of a tool like Fastline, there are many tools like it that support automated uploading to App Store Connect, but if you have unique needs or additional security concerns, writing your own solution may be of more value. https://fastlane.tools Hopefully this helps and happy coding!

Hey @anveshkamboj, Thanks for providing this additional information! Hopefully the link to the EMM site above will help with capturing the logs from Windows. Apologies that I am not a Windows user and able to help, but hopefully someone else will jump in! In order for the IPA file to be installed successfully on your iPhone, it needs to be code signed with your device UDID in the Provisioning Profile unless it is an Enterprise signed application. Do you know how the IPA file was signed? Below are the steps to figure this out if you or the developer do not know how it was signed. Unzipping the IPA file to see its contents unzip -d /New/Directory /Path/To/IPA.ipa Displaying the contents of the Provisioning Profile cat /New/Directory/Payload/*.app/embedded.mobileprovision If you see a section in the resulting output that shows "Provisioned Devices" then the application is either Development or Ad-Hoc code signed and if you did not provide your UDID to the developer you will not be able to install without signing it yourself or with the help of the developer. If you see a key value pair that indicates ProvisionsAllDevices, then the application is Enterprise signed, but the developer will need to update their code signature following the guide from Apple provided at the link below (same as above), or alternatively, you can sign up as a developer and go through the code signing process yourself which is a fun learning experience. https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format One thing to note is that if you go through the code singing process yourself, it is likely that the functionality of the application may break, so you will want to check with the developer who provided the IPA file and make sure they know you are doing this and if they know of anything that would stop working. Hopefully this helps and happy coding!

Hey @joestone, Thanks for posting on the developer forums! I am not sure if you are still encountering this error, but I did some looking, and in your posting it looks like the example string and the string in your example code are not the same exact string. I am pasting them below for reference. ตัวแก้ไข xliff, การแปลเป็นภาษาท้องถิ่น, เครื่องมือ xliff, xcode, การแปล xliff, xcloc, การแปลงข้อความ ตัวแก้ไข xliff, การแปลเป็นภาษาท้องถิ่น, เครื่องมือ xliff, xcode, การแปล xliff, xcloc, การแปลงข้อความ xliff Your first string is 100 characters exactly. However, your second string that is in the API request body is 106 characters which is too long. I am able to replicate the API error when using the string that is too long, but when I use the string that is only 100 characters I am able to successfully update the Keywords text using the API. I tested using both an English and a Thai localization to make sure there was not an issue with how the characters themselves were being handled in the API body. One thing to note that I take advantage of with Keywords in particular is that you do not need to include spaces after the commas as the string is broken apart by the comma and not a comma and a space (the space is wasted and still counts as a character). I would minify your strings to look like below. ตัวแก้ไข xliff, การแปลเป็นภาษาท้องถิ่น, เครื่องมือ xliff, xcode, การแปล xliff, xcloc, การแปลงข้อความ <- 94 Characters ตัวแก้ไข xliff, การแปลเป็นภาษาท้องถิ่น, เครื่องมือ xliff, xcode, การแปล xliff, xcloc, การแปลงข้อความ xliff <- 100 Characters Both of the above strings are accepted by the API and accomplish what you are trying to do I believe. Hopefully this helps and happy coding!

Hey @Xia Jian, Thanks for posting on the Apple Developer Forums! I believe the reason that you are experiencing the behavior in which you are is that by default, applications should support iOS, iPadOS, and possibly macOS next week after WWDC. This is driven by the App Store Review Guidelines and iPhone applications running in compatibility mode. https://developer.apple.com/app-store/review/guidelines/#hardware-compatibility 2.4.1 To ensure people get the most out of your app, iPhone apps should run on iPad whenever possible. We encourage you to consider building universal apps so customers can use them on all of their devices. Learn more about Universal apps. However, if your application is leveraging a device capability that is only available on iPhone (i.e., HealthKit) then an iPad will not be able to technically install your application, meaning that it will not show up in the App Store for iPads as an install option. https://developer.apple.com/support/required-device-capabilities/ This does not guarantee that iPads will not be able to install your application in the future though, so I would suggest spending the time to design your application to support iPad. We know the long term goal of Apple is to make it easy for consumers to use our products on all of the Apple products they own so designing with this in mind will set you up for success. Hopefully this helps and happy coding!

Hey @rlecheta, I have run into this issue before and the way that I solved it was by leveraging the below command within my automation scripts. This is an implementation of what @eskimo suggested with a different flavor. security set-key-partition-list -v -S apple-tool:,apple: -s -k [Login Keychain Password] [Login Keychain Path] I did not figure this out on my own and had the help of many previous developers with the power of the internet. Additional reading and learning can be found at the below URLs. https://apple.stackexchange.com/questions/255872/unable-to-unlock-login-keychain-on-sierra-in-ssh https://stackoverflow.com/questions/24023639/xcode-command-usr-bin-codesign-failed-with-exit-code-1-errsecinternalcomponen https://mostlikelee.com/blog-1/2017/9/16/scripting-the-macos-keychain-partition-ids I would also suggest like @eskimo did that you use key based authentication for your remote SSH connection and leverage additional logic for protecting either your login keychain or using a separate less important keychain all together. Hopefully this helps and happy coding!

Hello @svedm, Thanks for posting on the Apple Developer Forums! Have you already requested this entitlement the developer account that you are signed into when trying to access the page? Have you tried to load the page in a private browser (i.e. private mode on Safari)? I have found that Chrome specifically and other browsers have issues with XSS tokens and this causes issues sometimes when a page is protected by authentication so I would try it in a private browser window and see if you get different results. Hopefully this helps and happy coding!

Hey @Mike-in-NM, Thanks for posting this question on the developer forums! One way to confirm which iOS SDK your application is actually being compiled with is by checking out theInfo.plist from the compiled binary and checking what is being injected. The Info.plist would be found at the below path. /Path/To/Archive/Archive.xcarchive/Products/Applications/*.app/Info.plist You would want to check what the value of DTSDKName is set to. If this is not iOS 15.5 like expected, then the file is not being compiled with the iOS 15 SDK. If this is the case, one thing to check would be your Command Line Settings under Xcode --> Preferences --> Locations --> Command Line Tools and make sure the latest version of Xcode Command Line Tools are selected. Hopefully this helps and happy coding! Let us know what you find out!

Hey @taktem, Thanks so much for posting on the Apple Developer Forums! I had never worked on this before now so I was tinkering around and I think I found what could be holding you up (or at least what held me up). The first issue that I ran into when trying to figure this out was that the App Store Connect API documentation appears to need some updating. I have filed a feedback for this (FB10036380). You will need to update your "scope" to the below code example. “scope”: [ “GET /builds/{id}/app” ] Currently, including the /v1 as a part of the scope path will return an error from the App Store Connect API which does not match their documentation. By removing the /v1 things started to work for me. There are many ways to accomplish what to put in the scope path, and I have not fully tested if the API accepts wildcards, but in this specific example, you would need to have some information beforehand or you would need to dynamically generate tokens on the fly and return them to the system wanting to make a request. A bit past the scope (no pun intended) of this response but I will give you one example. In order to limit the scope of the Read the App Information of a Build API, you would first need to know all of the Build IDs and include those in the array of the scope permissions. To do this, you would need a JWT without a scope limitation to hit the List Builds API and then find the IDs from the response and generate a new JWT to be exchanged for a token. Below is an example of what this would end up looking like (IDs are fake and generated by uuidgen). “scope”: [ “GET /builds/4E01297D-1D43-4020-B21C-9DC94A40579B/app”, “GET /builds/A72021D3-8712-445D-9585-B847BBCCA362/app”, “GET /builds/65E73521-ED9A-4F06-9C5D-44B54BB34ED6/app”, “GET /builds/1FAC0D8D-4FD5-4ECD-9B84-D1422ADE3003/app” ] There are many ways to go about achieving what you are looking to do so I would explore how to implement this logic upstream as a part of an initial request, but that is just how I like to build things. Hopefully this helps and happy coding!