OK I'm working on a app where the user purchases the app from the App Store, gets access to the app for a year, and then after the year has passed they are sent to an In-App Purchase screen where they can purchase a subscription for continued access.
(this is not the subscription model I'd implement if it were up to me, but the client insists that it follow this model)
In order for it to work, though, I need a reliable way to check when the app was purchased, in order to calculate when the first year of access ends. Following the suggestions in one of the answers in...
iOS App Purchase Date
...I've gotten the app receipt and I can find all the data fields that the documentation says there are, but there are also a few others including "original_purchase_date" (not the one in the IAP receipt array; the one for the app receipt itself). This would appear to be what I want. However this field is undocumented.
As far as I can tell, Apple security operates via a form of "Security Through Obscurity/Diversity", so it's been difficult to find further information about these undocumented data fields. My concern is that I might use the data from this field, and then discover that it was only there in sandbox mode and actual receipts don't have it. Worse, what if I reference that field and then Apple releases a new iOS update that completely discards that field from its implementation? Undocumented features are even less reliable than deprecated features, after all.
My question is this: is there a reliable source of information somewhere where I can find out what Apples intends regarding this field? Or better yet, is there another, safer way of achieving the system my client wants?
You have to implement it as a free app that requires a subscription IAP. Paying for an app cannot be its subscription cost.
Check rule 11.12 here: https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
Apps offering subscriptions must do so using IAP, Apple will share the
same 70/30 revenue split with developers for these purchases, as set
forth in the Program License Agreement
Implementing it the way your client wants will result in rejection.
Related
Is there any way to implement conditional logic for payments in Swift? For example:
Say the user has agreed to have 10$ withdrawn from his bank account he connected to his app account if, on a specific day, he has not fulfilled a condition that can be tracked with the app.
If he fulfills the condition until 23:59, no money will be withdrawn. If he doesn't, at 00:00 on the next day, the 10$ are automatically withdrawn from his bank account.
I don't know of any app that does this and I'm not even sure whether an app like this would be permitted on the app store. I'm not even sure whether that's technically possible.
Would be thankful for any helpful input!
Using the in-app payments system (a.k.a. iOS in-app purchases which utilise the StoreKit2 or StoreKit API) this not feasible.
Explaining how in-app purchases work would be a bit tedious.
However, to put it simply, you can basically initiate either a one-time payment request, or a recurring payment request.
In each of these scenarios, the user may obviously either make the payment or decline, about which you would get updated in code.
The closest the system comes to what you are asking for is recurring payments (technically called the auto-renewable subscriptions).
However there is no way to ask Apple to conditionally deduct money based on whether the user has performed some action or not.
I'm pretty sure you should not be looking at the iOS in-app purchase system as a way to do what your are looking for.
You could use 3rd-party payments.
However, whether Apple allows this, would depend on what kind of condition you expect the user to fulfil. If it relates to a real world service or material, then you may be able to justify it to Apple, however, if it is a digital service, lets say an app based activity, such as opening the app a given number or times, or viewing the app for a given amount of time, then I'm pretty sure this would be in violation of the Apple App Store Guidelines and they would reject your app when you submit it for review.
To be honest without understanding the use-case a little more clearly it is a bit difficult to advise you on the technical feasibility.
I know, that this question is not directly related to any coding but there are several other question on SO about the App Store and its Guidelines. So I assume, this question is OK.
There are other questions about (more or less) the same issue. However they where asked / answered several years ago and the Guidelines have been updated since then. Additionally the circumstances are always a little bit different.
I am well aware, that nobody can give me any kind of guarantee on which interpretation of the Guidelines is correct. Not even Apple could do this, since everything depends on the review staff an its current mood. However It would help a lot get to know your opinion on what is allowed and what is not. Maybe you already encountered the same problem and have some useful recommendations.
The set of facts:
A Shopping List app is offered in iOS App Store. The app offers functions to create and manage any kind of shopping list. These functions do NOT depend on any external purchase. The fee version limits the number of lists. This limit can be unlocked using an In App Purchase.
There is also a WebApp version that offers the same functions (and a little more) as the iOS version. The WebApp has a one month free trial and can then be extended using a subscription model. Subscriptions can only be ordered within the WepApp, not from within the iOS app.
Both version can be used completely independent from each other.
Additionally the apps can be connected (REST API) to sync lists between them.
Obviously there are pages/controls within the iOS App, that allows to setup the connection (enter username, password, etc.).
Obviously the WebApp has to be described in some way to the user within the iOS App.
Once the free trial ended or a subscription has expired, the sync will no longer work. In this case the user needs some kind of hint why sync is no longer available ==> There has to be information about the subscription model of the WebApp and a discription on how to renew the subscription.
The "Problem":
The current App Store Guidelines are pretty vague on wether this kind of business model is allowed or not:
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions,
in-game currencies, game levels, access to premium content, or
unlocking a full version), you must use in-app purchase. Apps may not
include buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP.
This paragraph is not as clear as it my appear on first sight. Unlocking functionality within your app is only allowed by using IAP. Fine, so unlocking a app feature (e.g. creation of more than 2 shopping lists) would be not allowed. But is the sync functionality I described before also covered by this? Of course there has to be functionality within the app to connect to the WebApp, but the complete sync logic is implemented on the server, not in the iOS app.
The functionality the iOS app offers is "Establish a connection to the WebApp". This functionality works independently from wether the WebApp subscription is active or not. Only the functionality of the WebApp changes depending on the subscription status (accept or deny sync requests).
So: Is it allowed to add some text like "There is a WebApp, too. Use this link to got to the WebApp. Follow this link to renew your subscription" to the WebApp or not?
Or is the part "Follow this link to renew your subscription" forbidden?
What makes the whole thing even more confusing is the following paragraph form the Guidelines:
3.1.5 Physical Goods and Services Outside of the App: If your app enables people to purchase goods or services that will be consumed
outside of the app, you must use purchase methods other than IAP to
collect those payments, such as Apple Pay or traditional credit card
entry. Apps may facilitate transmission of approved virtual currencies
(e.g. Bitcoin, DogeCoin) provided that they do so in compliance with
all state and federal laws for the territories in which the app
functions.
Does this read as "Physical Goods and physical Services" (e.g. postal delivery in contrast to digital Services) or this include all Services?
So, is the "WebApp Sync Service" covered by this paragraph and thus the usage of external payments not only allowed but necessary?
Of course I could ask these question directly to Apple. But I would never get an answer. Even if I would, this would still be no guarantee, that the review stuff shares the same interpretation of the rules. So your experience and opinion will be the best "guarantee" I will ever get.
Thank you very much!
Have any of you implemented something similar to the below scenario?
Consider an app which provides audiobooks:
The books are maintained dynamically from a web based UI by the authors.
The books become available for users of the iOS app, as in-app purchase items.
By default Apple guidelines suggests using non-consumable IAP, and adding continuously as many IAP items as many books we have. But this is not proper for us, as the authors won’t have access to iTunesConnect, so it cannot be dynamic, “self-serving”.
Therefore we are planning to create a set of generic "consumable" IAP items like “Book worth $0.99”, “Book worth $1.99”, and so on. Then in the app we’ll show the corresponding IAP item for the books as specified by the authors, when they added it to our system.
Of course we store the purchased items on the server side, so the user will always have access to the purchased items -- even if they access it later from another device.
Will Apple approve this implementation?
Does it fit with their IAP policy?
I’ve found some similar quite old topics in the forum but the answers were confusing.
Have you implemented something similar and get approval from Apple?
Apple has accepted our solution, as described in the question.
The point is, as highlighted correctly by #RomOne and #ge0rges that you need to provide the possibility to restore the items later.
As we are storing every purchase in our database, and our users are authenticated (they need to register and log in to purchase), we are able to provide them access to the purchased items forever, even when accessing the app from other device.
We are also storing the associated in-app-purchase's ProductID from iTunesConnect, plus the userID, the price, and the date, to have a detailed register of all purchases.
Important: Apple has rejected our first solution, because they didn't understand how it works, and how a purchase can be restored.
The key to success was describing in detail how the system works and providing a test user access to our web admin site. This allowed the Apple reviewers to see the whole system.
Yeah in my point of view they will accept it. As long as you allow users to retrieve their purchases later on. Your system make me think about a virtual currency I have made where I had to make generic consumable that needed to be actually saved for the user. Apple approved it (and still does) because I was saving all purchases, even if it didn't fit perfectly with IAP policy ;)
The key here is to make sure these purchases are restorable, always. So make sure to store the "IDs" or however you identify the different item in a way that is associated directly to the Apple ID (not account, but Apple ID).
As of about May 2014 this year, searching Google for "ios in app purchase promotion code", yields lots of news sites reporting the same thing - Apple seem to be working on allowing promotion codes for testing in-app purchases as evidenced by a screenshot from EA games.
My question is; does anybody know how to do this yet? I logged into the new iTunesConnect interface but can't find any link and nothing appears in the Apple docs from what I can find.
Ideally I'm looking to create a code for a monthly subscription but they may only be allowed for consumables. With the lack of actual info on IAP promo codes my guess is that the feature hasn't been officially made available yet and that EA games were invited by Apple to test it out.
As #Christoph Wimberge notes this is old news. Apple is now supporting this.
You cannot officially get promo codes for IAP currently. See here https://developer.apple.com/library/prerelease/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/ProvidingPromoCodes.html . If you're testing then you should be creating Sandbox Testers under Users and Roles. Depending on how you handled the IAP this could well serve as a promo code of sorts. So, for instance, if you're using the IAP to set a flag in NSUserDefaults or a plist file then this will work as a promo code. You will have to instruct the user to log in as the test user for the purposes of the purchase. Even if you delete the test user once the flag is set the user can use the IAP so long as they don't completely remove the app and assuming you don't change the way IAPs are handled like using App Store digital receipts to confirm purchases. Of course, if you're worried about crackers then you're probably not going to store successful IAP as a flag especially in User Defaults where anyone can just change the value willy nilly. But for apps that aren't games this probably isn't a huge worry. Hope that helps.
We were told by Apple today that they never allow users to type in codes, use Q-codes, or other gateway key to access anything. Instead, she said we should use a members-only webpage (i.e., login required) to accept redemption codes and associate the content through our backend. When the user returns to the app, the content would be available.
If Apple enabled codes for IAP, you could offer sales of the codes from another platform, which would then unlock the IAP. Apple would be doing all of the work, but reaping none of the rewards. In addition, all of a sudden, you've created a knock off market for promotional codes, like g2a.com does for Steam keys.
While Apple might have the functionality, it seems exclusive to EA for now.
Currently, you'll need to figure out how to support promotional items outside of the app store.
I have a very strait forward question (and yes I've looked though apple documentation to see if this has an answer but no luck... I may have accidentally missed it though)
Here's my plan:
The problem I've been trying to find a workaround for is that if the admin would ever want to add a product, he would have to log into iTunes connect to add it and also add it in a custom control panel. We, obviously, don't want to make him suffer that so I've been looking for a solution but I need you guys to tell me if it's allowed by apple. Basically I will take over most of the product handling on our servers and will only go to apple with the transactions. This means that apple will not have an in-app purchase set up for ALL the products... only one for each length of subscription (1 month, 3 month... etc) and a few consumable in-app purchases for the various prices of the issues/singles
Side note: I will be selling monthly issues that contain multiple singles for each day of the month. The user will be able to download a full month or a single day at a time if they like.
DEFINITION OF CONSUMABLE PURCHASE - products must be purchased each time the user needs that item. For example, one-time services are commonly implemented as consumable products.
So I will store all the information in our server about the products and if someone chooses to buy a single month's issue that was set to 4.99 (on our server, not apples) then the app will run the in-app purchase with apple that is listed for the 4.99 tier. Whenever a person opens the app for the first time, their app will send some information to our server and they will have a row set aside for them where all the information about their purchases will be recorded so that they can restore them if they switch over to another device.
If you guys think i'm safe in doing this, please let me know so that I can proceed. Also, if this method helps anyone, feel free to use it!
Thanks,
Matt
I think your restore process might be flawed. You talk about the app sending some information up to your server, but what is that information? There is no reliable way to uniquely identify a user across different devices.
If you want to continue on this path you'll want to make sure that your recovery and failover process is very solid. Try out every imaginable scenario. From an app store submission point of view, you'll want to consider a token/coin-based approach. Of course, Apple's guidelines are fairly loose and subject to change so it's always possible you'll get rejected, but tokens are certainly more solid than simply using the same generic in-app purchase.
In a token system, you would set up in-app purchases for different numbers of tokens that the user can purchase as a sort-of virtual currency only valid within your application. Then users can spend these tokens on any items that you dynamically create.
Server-side this means you'll need some way to store how many tokens a user currently has and a way to uniquely identify a user across devices, which is a fairly uncertain proposition. Instead of storing the number of tokens each user has, you could implement some sort of hashing algorithm that generates a hash from an in-app purchase receipt and then sends it up to your server. If the app crashes or the network dies after purchase but before sending your hashes up, next time they open the app you can recalculate all of the hashes, send 'em up, and if the server doesn't recognize a hash it just adds it to the database. Then if a user wants to restore their purchases you simply recalculate the hashes on the device using the in-app purchase receipts you'll receive and then send them up to your server and ask the server to figure out for each of those hashes, how many tokens the user has left. You could think of it like a gift card system, where each hash is one gift card.
Again, app store rules change and if apple thinks you're trying to game the system and not provide a useful experience they have the right to reject you. It could be worthwhile to open a Developer Technical Support request and see if an apple engineer can provide you with a better solution or tell you if the reviewers are likely to accept your application.