I have two similar apps with in-app-purchase (IAP) content that could be shared between them. I'd like to reward customers who buy in one app, by letting them transfer the purchase to the other app. However, I'm worried that my apps would be rejected due to the App Store review guideline that says you can't have any non-App store content activation methods.
As far as technical feasibility, it's clear to me that the Document Interaction mechanism is a means to this end (sans web server). I can have each app register a custom file type. The app in which the user purchased the content can show a link to launch the other app, passing it appropriate metadata as the "launched file" so the second can then mark the items as purchased.
Does anybody know if this has been attempted, and if Apple is approving such an approach?
Note that I'm not concerned about purchase security with this approach, because making paying customers happy is much more important to me than preventing piracy.
This isn't so much an answer to the precise question above as it is a useful alternate technique of accomplishing the end goal. If you set things up correctly, two apps can share KeyChain access, and thus share metadata about purchased IAPs. This requires using the same Bundle Seed ID (e.g. "AXGUKHGX...") for the app ID, in combination with setting things up properly in your app's info plist. This latter technique is a much more elegant approach for propagating sharable IAPs.
Related
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!
Recently, I finished developing an app in which users unlock resources using codes. These codes are free but users need an authorization from a contact to get them.
I had uploaded the app in iTunes-connect but now Apple said I must remove this feature from my app because it goes against 3.1.1 guidelines (In-app-purchase).
Reading this guideline, I found that:
Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
but, as I said (and I told it to Apple), I don't use any kind of purchase in my app nor out of it.
Is there anything I can do, as this feature is 100% of my app?
Edit:
I found this in the guidelines (this is my case, if we asume "purchased=free"):
3.1.3 Content-based “Reader” Apps: Apps may allow a user to access previously purchased content or subscriptions (specifically: magazines, newspapers, books, audio, music, video, access to professional databases, VoIP, cloud storage, and approved services such as educational apps that manage student grades and schedules), provided the app does not direct users to a purchasing mechanism other than IAP.
so, can I use this to pass the review?
3.1.4 Content Codes: Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, etc. In limited circumstances, such as when features are dependent upon specific hardware to function, the app may unlock that functionality without using in-app purchase (e.g. an astronomy app that adds features when synced with a telescope). App features that work in combination with an approved physical product (such as a toy) on an optional basis may unlock functionality without using IAP, provided that an IAP option is available as well. You may not, however, require users to purchase unrelated products or engage in advertising or marketing activities to unlock app functionality.
https://developer.apple.com/app-store/review/guidelines/
I assume that the resource in question is something used by your app. If so, you probably have to use another approach to unlock resources other than using codes. As the guideline said, anything used by the app must be brought within the app (IAP). Codes can come from anywhere such as your app, your website and social network. The latter two are obviously not in your app.
But after all, if you let the user to unlock some part of your app, you have to use IAP, otherwise apple would reject it.
We're a small company and have developed an iPad app we would like to give to our customers. I've read through the B2B option but don't like our customers having to register their DUN info with Apple.
Should I just load it in the App store and put in the description that it's a private App? It requires a login so it doesn't matter if other folks download it.
Currently, we're using it in house via the internal tester scenario.
No one but Apple can say for certain what Apple will do in any specific case, but your description suggests it will be rejected.
From Apple's App Review Guidelines (https://developer.apple.com/app-store/review/guidelines/):
17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
If you don't have a base functionality that applies to the general public, you will, in all likelihood, need to go Enterprise delivery.
Distributing publicly might be the best option, but I don't think you would get an approval if you describe it as a private app in your description.
Without knowing too much about your business or the nature of your app, it's hard to suggest, but possibly you could add some public usefulness on the front-end of your app, even if that's business info, contact information, a news feed, etc... with the real intent of the app being tucked behind a login portal. (all total speculation).
Distributing the app outside of the app store has a lot of limitations as well: http://mobiledan.net/2012/03/02/5-options-for-distributing-ios-apps-to-a-limited-audience-legally/
I would just submit to the app store and see what happens. Apple may reject it, but that is true in any case. I have an app of this nature, submitted with a couple of test accounts, no problem getting it approved. When the app launches, it pops a logon screen, and has a short message about where to get an account (which won't make much sense to people not in the intended audience).
Using the links at the bottom of my post I have built a basic in app purchase for my OSX app. Basically what I do is show a UI for the user to select that they want to purchase the upgrade (which just adds more content), then I start the transaction with a call to addPayment:, I receive the transaction in paymentQueue:updatedTransactions: and if it is purchased transaction I send it along to a method that provides the content and then calls finishTransaction:.
This all works in a single use of the app but then when I fire up the up again I would have to do the purchase again to reenable those features (this makes sense because I am not storing the upgrade data anywhere), but I am wondering what is the best way to store the data about the purchase to prevent the user from being asked to buy again after they have already purchased. Is this somehow suposed to be done through receipt validation? None of the documentation I found talked much about this.
Helpful links:
In app Purchase walkthrough
Apple's in app purchase documentation
EDIT:
My app is really just trying to enable built in content through the in app purchase so it seems that using property list is the what Apple would suggest:
Apple recommends using a property list (plist) to track product identifiers for your built-in features. Content-driven applications can use this to add new content without modifying the source for your application.
But I wonder how can I edit a plist file if it is stored in the bundle (this was cause the sandboxing to think the app had been compromised). Do you store the preferences plist in the container? The link apple gives that is supposed to discuss more about changing application preferences links to an IOS page and the only thing on that page about preferences is in the settings bundle.
Implementing Application Preferences”
Is the application preferences method only to be used on IOS? Is the correct place to put the upgrade data in the settings bundle?
For purchases that enable additional content, Apple recommends using a server-based receipt validation setup as noted here:
http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/APIOverview/OverviewoftheStoreKitAPI.html#//apple_ref/doc/uid/TP40008267-CH100-SW12
"Apple recommends you retrieve product identifiers from your server, rather than including them in a property list. This gives you the flexibility to add new products without updating your application.
In the server model, your application retrieves the signed receipt associated with a transaction and sends it to your server. Your server can then validate the receipt and decode it to determine which content to deliver to your application. This process is covered in detail in “Verifying Store Receipts.”
The server model has additional security and reliability concerns. You should test the entire environment for security threats. Secure Coding Guide provides additional recommendations.
Although non-consumable products may be recovered using the built-in capabilities of Store Kit, non-renewing subscriptions must be restored by your server. You are responsible for recording information about non-renewing subscriptions and restoring them to users. Optionally, consumable products could also be tracked by your server. For example, if your consumable product is a service provided by your server, you may want the user to retrieve the results of that request on multiple devices."
You can create a UUID for the user and store it in the app's preferences. The advantage of doing this is that the uuid is then backed up when the user backs up or restores their device. It can also easily be synced across iCloud if it's a universal app. The server can then link that UUID to the purchases made and deliver the content that was purchased by that user. You may want to include additional security protocols to reduce any UUID spoofing by unscrupulous users, but unless the content is extremely valuable, that is usually more effort than it's worth IMHO.
I am building an app that downloads an XML file and ultimately presents stats for financial quarters.
If I wish to add a button that prompts the user to allow another quarters worth of data, can I simply add a boolean value to my app, send them to the store, toggle the flag and allow the download of further XML files from my website?
Read many articles on the web, but my head is spinning!
Ideally I would prefer apple to handle all the backend restoration of data on the device once it is purchased :)
Any useful links or advice would be great :)
In theory, yes. It depends how secure you want the process to be.
In your suggested way, the paid-for content (your XML files) still remain accessible to download across the public internet. You could authenticate the download, but that will require infrastructure on your end, rather than Apple's.
Basically, once a user goes off and makes an in-app purchase your app is sent back a) whether the transaction was successful, and b) if so, an iTunes receipt.
The receipt is critical, since it allows you to verify someone really has paid for the item they're trying to get. Most developers implement receipt validation on their own servers (although you can, in theory, do it on device as well).
You may decide if your app has a sufficiently small market that this isn't required. For apps where it could be quite likely people would want to pirate data, perhaps you want to consider some receipt verification.
It is possible to use a third-party service to simplify the process, if it's something you find a little too complex to integrate yourself. I've never used any myself, but one I've heard reasonable things about is Urban Airship's IAP service: http://urbanairship.com/