'last write wins' does not refer to modificationDate it refers to the order of the write - and that is exactly what would happen if you chose CKRecordSaveAllKeys here:https://developer.apple.com/documentation/cloudkit/ckrecordsavepolicy?language=objc

> The code I'm writing is the part that tries to resolve/merge the conflict (ideally without user interaction) after the conflict is detectedI was answering the question 'do we need a local modificationDate field' - you don't. Again - time (modifciationDate) doesn't matter, version does. CloudKit already has a serverRecordChanged error that compares version downloaded and version being changed, not times, and warns the device that there is a conflict. That's the answer to the question asked.Now, what to do when you detect a conflict? As you indicate, there are lots of ways of handling it. But none of those ways depends on modificationDate.

App B creates a schema and App A executes a canOpenURLhttps://developer.apple.com/documentation/uikit/uiapplication/1622952-canopenurl?language=objcto detect whether App B is on the device. If it is not there you show a screen indicating App B is missing and ask the user if they want to go to the App Store to download it. If they do then you do a[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"https://itunes.apple.com/app/idYOURIDHERE?"] options:@{} completionHandler:nil];

Are you really sure that "logging out of the user's Apple ID" is required? Usually just deleting the app and reinstalling works. That will wipe out all local files. Nothing will wipe out the keychain data so it is unclear what you gain by forcing the user to log out of their Apple ID.But ask your developer what files need to be refreshed. And create an updated version of the app that does that on first install so that you do not need to do this nuclear reinstall but rather rely on the app refreshing the files itself. The app detects its current version number - if it is not the new version it rewrites all app files on the device, on CloudKit and even resets the keychain at the same time writing its new version number somewhere. It's not that hard.

The receipt indicates that the user cancelled the purchase. Such cancellations are rare but you've found one.- An user purchases a one month subscription for accessing to some contents by few days later he ask for a refund to Apple.This is what your receipt indicates.- An user purchases a one month subscription for accessing to some contents by few days later Apple rejects the payment.Apple rarely rejects a payment a few days later. But I would assume that if they did, it would generate a cancellation_date field in a new receipt.

Have you tried calling exit(173) to force a login?

The receipt's in_app_purchase array will be empty if the product is a consumable and the device has called finishTransaction.You get a new receipt on the device (with in_app_purchase array filled in with latest purchase) after StoreKit calls updatedTransactions.You might want to explore the app "Beat The Stock Market".But..."That's why any delay in purchasing process creates serious disadvantage in user status." - there is at most a few second delay in any purchase and the call to updatedTransactions.

Keep in mind that what is more important than the 'time' of any change is whether or not the version that a device thinks it is changing is the current version stored in CloudKit. That is the purpose of the logic behind:https://developer.apple.com/documentation/cloudkit/ckmodifyrecordsoperation/1447488-savepolicy?language=objchttps://developer.apple.com/documentation/cloudkit/ckerror/2325208-serverrecordchangedYou can certainly use your own system, but focus on version number not absolute timingDevice 1 downloads version A of a record (e.g. you have $100 left in your account)Device 2 downloads the version A of the record (e.g. you have $100 left in your account)Device 1 makes a change in version A and saves it as version B (e.g. debit $20 from $100 - you have $80 left in the account)Device 2 makes a change in version A and saves it as version C (e.g. debit $10 from $100 - you have $90 left in account) CONFLICT!! - device 2 is making a change in a record that is outdated. And error should be sent to device 2 telling it that its change may be incorrrect.

(interestingly - I thought I posted this last night...here it goes again...)Another approach is to use a daisy chain.User's A, B, C and D create two Matches. One amongst each other and one with 3 other users:Matches:ABCDAEFGBHIJCKLMDNOPWhenever users A, B, C or D receive data in one of their matches they immediately transmit teh data to their other match. Whenever A, B, C or D wish to transmit data, they send it out to both matches. In your case, to get to 30, you would need users EFG and HI to do the same thing.

>allows individual contributor to sell their digital content like audio, video.Will these contents, once purchased, be used within the app? If so, both flows are a violation of the guidleines and your app may be rejected (aka should be rejected, aka most likely will be rejected - but no one can predict....). If 'played in Webview only' in flow 2 means - played outside the app, then you may not be in violation of the guidelines although this depends on whether App Review will consider a digital good as a "Goods and Services used outside the app"

You could consider operating under these guidelines:3.1.3(a) “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: ...... VoIP....), provided that you agree not to directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods are not designed to discourage use of in-app purchase.or3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired in your app on other platforms or your web site, including consumable items in multiplatform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.[added with edit....]Regarding your questions1. Does IAP applies to every transactions being made by users? Yes3. Is it allowed to redirect users from app to website when performing payment activities? Since what you want to do is sell VOIP to use within the app, you must use IAP within the App and you may not suggest, within the app, that the user can get a discount outside the app. But you can allow the outside-the-app purchase to be used within the app as per these guidelines.

I read below that you wrote "Thanks, I think I will use subscription in case of furher rejection."A subscription expires after a certain time period. Does your 'consumable license' expire after a certain time period?

since this is no longer about CloudKit, close this thread by marking the suggestion above that you convert to Game Center as correct.

> can rely on apple webhook call API to renew the subscription?based on the number of issues that have arisen over the past months, 'rely' - no, you can't. You need to have a means for the user to restore their subscription if your 'reliance' fails.

>But, WKWebView can not support URLProtocol...It can.....https://developer.apple.com/documentation/webkit/wkwebview/1414954-loadrequest?language=objc