Post

Replies

Boosts

Views

Activity

SKDemo SwiftUI subscription example shows misleading renewal info
I have been trying to setup device based subscriptions in my app using SKDemo from WWDC session (2021-10114) When I try to change the subscription from yearly to monthly, the screen shows misleading renewal info date. Inside StatusInfoView struct, there is this renewalDescription function: fileprivate func renewalDescription(_ renewalInfo: RenewalInfo, _ expirationDate: Date) -> String { var description = "" if let newProductID = renewalInfo.autoRenewPreference { if let newProduct = store.subscriptions.first(where: { $0.id == newProductID }) { description += "\nYour subscription to \(newProduct.displayName)" description += " will begin when your current subscription expires on \(expirationDate.formattedDate())." } } else if renewalInfo.willAutoRenew { description += "\nNext billing date: \(expirationDate.formattedDate())." } return description } On Mar 22, 2023 subscription purchase date, it goes into the renewalInfo.autoRenewPreference part, and there, it prints something like: "You are currently subscribed to Monthly.\nYour subscription to Monthly will begin when your current subscription expires on Apr 23, 2023." This is misleading, because it seems to talk about two different subscription options, but actually talks only about single one - monthly one. If the user switched from Yearly to monthly, the message should be like: "You are currently subscribed to Yearly.\nYour subscription to Monthly will begin when your current subscription expires on Mar 22, 2024." However, if the change happens from smaller to higher subscription, it seems to respect the pre-existing older subscription date before starting the newer subscription. Another problem with the example SKDemo is that the StatusInfoView fails to update subscription checkmark sign i.e. upon scrolling up and down, it shows the Buy button enabled. What am I missing? Thanks in advance,
0
0
461
Mar ’23
Auto-renewable subscription - confusion about source of truth
Apple's latest WWDC entitlement engine presentation - https://developer.apple.com/documentation/storekit/in-app_purchase/subscriptions_and_offers/determining_service_entitlement_on_the_server is quite useful as far as converting receipt into subscription + entitlement data. I am using it in conjunction with my own server verifyReceipt endpoint and store subscription data on server, along with original transaction id + user id. First, terminology for below situations: appuser = user login for my own app appstore user = user login for iTunes / appstore However, I am confused on a few things: What should be the source of truth? For entitlement engine to work, receipt must be sent to server. If appuser signs in on Device A, purchases product P, then signs in on Device B, no / empty receipt will exist on Device B. Obviously, this appuser will download subscription data I stored on server during previous verifyReceipt call. Is this OK? How do I know if my server knows the truth about this appuser? Should this be restoreTransaction flow, or simple REST call? If my server holds latest subscription data based on receipts, what should restoreTransaction do? Also, if appuser remains the same, but appstore user changes (different itunes id) - what is the way to tackle? 1 - Is Apple OK if I allow access to purchased content via this appUser but different appstore user who never purchased it? 2 - Vice versa, if appuser is altered, but appstore user remains the same, what is correct entitlement? Does Apple has any say on above 2 scenarios or is it just me who gets to decide? Probably too many questions, but it is bit confusing in conjunction with storekit callbacks (transaction observers etc) and I am wondering if there is well-established universal approach other developers are following....
3
0
955
Jul ’20