Post not yet marked as solved
I have the same problem and I am seeing other related issues in different forums. Moving away from cocoapods is not viable for me right now. Can I still do archive releases from the 14.2 xcode if I download it from the developer portal, I know in the past sometimes you cannot release from those versions and this is holding up getting out updates. Anyone else come up with other fixes for this? It looks to be a symlink issue fo some sort. Maybe removing intermediates or something. I will update back here if I figure anything out.
The issue magically resolved itself when we attempted again yesterday. Appears to have just been a bug on the site.
I apologize, "one of them result in a successful creation" should read "NONE of them result in a successful creation". I don't see a way to edit the question. I also have a screenshot of the error that I can throw up on s3 if anyone is interested in seeing it.
Post not yet marked as solved
Just to update here as well, Apple did end up updating their criteria in 4.8 as shown here appstorereviewguidelineshistory.com/ and they have removed the word "exclusively" on March 4th. This now makes all apps that offer any third party logins along with their own authentication to be required to implement Apple Sign In. I did not catch this and was just rejected for not having it. Luckily we implemented this just in case, though it will still take some time to get it merged back in and go through QA.
Post not yet marked as solved
I got them sorted out yesterday. Does seem to build quicker now.
Post not yet marked as solved
Migrating to the new build system also is requiring a lot of work currently and does not build my project without errors. Is there no plan to fix this for the legacy build system and we should just count on it the legacy build system no longer being supported?
Post not yet marked as solved
I am having the same issue. There is also no longer a setting in Build settings for "intent class generation language". The custom intent class is never generated. You can tell by looking in your intent definition file and selecting the custom intent, then in the identity inspector, you normally see an arrow in the "Custom Class" field that will show you where the generated file resides. It is gone, so just like that, updating Xcode has stopped all progress as we try to resolve this since we can no longer build the project without tearing out all references to the custom intent. One thing to note, my custom intents were all being generated in Objective C since my project is 11 years old and mostly in Objective C. Anyone having this issue that has them generated in Swift? I was thinking of trying to just rewrite them all in swift. I will update here if I find a work around. Hopefully Apple can respond to this soon and provide some guidance.
Post not yet marked as solved
My app has been experiencing this same issue since WatchOS6 and iOS13 release. The only solution we are able to give our users is to uninstall from their watch and install it from the watch app store to ensure they have the latest version. I was really hoping that Apple would have fixed this by now.
Post not yet marked as solved
I am in the same boat (wow Apple really has been botching things lately). XCode 11.2.1 does not show up in the app store unless you update to the very latest version of Mojave first. If you try to download it from the appstore by using the link in the developer portal, it will give you an error that there is not enough disk space to install the update (no matter how much disk space you free up, I had 160 something GB). The only remedy was to update Mojave to the latest, then install the new XCode.Heads up: If you have an Apple Watch App, you may want to check it on the new WatchOS6.1 as well, it completely broke some of our UI for the version that was already released.
Post not yet marked as solved
I'm actually not sure how some don't see this as ambiguous. My internal team have all read it and agree that it has conflicting criteria. As the original poster stated, Apple gives two conflicting statments.1. "You must if you offer exclusively third party sign on" - I don't fall in this category, because I offer my own authentication and third party sign on. Okay I don't have to offer this.2. "You don't have to if you offer exclusively your own authentication" - Hmmm, I also don't fall into this exception since I don't offer exclusively my own sign on. Since I don't qualify for any exemptions listed, I would assume I do have to implement Apple Sign On.So I don't have to implement sign in, although I don't meet any of the exemptions that would allow me to not have to offer apple sign in.If the wording is incorrect as suggested by PBK, then it would be clear that we have to implement this if the word "exclusively" were removed.My apps were existing and have been through 2 reviews each since iOS13 without Apple Sign On, though the enforcement for existing apps won't happen until April 2020. The dev work is done, we just have it sitting in a branch in case we need to pull it over. I'll keep checking to see if they update the guidelines and update here if so.
Post not yet marked as solved
I am in the same situation. The review guidelines are ambiguous as there is a "You are required if" statement that says only if you offer third party sign in exclusively. They then go on to define a "You are not required if" statement that says you are not required if you only use your own own authentication exclusively. This leaves all apps that offer both their own authentication and third party authentication to fall into neither category and is therefore ambiguous as to what the rule is. My whole team has read it and we have no idea if we have to implement this. When Apple Sign in was announced, they stated that it would be required for all developers that use a third party sign in.
Post not yet marked as solved
This may not be the answer anyone wants to hear right now. I know for me, this delayed getting a testflight build to a large parter for integration testing by 4 days. So, in further researching this and based on the clues above about the iOS SDK no longer showing in the docs online. I looked through the class in the latest version of Xcode and viewed my docs from within Xcode. WKInterfaceDevice shows iOS SDK 8.2 and up. We then downloaded the latest beta version of Xcode and lo and behold, we can no longer even #import <WatchKit/WatchKit.h> into our iOS project files. Only from the watch extension and app. It appears that Apple is planning to remove access to this in the next release and somehow is already holding code to that standard in code analysis. I would guess that they will fix this and we will still have to react to the change before the official release, but if you want to just get up to date now, you should maybe have the watch app send the iOS app the information that you need about the device and audit your application for other previously supported WatchKit code. I can confirm that removing WatchKit references from the iOS project files has resulted in a successful upload to Apple and we are back to testing at least. So even if you are accessing only items that are documented to be accessible from within the iOS application, it appears that they are considering them private now based on a yet to be released version. So frustrating.
Post not yet marked as solved
We are having the same issue. We can't even upload for testflight testing and Apple so far keeps routing my inquiry to different departments. I will update here if I ever get an answer or if I notice this gets fixed.
