Whats great about In App Subscriptions
Negative, Negative. Complain, hate and moan. Blogging media is so easy to jump onto the negative of a new and shiny addition to our tech lives. Its easier to find a way to hate something rather than love it, and unfortunately all bloggers care about is page views and ad revenue with the least amount of effort.
So I am going to go through the positives of the In App Subscription service and why we should love, not hate.
Recurring payments are expensive, time consuming to setup
If you have done web application development and dealt with a payment gateway then you will understand the uphill struggle that it is. For anyone that is lucky enough not to have the agonising memories of implementing a payment gateway heres some typical requirements:
Get a merchant account with your bank to be able to process CCards electronically (varies between banks, ~$100/year + setup fee + per transaction fee)
Subscribe to a payment gateway that is compatible with your bank (~$300 p/year + per transaction fee)
Develop the payment gateway into your application taking account for:
When the CC details entered fail to validate
When the CC fails to process a payment
Cutting a subscription when no payment is made after X time
Handling all CC details in a PCI compliant manner
Transaction history, paper trail for auditing
Refund capability if something goes wrong (I wonder how DreamHost are doing...)
For your average start-up this is a big initial investment (time and money) and most will find another way to do this in a different fashion, probably PayPal with users paying in a Pay-as-you-go manner.
Apple's implementation only costs your ADC membership fee and 30% on the subscription cost. There is no further development to handle the gateway on your own application.
No handling Credit Cards, accounts, transaction paper trails
PCI compliance is Number One when accepting any credit cards. In most cases this is handled by passing off the payment form to your Payment Gateway. Your payment gateway will securely store the credit card details allowing you to referenced them by an ID number.
Next is managing the account and associated subscription. This involves handling any changes in costs and how that effects current subscribers, not to mention currencies. Then after that the subscription payments need to be tracked to make sure there are no mistakes.
In the event of a mistake there needs to be provisions to perform a refund or credit.
With all this its almost impossible to keep an eye on it without someone managing it almost on a full-time basis.
Since all of the In App payments are done through iTunes there is absolutely no requirement to manage credit card details, the users account or anything to do with refunds or subscription costings. It will even handle different currencies and offer the correct Tier of pricing appropriate for the currency. Just query wether the device/account has subscribed and go from there.
Using todays thinking of subscriptions wont work
I agree that some of the current subscription services out there, that have voiced their complaints about this model, have a valid point. However, the same was said about the App Store initially where Apple still takes a 30% cut on App sales. Using todays ideas and calculations on subscriptions wont work, the margins dont allow for it unless the subscription price goes up.
For now I dont have a clear idea on how this will be solved, as I am not in the future. But I am sure there will be a new model of subscriptions in the future that will solve this current issue.
Apple's control over subscriptions
With every decision Apple makes, the choice is always there to benefit the user. Always. This is not exception. What I believe to be the reason behind the restrictions on using an external subscription source in an app comes down to user security and consistency.Â
Users aren't as savvy as most of us developers. When they get a form to fill out for a subscription and have to enter CC details they aren't always going to check for HTTPS. Wether that form is then legitimate or not is another thing. This safe guards users against getting sucked into a "subscription" that may or may not be legitimate.
In App purchases use the users iTunes account for payment processing, and this is no exception. Consistency is another big thing for any user experience on an Apple product. Using the iTunes account means the user doesn't have to re-enter any details or financial details.
If you want to take in more money rather then providing a better experience for your users than frankly, you're doing it wrong (IMHO).
If you hate it then thats ok
Haters are going to hate. Thats ok. Bitching and whining about it on Gizmodo isn't going to get you far. Sure, initially I was a little taken back by the 30% cut but it's consistant with the cut Apple takes from App sales.
Just understand that the maker of the largest mobile device app ecosystem is now allowing you to have a full featured subscription service for any application you want to make. The only issue is that you have to adjust your margins or models to cover the 30% fee, or initially take that fee in mind. If you don't want to do that then that's ok, someone else will and will make a boat load of money. My advice, adapt and overcome.
So you may have some existing agreements with content providers, well maybe have a chat to them. If they want their content subscribed on an iOS device then maybe some things have to change.
When analysing these stories and arising discussions it is important to expand thinking to include both sides of the debate.
Sure 30% is probably a little too high but there will be reasons why that is so. Coming from a company like Apple there would be justifications. Apple respect their developers and I trust that they would want to make that 30% lower if they were able to.
Android or WebOS may try to "1 UP" Apples subscription implementation. In fact im almost sure Android will try. What you may find is that these implementations may not be as good as what is on offer here. They might have a lower cut from transactions but the implementation for the developer may not be great. The user experience of running a purchase may be confusing as Andorid does not have a solid account behind purchases other than Google Checkout, which is not apart of the environment until a purchase needs to be made.
I would hate myself if I was a developer that openly rejected something because it didn't meet my expectations or was not what I expected. I thought Ruby was a bit stupid at first, when I was doing PHP development. Now that I have been developing with Ruby for the last 2 years I have come to love it.
origamiaround
prguitarman
2087
gummygunk
