I came across this post to implement sign in with Apple on iOS 12. Apparently, the two answers (from @ppinkney  and @dima_beliy) are in conflict: For iOS 13 and later, macOS 10.15 and later, tvOS 13 and later, and watchOS 6 and later, use the AuthenticationServices framework as referenced here. For iOS 12 and earlier, macOS 10.14 and earlier, tvOS 12 and earlier, and watchOS 5 and earlier, as well as web applications which cannot directly access Sign in with Apple JS framework, you must manually control the sign-in request as referenced here. For web applications which can directly access Sign in with Apple JS, use the Sign in with Apple JS SDK. For communication between your web server and the Apple ID servers, use the Sign in with Apple REST API. The above implies that Apple JS isn't for pre-iOS 12, but rather for other platforms. Apps with SDK version below 13.0 can use Sign in with Apple JS. The above states otherwise. Are they the same? Looking at the docs, it does not look like that. As I last checked, App Review guidelines do not speak about this point at all. In any case - I followed the link in the @ppinkney's post, - https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/incorporating_sign_in_with_apple_into_other_platforms and I get that in order to authenticate using Apple: GET (with params) must be issued to https://appleid.apple.com/auth/authorize using Safari (native iOS openLink API) The developer server callback URL will receive a POST or QUERY in the safari, wherein code and id_token are contained. At this point, past verifying the id_token, control must be handed back to the app. Is this understanding correct? If yes, according to this: there should not be any calls to token verification endpoint - https://developer.apple.com/documentation/sign_in_with_apple/generate_and_validate_tokens Also, none of this can be performed in WKWebView and must be done via Safari? This is the most confused part of the documentation and is also crucial for managing our apps. If our app gets disapproved because of this, it is very time consuming to re-engineer, as it pertains to server code. It will be desirable to have proper clarity on the steps involved. AuthenticationServices is great, but it just doesn't serve pre-iOS 13, where it is too easy to go wrong.

thank you for the answers! I have small doubt - As for your answer about scenario where 2 app store IDs are associated with single appuser. Terminology: App user is U. App Store User A on device D1 - purchases product P. A's receipt is stored on my back end server. U signs in on different device D2 with App Store User B (same app user U is logging into the app) Upon login, U knows that he has purchased product P from back end server. But U has no knowledge which app store user did purchase. So, he is prompted to restore, before unlock on newer device. U gets B's receipt (empty), not A's receipt. So B's receipt will also be stored on the back end server, associating it with user U. But since U has paid for the content already(through App store user A), it does not matter to consider B's receipt. It will just lie on the back end for the records. Unlock on D2 for P will happen because server knows U has purchased P. App store's truth about B will not matter at all. So effectively, restore did nothing on D2. Is this correct? (This assumes that every receipt is stored on the back end server as your answer suggests that too)

Also relevant is the ideal state management with respect to promo offers. Current entitlement engine provides offers as part of receipt verification - in the process it might be bit time consuming call storing subscription + offer data on back end while verifyreceipt endpoint has just returned from apple. Also a concern would be, how to reset promo offer pending status on the server? promotional_offer_id I know the above tells about it within the receipt. This means that all such operations have to be tied up with verifyReceipt?

As I just tried with my YET UNPUBLISHED + UNREVIEWED app now: I can no longer change a bundle ID, the dropdown is simply grayed out for me If I delete the app to free up the bundle ID to be removed (to recreate it further) - it doesn't work. Removed apps remain in removed apps section, where they can't be deleted permanently. So if someone tries to create arbitrary app IDs (even for testing functionalities like IAP and Leaderbaords) but later decides not to publish them, they STAY - never to be recovered back. As of this writing, App store connect does not support creating an app ID with com.mycompany.myfavoriteAppId citing that this bundle ID is not available - even though I know that I have not used myAppId in any of my apps. Does it check myfavoriteAppId availability across app store? I have no idea. To be fair, App Store Connect is the most cumbersome piece of task in iOS development - due to poorly designed API, too much navigation, CRUD operation bugs, lack of command line / GUI based deployment tools (they just took away iTMSTransporter API - as of now there is NO KNOWN WAY of uploading bulk IAP to app store connect except for MANUALLY creating them.