5.1.1

If you add your device UDIDs to the provisioning profile, your apps should run on your own devices. (Providing you deploy apps ad hoc - old Xcode won't recognize new iOS devices, so you won't be able to install or debug directly from Xcode). But you cannot submit to the store unless you use recent Xcode versions. The minimum requirement for app store submission may still be at Xcode 5.1.1 / iOS 7 SDK for now but will be changing to Xcode 6 / iOS 8 SDK any day now if it's not already.

Somebody on stackoverflow had this to say:It is an Xcode 7.0 and 7.1 issue when linking to patch versions of iOS. When using -miphoneos-version-min=5.1.1 with linker, it will only respect major+minor parts (5.1) of the version.And another person on the same thread said: This appears to be a known bug in Xcode 7.0 and 7.1B1 (bug #21813082). (He provided no actual link to the bug report, however.)The problem still appears in Xcode 7.2. It seems that Apple doesn't feel like this is a high-priority issue. It's extremely annoying, though.

I tried to submit app build in XCode 7.0 two weeks ago, and saw similar error. Now i'm submitted app built in XCode 6.4, and submitted by https://github.com/nomad/shenzhen (because XCode 6.4 crashes during submission on 10.11 beta 5) it's approved for beta testing, but I can't send it to apple review with error mentioned earlier: Apps and app updates submitted to the App Store must be built with Xcode 5.1.1 or later, and iOS 7 SDK.Seems like itunes connect bug for me.

>all they need to do is install the app and log in.......What is the point of restoring anything?I believe all you need do is indicate in a note to App Review that you handle 'restore' through log in to your server. There is no need to do anything else.But......this means that the user is required to log into your server to 'use' the IAP. Therefore you will need to explain why you are also satisfying: 5.1.1 (v) Account Sign-In: If your app doesn’t include significant account-based features, let people use it without a log-in. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app.....

Instead of certifying a domain - can we certify specific email addressed ? The setting does not seem to work for that.We are using a DNS setting to send emails from Mailgun that appear as mg.pettingclub.com . However we cannot load the txt signature file to that domain because obviously the mail server is at Mailgun.So we tried instead to set the Individual Email Addresses settings, but any address we added to it - does not seem to work. Not info@pettingclub.com , nor any gmail address we tried. For example:550 5.1.1 Relay not allowed for <xxxxxxxxxx@privaterelay.appleid.com> from domain: <gmail.com>Is there a problem with setting up individual email addresses?

According to Apple one must build kernel extensions against the SDK for the lowest OS version they are to support. See WWDC 2013 session 707 What's New in Kext Development. In your case this would be the 10.8 SDK. You were just lucky that the kext built with Xcode 5.1.1 and the 10.9 SDK worked on 10.8. The trick with setting the deployment target to a version lower than the SDK only works for userspace code. This makes things difficult for kernel developers that need to support older OS version since we are forced to use old Xcode versions, on old OS's, on old hardware, for developement.

Are you able to specify what aspect of third-party mail services prevents their use? We have DKIM and SPF set up for our whitelisted SIWA domain, but don't have a reverse DNS record set up for the IP we're using (a dedicated IP used primarily with a different domain), and are getting 550 5.1.1 bad mailbox name responses. It seems like a third-party mail service with a dedicated IP and rDNS would be indistinguishable - from privaterelay.appleid.com's point of view - from running our own MTA.We can certainly set up rDNS if that's a requirement, but otherwise this is a pretty big blocking restriction for SIWA.

Hi @robevans, Please see the following documentation for more information: Configuring your environment for Sign in with Apple https://developer.apple.com/documentation/sign_in_with_apple/configuring_your_environment_for_sign_in_with_apple#3743946 For Sign in with Apple, the Private Email Relay Service is used to communicate to the private email addresses that users opt-in to providing your apps. As long as your email sources and domains are properly registered and their SPF and/or DKIM authentications are validated, there should be no message delivery issues. However, If there are configuration errors, you will receive a bounce back with a 550 5.1.1 Relay not allowed for or similar. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

I understand that a user can delete their own Passkey through Settings, but guideline 5.1.1(v) dictates apps that support account creation must let users initiate deletion of their account within the app. As Passkeys, and thus an account, can be generated from within the app - the requirement here means we need to be able to delete them from within the app too. This means programmatically - with validation to ensure we can only delete our own passkeys, and indeed ensuring that the user wants to delete it (with a modal). Also, with the ability to delete a passkey (and presumably their only way of accessing their account) outside of the app, it leads us with orphaned accounts. Accounts which exist on the server but the user cannot access. What is the best pattern here?

I am not part of the App Review team, but the only accepted way to use a customer service flow (like contacting the user support desk) for account deletion is if your app is used in a highly regulated industry. I was told by App Review that the fields given as examples in App Store Review Guideline 5.1.1(ix) - highly regulated fields (such as banking and financial services, healthcare, gambling, legal cannabis use, and air travel) - are the only fields that Apple considers to be highly regulated. As long as Apple considers insurance to be a financial service, I would think that your plans for account deletion would be acceptable. I'd email Apple directly to confirm just in case.

Update: I now think that this is due to a serious bug affecting users with an iPhone 6 Plus. Apparently many watch apps cannot be installed from that device running iOS 12.1 to an AW4 running watchOS 5.1.1. This is exactly the combination one of my users has, and I have another review mentioning it in the Netherlands, so I no longer think it is country specific.This is a serious issue that seems to be affecting many apps, such as Spotify, Shazam, Nike Run Club, PCalc and more: https://devandartist.com/posts/apps-not-installing-on-the-apple-watch-or-error-17If anyone from Apple monitors these forums then please take a look - this is a very serious problem for watch app developers.

I can no longer submit apps with Xcode 6.4 (6E35b), which is a GM, Appstore version, Xcode7 is not installed on my system. On submit for review i get Apps and app updates submitted to the App Store must be built with Xcode 5.1.1 or later, and iOS 7 SDK.Regardless of what apple says, this has never been a problem. It doesn't even make sense, as the build system of Xcode, and the command line tools for building should be contained. If this is not a regression, developers who want to prepare for future releases we now need3 iphones (current release, 8.4 train, 9.0 trains)2 osx devices (current release, el capitan train)2 apple watch devices (current release, watch os2)😐

When the app was submitted for the first time, apple has rejected the build with the following message:Per section 5.1.1 (ix) of the App Store Review Guidelines, apps that provide services or collect sensitive user information in highly-regulated fields, such as healthcare, should be submitted by a legal entity that provides these services, and not by an individual developer.Which refers to,(ix) Apps that provide services in highly-regulated fields (such as banking and financial services, healthcare, and air travel) or that require sensitive user information should be submitted by a legal entity that provides the services, and not by an individual developer.I remembered that I have selected the Air Travel previously, which is not the Category in the App Information section because I chose Lifestyle as the main category without choosing the secondary option.

I don't use Xcode, but I know how to set the min iOS level. Mine is set to 5.1.1. I think I was wrong about armv7 affecting the min OS. I'm still not sure where I thought I saw that minimum OS version now... it wasn't when uploading via Application Loader, anyway.I use these two charts to determine device compatibility:http://iossupportmatrix.com/http://28byteslater.com/ios-compatibility/My app is unreleased. If it was released, I could visit iTunes on a Touch 4 and see if they'll let me buy it. If the Touch 4 could run TestFlight I'd also be able to tell that way. You're right that anyone can buy an app via iTunes on their computer, but I don't think they can give it a 1-star review unless it actually installs on their device.