I am writing a SwiftUI app and I am looking for some advice.
I setup a product identifier in AppStore connect
Lets say it's
com.example.subscription_service_1
The monthly price is $39.99
I want to have an introductory offer for $19.99 if a buyer chooses a 12 month pay up front
SKProductDiscountPaymentModePayUpFront
When the IAP is triggered, the customer ONLY gets to see ONE option. They see the Pay Up Front.
I am not sure if I am doing something wrong or if this is how it's designed.
I felt that Apple always allowed customers to choose their options.
Please advise what I must do (without creating unnecessary product Identifiers).
I am not sure if I understand you correctly, but if you want to charge the user $39.99 monthly and grant him an introductory offer when he chooses one year, then you have to create two subscriptions: one monthly subscription with the price of $39.99 and a yearly subscription with a price of whatever you want. You then have to create the introductory offer of $19.99 within App Store Connect for the yearly subscription.
Related
My web has a pricing of pay-per-use. Let's say my web process a file for example resizing image.
When my customer sign up they get 100 coins for free.
Each time my customer resize image and sell it it will cost 1 coin. but all of this happens automatically after someone purchases image.
My question is I would like to charge them automatically
for example after the coins of my customer drop below 10 then charge automatically 15 coins ($15) --- $1 per coin (My customer should be able to choose how much coins he/she wants to recharge)
I'm not sure but I think paypal doesn't provide this feature to new customer anymore?
https://developer.paypal.com/api/nvp-soap/paypal-payments-pro/integration-guide/reference-transactions/
What choices do I have? I really need this auto recharge feature.
Reference transactions still exist, but have always required approval. The account owner should contact PayPal's business support (not technical support) to inquire about the approval, and explain the business need.
If approved, PayPal can then guide you on which API to best integrate with -- which might be the new v2/vault (note: not v1/vault)
The service is for a digital option within the app but users are to be billed on a monthly basis, based on the activity they have actually made.
How do I make sure my app isn't rejected?
If you think to bill the user after the monthly usage of the service, you cannot do that. In App Purchase is a form of payment in advance, so you can ask the user to pay initially for a certain amount of service (e.g.: use the service for N hours) and then decrease the number of available amount until it reaches zero, after that the user will be requested to purchase a new amount of such a service to continue to use it and so on.
You can do that using In App Purchase "consumable" in apps. But the user should buy the items before and not after the usage of your service.
Of course nothing prevents you to give some "credit" to the user and then ask the user to pay back this credit using in app purchase. This is closer to what you need but of course nobody can prevent the user to delete and re-install the app to reset his/her credit.
Another possibility is for you to introduce in-app subscriptions: but they are based on time, so you can ask for 1-week or 1-month service, but you cannot control the amount of service used in this month (in theory you could add a monthly cap, but I'm not sure this would be accepted by Apple as the idea behind subscription is that you pay for full usage in the subscription period).
A question regarding in-app purchase auto-renewing subscriptions:
I'm unclear how to handle the case where a user purchases multiple subscriptions of differing durations. It seems that Apple will recognize if the user has already purchased a given SKU (based on product-id) and prevent re-purchasing (my app gets a failed-transaction event in this case), but if I offer the same content using different product-ids having different durations, then the user can potentially purchase twice or more.
Even if I hide the additional purchase options once the user has subscribed once, they could potentially buy another subscription on an alternate device, and that purchase would/could ultimately be restored to the other device already having a subscription.
Am I supposed to track purchased subscriptions by transaction-ID and product-ID, and calculate an ultimate expiration date? That seems complicated.
Before I proceed, please see the comments on this linked post on why it may be a bad idea to use auto-renewing subscriptions.
Stop me if you've heard this before.
When you choose Auto-Renewable Subscriptions in iTunes Connect, you are given the opportunity to add multiple durations, with different Product ID's to one subscription Family. Apple won't allow a user to purchase multiple, overlapping subscription durations within one family. (If you're using multiple families in your app, please explain the reasoning, so I can give you guidance based on that).
In fact, Apple won't let the user stack different durations of a subscription within one family.
Here's an example.
I (as a user) download the hypothetical Acme app and subscribe with a 1-month subscription. If I do nothing, my subscription will automatically renew at the end of the period with another 1-month subscription. And so on.
But instead I go back in and purchase a 6-month subscription. Apple will tell me (with an alert) that my 6-month subscription will begin at the completion of my current 1-month subscription, and would I like to proceed. If I say yes, Apple will make note of it, but they won't charge me until my current 1-month is up.
Now if I go back in again and purchase a 1-year subscription, then again Apple would respond with an alert telling me that it will begin at the end of my current 1-month subscription. It won't get added to the upcoming 6-month subscription. It will replace it.
In Summary
So a user can only have one Current subscription and one Upcoming subscription (within a family. This is why you use a Family of product durations within a subscription. If you create multiple subscription families then they can exist simultaneously, and you loose that protection.
If, as a developer, you'd like to manually extend, shorten, cancel or stack subscriptions, you should be doing it with Non-Renewing Subscriptions. And if you read the link I posted at the top, you'll realize that Apple may force you to do that.
try using MKStoreKit 4, it has support for auto renewable subscriptions http://blog.mugunthkumar.com/coding/mkstorekit-4-0-supporting-auto-renewable-subscriptions/
Please consult Appstore Subscription page for latest information https://developer.apple.com/app-store/subscriptions/. The gist is to use group to define multiple subscription channels
Creating Subscriptions
Users can only buy one subscription within a subscription group at a time. If users would want the ability to buy more than one type of subscription — for example, to subscribe to more than one channel in a streaming app — you can put these in-app purchases in different subscription groups.
Upgrades, Downgrades, and Crossgrades
When a user upgrades to a subscription of any duration, or crossgrades to a subscription with the same duration, the service level change goes into effect immediately. When a user downgrades to a subscription of any duration, or crossgrades to a subscription with a different duration, the change goes into effect at the next renewal date.
Having a similar issue. Had an app approved with two subscription groups (for annual and monthly). They are auto renewing subscriptions. We have hundreds of users and they want us to change by deleting subscriptions groups and create a new one. Is it possible to create a new group and move existing products to that? Not sure what to do here and what happens next.
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.
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