After attending an iPhone dev conf in San Jose - I left with more questions about In-App purchasing than when I started. Here's what I was wondering:
You can set a purchase as a type "subscription". cool. But, it doesn't say anywhere about how the subscription is serviced - how does apple know to charge once a month? once a week? one every six months? etc. I was told that apple doesn't really do that - only that it calls it a type of subscription. That the developer must be the one to monitor the subscriptions and then submit them to apple when they are due up - but this leads to another question - then why have the subscription type? If I monitor the days until it's due, then submit it to apple as an application charge - what's the difference in merely making separate charges on a regular basis?
it seems to me, apple is doing nothing on the subscriptions - only declaring the type - all the work is done by the developer - in which case, why call it a subscription?
Can someone point me to some code that handles a subscription for an app - and what they had to do to set this up for recurring payments? Would greatly appreciate it....
many thanx.
peace. JOe...
Subscriptions in the iPhone SDK really are to get around the fact that you cannot sell virtual credits, therefore what you can do is sell a subscription and make the digital content free from within your application assuming the user has a subscription to your service, you are correct in that you have to handle the majority of the logic yourself
Related
Is there some new subscription mechanism requirement on iOS? So far we handled the subscriptions without involving Apple, but this (https://developer.apple.com/appstore/in-app-purchase/subscriptions.html) is saying something different:
If you offer auto-renewable subscriptions, you can also use other
methods to acquire digital subscribers outside of your app. You can
sell digital subscriptions on your website or provide free access to
content for existing subscribers. In these cases there is no revenue
sharing since Apple was not involved in the transactions. Developers
keep 100% of the revenue. If you would like to make a subscription
offer outside of the app, the same (or better) subscription price must
be offered inside the app for users who wish to subscribe from within
the app. In addition, you may not provide links in your apps which
allow the customer to purchase content or subscriptions outside of the
app.
I understand the In-app purchase is mandatory for one-time payments, but so far we were not forced to offer subscriptions over In-app purchase mechanism...
BR
STeN
My historical understanding as well as my understanding of that specific text is that, yes, they require you to offer the IAP subscription inside your app since you're offering it outside as well. I think you've just gotten lucky so far that they haven't noticed.
I am having the below concern when implementing auto-renewable subscription - in-app purchase inside my app.
I am finding the difficult scenario on offering the poems under auto renewable subscription.I have referred this url.By reading this i am got confused that whether i can offer poems via Autorenewable subscription or not?
Please let me know.
Whether Apple lets you do auto-renewing subscriptions or makes you do non-renewing subscriptions is less about your content and more about how it is delivered. I assume you have already read the information in the iTunes Connect Developer Guide. You should also watch the WWDC Video from 2012 about Supporting Subscriptions (it is 308) and it will give examples about when to use what kind of subscription.
I have recently done an app with subscriptions and we were initially rejected for auto-renewing and told to use non-renewing subscriptions. As best I can understand, you will use auto-renewing if you are creating original content on a set, regular basis and have built your app so that there are logical units (like a monthly newsletter or magazine). In my case, the user was subscribing to a series of blog entries that are updated every few days. However, the entries are presented in a single table view listing sorted by date and not separated into any kind of daily or weekly units.
Again I cannot tell from your question how the poems will be presented, but my suggestion would be to review the above documentation and if you are not 100% sure that you clearly fit into one of the auto-renewing subscription categories, submit your app with non-renewing subscriptions.
I have an iPhone/iPad application that offers a monthly subscription to a service. Although, this service is totally useless during 2 months in the whole year.
Is there any way to either suspend all my users subscription for 2 months, or give them a 2 months refund every year so they don't pay for a useless service ?
After a good talk with an Apple employee, it is not possible to suspend an auto-renewable product.
Also, 0$ subscriptions do not exist outside NewsStand apps for the moment.
In order to solve our problem, we will have to delete the in-app product in iTunes Connect. This will automatically cancel all active subscriptions we have so the users will not be charged for nothing.
A big downside to this solution is that we will lose all current subscribers, so next year we have to build up a new subscriber bank from scratch.
Maybe you can give two months for free to your users instead of refund them.
Have you found any better alternative, since posting your answer about canceling all subscribers every year?
In addition to 1-year subscriptions, apple lets you do other terms as well, including 1-month subscriptions, for both renewable and non-renewable subscriptions.
Maybe you could make your in-app UI look as if the user is signing up for a long-term subscription, but behind the scenes, your app only sends a 1-month non-renewable subscription request to apple. Then, each month, your app automatically requests another 1-month subscription, and another... just skip the months you want to skip.
The user fills out the subscription form in your UI 1 time. Your app logic remembers how many times to start a new 1-month subscription.
In an app that is free, but has in-app subscription purchases I would like to allow a user with a paid subscription to receive x number of free months on top of the paid subscription if he refers someone that purchases a subscription.
For this to work it would have to be possible to track some sort of unique token through the Apple App Store in order to reliably assign credits.
To "Refer a friend" the app would allow the user to send an email to one or more people. This email would contain a link to the app store that also contains a unique key that I would generate to track the lead.
Is this possible?
Our app just got rejected yesterday regarding this kind of functionality.
We had an application which includes yearly subscriptions to access premium features. We also had a way for users to refer 5 friends to get a free access for life to our services. Apple rejected the app stating that this was against their rules for IAP.
Specifically, they referred us to the section 11.1 of the guideline which states :
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
Unfortunately, apple doesn't offer that functionality. One option is to offer 2 different subscriptions - paid and free.
Hide the free subscription portal until they refer someone - then allow them to see the free subscription option.
A couple problems:
The user will have to manually cancel auto-renew on their current paid subscription and then manually sign up for the free subscription.
I don't think you will be able to disable auto-renew on the free subscription option, so it would probably end up being permanent.
You could skip the free subscription official IAP and just make your own time-limited "back door" letting the customer continue downloading subscription content without verifying their App Store receipt. This would still have problem (1) above with the customer needing to manually cancel their auto-renew and then repurchase the subscription when their free time runs out.
My gut tells me this is going to be REALLY hard to pull off in a satisfactory way.
It would be much easier to reward one-time exclusive content for referrals. E.g. Give X for the first, Y after 5 referrals, Z after 10 referrals, etc. This is actually an easier value proposition to present to the users too; make a nice icon or something with an "Invite Friends to Unlock!" call to action.
I'm considering posting an app to the iphone app store, but I'm curious before I start paying them for the priviledge of posting the app, whether they provide instant payment notification to a url?
Generally, I've used paypal in the past for applications where right after payment my web site is secretly notified of a purchase. I take this notification, with the users email address and product purchased, to send the purchaser information required for the application.
Is this possible with apple? With the iphone app store? What about the upcoming mac store?
thx
No. Apple handles all contact with the customer, including delivery of the app. At the end of each day, week and month they give you summaries of sales of each product in each country. It's nothing like selling with PayPal. The iOS and Mac App Store are exactly the same in this regard.
The nearest you can get is having your app connect to your server when it first runs, although if you're doing this for no other reason than to track your users, you'll have to check it's allowed under the developer agreement.
First, no, you do not receive instant notification. You can grab a daily report on the web the following early morning (in the US), you can use the free app that Apple provides to retrieve the information, or you can use a variety of third-party tools to do the same.
Second, you will never receive any information whatsoever about the people who buy your app, so no, you can't send purchasers anything.
The Mac App Store appears to use the exact same arrangements.
If you use in-app purchase, you can get an instant notification to your server for the in-app purchase, but not for the initial download of the app.
If you just place a paid app in Apple's App store, you get no direct sales or customer information of any kind, only after-the-fact daily and weekly sales trend estimates, and monthly sales reports a few weeks later. Then Apple then pays you 70% of what they reported up to 45 days after the monthly close. You don't pay them. They pay you. And with over 300K apps in their store, and no other store doing anywhere near as well, they need no privileges granted from any developer. It's more like take it or leave it.