I'm building an app that will provide users with an evolving directory of companies in their local area (location-based) that manufacture green/sustainable products. I want companies to be able to add themselves to the app by purchasing a subscription using in-app purchase. This would be a 1 year subscription.
Just read this in the iOS Standard Agreement: 2.3 Content and services may be offered through the In-App Purchase API on a subscription basis (e.g., subscriptions to newspapers and magazines). Rentals of content, services or functionality through the In-App Purchase API are not allowed (e.g., use of particular content may not be restricted to a pre-determined, limited period of time).
If the service is only for a year, does this preclude me from doing the above? Anybody have any insight on any of this? I'd appreciate your input - I can't get any info from Apple. Thanks.
My guess is that you are not allowed to do that. As you really cannot restrict who subscribes for a year – it might be any user – you probably cannot offer this. The IAP doesn't provide any content or service to the user other that a listing. As you probably need an external data source (e.g. a web application) I would suggest moving the subscription there. This is just my opinion and I am no lawyer so I might be completely wrong here.
You can do it. See the image below. You just have to choose the right option.
You can find it itunesConnect in the app detail section.
For your case I suggest Consumable is appropriate and have to maintain a check that wether its been a year or not since the last magazine purchase or what so ever your scenario is.
Related
Our app was rejected in App Store because we were using 3rd party solution for subscription and was decided to use In-App Purchases ( Auto-Renewable Subscriptions). I went through several tutorials and it seems that the subscription has to be created in App Store Connect and only then it will be available to use in app and that's the problem for us.
Our app is something like news app where user can subscribe to some author. List of authors comes from server therefore hardcode every subscription for each author is not the way to go.
So, Is that possible to somehow implement what I want with In-App Purchases? Thanks.
There is no option to create subscription dynamically. Your case is a draw back of iOS subscription platform. I have pointed out this problem to Apple subscription team but they were not ready to accept this and forced us to implement in-app subscription, so we had to restrict the number of subscription in app.
Only possible option is to create a number of subscription groups, lets say 10 groups representing each author.
authorSusbcription1,authorSusbcription2,...authorSusbcription10
I know it's not a viable solution since the number of authors is indefinite. But we don't have any option as of now. You can restrict 10 authors subscription in the app and then prompt users to buy from website if it's exceeds 10.You can show some alert that doesn't violate the in-app rule. For example, "Further subscription is not available in this app" instead of mentioning about your website. Track this user and use an API to send an email to this user asking to subscribe via website.
Unless Apple fix this drawback, we have no other options..!
Dynamic Auto-Renewable Subscriptions creation (and dynamic in-app purchase creation in general) is not possible. Alternatives would be to sell credits to authors (but this is non-auto renewable). Another possibility is to sell tiers of subscriptions that grant access to a number of authors.
Case:
Our iOS app offers selling of custom made recipe packages that would be created for each user specifically. For example - user buys package of recipes, but for each user this package would be created individually, based on users preferences and needs, by someone from the app team. This package should be created in 5 days for example. If app team fails to create this package and deliver to end user in 5 days, automatic refund should be triggered and end user should receive money back that he spent on this in app purchase, thus invalidating purchased custom package.
Problem:
Is this kind of scenario even possible in Apple / iOS world? Can app developer trigger refund process of one specific purchase that end user made? If user isn't satisfied with specific purchase, could app developer trigger this is refund process if he has reference to transaction receipt?
P.S. We aren't really selling custom recipe packages, this was just an example scenario to help to understand this refund scenario case. ;)
EDIT:
If such scenario isn't possible via Apple refund, are there some examples of this kind of purchase model, implemented in some other way? It's hard to wrap my mind that only way for end user to get refund for something is to write Apple and that also needs to be done by user itself.
If you get paid using Apple services (in-app purchases) then NO, it isn't possible for an Apple Developer (business or individual) to refund App Store customers.
The only option is to direct customers to iTunes Store Customer Support as officially stated in the iTunes Connect screenshot below:
To increase the chances for your customers in getting refunded you could provide them with an e-mail stating that you would like them to receive a refund which they could show to the iTunes Support employee.
As a colleague stated, an option would be to use an external payment processor like PayPal which would allow you to manage refunds, but I think this will greatly increase the work needed since you will need to manage almost everything regarding payments on your own.
Also note that this option is highly restricted by Apple to only physical services or goods and sometimes Apple does not approve apps providing services through third-party payment processors. So.. you should be very careful what path you choose to take.
If the recipes you're providing to your customers are in digital format and users receive them in your app, you can be 100% sure that Apple will force you to use the in-app purchase system.
If such scenario isn't possible via Apple refund, are there some
examples of this kind of purchase model, implemented in some other
way?
In some cases you can use payment through PayPal (for example). We did it in our application where we had to take money of users and return it after a certain period. Check if you case is suitable for using third-party payment systems. Because (for example) Apple will restrict your app if you want to sell in-game content via Paypal, not with in-app purchase.
One very simple alternative would be to have your users buy virtual currency in your app that they can then spend on their recipe-package-orders. Since you are managing their virtual currency account balance, you can easily refund, give volume-discounts, etc. as you please. The only thing that will still be hard then is to have users return their virtual currency to get back their actual money.
There is no api for allowing users to refund a purchase (otherwise guess what can happen).
More info here
I am looking for clarification of what type of In-App purchase would the following fall under according to Apple (https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html#//apple_ref/doc/uid/TP40008267-CH2-SW2):
A monthly video subscription service that delivers rich content only available on the application.
Do I need to offer the ability to restore purchases? If a user subscribes in March is it okay to give full access historically? If a user joins, cancels and joins, can the history cover the gap? Reading the documentation it is not very clear.
Yes, you need the ability to restore a purchase.
The rest is a business decision and is entirely up to you. Apple may quibble if you don't make what you're selling clear but the details are yours to decide.
We are an university department for further education courses and we are planning to publish our cd based courses as an additional iOS/Android App. As we have almost finished the development process we are now facing some questions regarding the distribution. The basic idea is to publish the app in a lite version for free (including chapter one of the course). After you have completed this chapter you will be asked to enter your login data. Our students will be able to enter thier data to activate (download missing content from our server) the app. If you are not an enrolled student there will be a link to our course page. On this page you can enroll for the courses and of course there is a charge for this.
But Apple only allows purchases via the App Store or as so called "in app buys".
Will we violate this rule with our idea?
I have found some newspaper apps with basically the same concept: download for free. If you have a print subscription for this newspaper you enter your data and can use the app. If not you can subscribe for the online offer via an in app buy.
After days of research we have no clear answer to this scenario.
Any comment appreciated.
There are two possible solution for your situation:
Without In-App Purchase: You can create an app which can have a eBook (in your case, dummy eBook with chapter 1 content) bundled with the App.
By doing this anyone who can download will have access to the dummy eBook as well.
For downloading of additional-contents user can do login and access the eBooks available with their account.
Kindly note as you are not using In-App purchase there shall be no links for user registration, buy inside your app.
All these you can handle at your web-site.
Your app can check for valid user credential using a web-service call, and user can see the contents available for download.
Advantages: 1) You shall not be paying 30 % to Apple as No-purchases are done using your app.
2) This is total compliance with Apple guidelines, this link and part 11 specially will be of interest.
Disadvantage: Users cannot directly buy/register via app and you need to maintain additional services for user login validation/content mapping/download content etc.
Using in-App Purchase:
You can use Apple provided in-App purchase for selling content/ registration of users etc.
Please note Apple shall charge 30 % on your selling price.
Advantages: Users can register and buy directly using your app. In-App purchase guidelines will help more in this.
Disadvantage: Apple will charge 30% on Selling price.
Given what you are trying to do, there really is no clear answer for your question that this community can provide, I'm afraid.
The true answer is entirely up to Apple's current app review policies. You should probably submit the app, explain clearly what you are doing, and if it gets rejected/denied, you can follow up with an appeal to the app review board.
As far as I know, physical items that are purchased are not subject to Apple's 30% cut. However, since you're offering courses / content over the 'net, Apple may want some percentage (between 0 & 30%) of the the profits you're making. Maybe they have a different arrangement with newspaper publishers. Ultimately, you'd need to submit the app and find out what the reviewers and app review board say.
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.