We have two targets from the same code. Reason is to be able to localize the icon in the app store and on the device. They have different App IDs, but we was hoping to use the same IAPs for both.
We use Urban Airship to look after the IAPs, but iTunes Connect doesn't allow us to enter the same Product ID in the different apps.
We don't really want to keep different sets of codes and IAPs, so is there any way of getting this to work?
Thanks
No.
In-app purchases require non-wildcarded App IDs (foo.bar.bang, not foo.bar.*).
App IDs must be different.
In-app purchases can only access their own App IDs available purchases.
I suggest you rethink the need for localized icons. (If there is text on your icon, you should definitely rethink it!) Otherwise, genericize the icon.
Possible workaround (i think you can do this): both apps can use iCloud to access shared defaults. Unlock purchases made from one app in the other as identified by defaults.
No you can't use the same subscription as #bshirley mentioned - according to https://developer.apple.com/app-store/subscriptions/
But you can create two subscriptions and sync between the apps so your users will not pay twice for the same thing.
Offering Subscriptions to Multiple Apps
You can offer auto-renewable subscriptions to access multiple apps in your portfolio. Each app must be approved to use auto-renewable in-app purchases and must be published under the same developer name on the App Store.
In iTunes Connect, you’ll need to set up separate and equivalent auto-renewable in-app purchases in each app offered in the multi-app subscription so that users can subscribe from any app. To avoid users paying multiple times for the same offering, you are responsible for verifying that they are subscribers in one of the apps before showing any subscription options. To do this, consider maintaining an account management system in which users create an account with your business to sign in to each app.
Related
I have an app which has some purchase option. However, I don't want to make it through the app itself. For that, I already have a website for the purchase.
So can I create a redirection page from my app to the respective webpage?
Will my app get rejected?
or is there a better solution?
It depends on what you are selling, if you are offering "Physical Goods and Services Outside of the App" you cannot use IAP and must use something else as described in the App Store Review Guidelines
3.1.5 (a) 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 in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.
If not then you must use IAP and will be charged a 30% fee. However, if you are offering subscriptions this rate will drop down to 15% for users who have been subscribed for over 1 year. Check out Offering Subscriptions for more info if you are interested.
There isn’t any,
According to Apple’s official guidelines
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 use in-app purchase currencies to enable customers to “tip” digital content providers in the app. Apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase.
You must use in-app purchases and Apple’s official API’s, if it’s not a physical item
Otherwise your app will be rejected
if you want to sell tokens/credits/gold coins/gems or whatever as consumables in a game they also must be through In App Purchase. Meanwhile for Physical elements that we brought from any e commence app that must should go through your requirement.
hope this work
for more info refer this link blog post describing it
Firstly, let me answer your question based on my experience(bad :( ) with Apple
So can I create a redirection page from my app to the respective webpage? - NO
Will my app get rejected? - YES
or is there a better solution? - Depend on types of app.
The In-App guidelines are recently updated with few more changes so it's depends on what kind of feature you are subscribing. For example:
3.1.4 Hardware-Specific Content: 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).
To be honest, DON'T trust these exceptions and build your app based on this. In our case, app works exclusively based on a connected physical device device. After rejection from Apple, we appealed with this exception but we didn't hear from Apple for more than a month..!
Using subscription through website
Many thinks that they can get away In-app purchase by offering subscription through website and removing t from app. But Apple will still reject your app and confirmed with Apple team. If you are thinking about Spotify and Netflix cases, there is a category of apps it's only permitted called "Reader app". Please refer 3.1.3(a) of Apple guidelines.
Building an iOS App in Swift. Quick question about IAP's I want to implement. Currently, I have my In-App Purchases fixed in my app. Meaning, I would have to push an update to the app in order to change the visible information about the IAP, etc.
Does Apple allow me to store this In-App Purchase data in my cloud(Parse), or does it have to be local? Of course, the IAP's would have to be approved in iTunes Connect, but don't have to be used if they are approved.
My goal is to alternate through different plans without having to go through an entire app update.
I feel like the answer is a big obvious yes, but I just wanted to confirm before I begin coding it all in.
Thanks!
It's up to you to decide where to store In-App Purchases.
Here is Apple documentation about storing in-app purchases data.
How to store product identifiers:
Every product you sell in your app has a unique product identifier.
Your app uses these product identifiers to fetch information about
products from the App Store, such as pricing, and to submit payment
requests when users purchase those products. Your app can either read
its list of product identifiers from a file in its app bundle or fetch
them from your server.
How to store associated content for purchased package:
You can embed that content in your app’s bundle or you can download it
as needed — each approach has its advantages and disadvantages.
Embed smaller files (up to a few megabytes) in your app.
Download larger files when needed.
Personally I want to say that all projects I was working on used remote server for getting in-app purchases data.
You don't need care about app approval in this situation.
Yes, It is possible to store In-App Purchases on the Cloud(Parse).
The in-app purchases for iOS are done through the Apple app store. We do not take a cut or interact with the transaction in any way. We simplify the process of setting up in app purchases, take care of interacting with the Apple server, perform receipt validation to ensure your purchases are done securely, take care of delivering the purchased content through PFFiles if you choose to use this mechanism and also provide an easy to use UI component for use in your app.
if you want to know in detail visit here http://blog.parse.com/announcements/in-app-purchase/
Yes, you can do that using parse in swift(youtube)
and parse doc.
I've recently taken over development of an iOS project for a company, and we have a completely new version in the works. To distribute the beta without overriding the old version (so our users and testers could use both on the same device) we've set a new bundle ID and such for the new one.
We're going to have the same In-App-Purchases available, so I'd like to be able to just access the old ones in the beta. Can I make them available to multiple Bundle IDs?
Yes and no, you can't share subscription between apps, but your backend can verify if user is allowed to use feature behind In-App-Purchase. But you are responsible to not to take money twice for the same feature.
source: https://developer.apple.com/app-store/subscriptions/
Offering Subscriptions to Multiple Apps
You can offer auto-renewable subscriptions to access multiple apps in your portfolio. Each app must be approved to use auto-renewable in-app purchases and must be published under the same developer name on the App Store.
In iTunes Connect, you’ll need to set up separate and equivalent auto-renewable in-app purchases in each app offered in the multi-app subscription so that users can subscribe from any app. To avoid users paying multiple times for the same offering, you are responsible for verifying that they are subscribers in one of the apps before showing any subscription options. To do this, consider maintaining an account management system in which users create an account with your business to sign in to each app.
I am implementing an App with in app purchase of type:non-renewing subscriptions.
according to apple documents:
If your app uses non-renewing subscriptions, your app is responsible for the restoration process.
FROM HERE
My question is, if the restoring is mandatory by apple, how to prevent thousands of users sharing one apple account with only one description?
For example, if in my app, you pay $0.99 that can use this app for 10 days, from apple's requirements, the user must be able to use app within 10 days on any his/her devices, with simply enter the credentials. However, if the user set a simple account credentials and share it with 100 people, then, the 100 people don't have to buy the subscription anymore and can use the app free during the 10 days.
Some people keep assert that people won't share their account... how do you know that? i saw people register some apple id exclusive for sharing apps and games, and only need to pay once.
Besides, i don't implement my own server and my App don't need one. Is there a way to prevent this?
Thanks in advance
Since non-renewing subscriptions seem to require the app (developer) to use a separate (non-Apple) server to deal with the restore process (for example, see How to support multiple devices with non-renewing In-App Purchase?), why not have that server keep track of the number of restores per "user"? Then you could impose a maximum number of restores per "user". Each installed app that has made a purchase could have its own unique_token (for example, see app rejected.how to track user non-renewing subscription). The user would then have to have a username/password, which would be associated with the unique_token, in order to do a restore (for example, see Restore transactions for Non-renewing subscriptions without registration; and see Registration should be always optional on non-renewing subscription?).
I don't understand Apple Guidelines. I had created an app which is having free as well as premium features.
By default the app comes installed with free features, I had provided the buy button so that user can buy the premium features of the app using the in-app purchase feature.
The duration of subscription is 3-Months and it is non-renewing.
I submitted the app to App store, but apple is asking me to place a restore button in the app, so that users can restore their previous purchases.
on the other hand, It is written in the apple documentation that you cannot restore subscription based apps.
It seems quite confusing to me, Can you please guide what to do in this matter.
There are two possibilities:
1) You don't know that some of your purchases are restorable.
2) Apple doesn't know that all of your purchases are non-restorable.
Follow up with Apple.
EDIT The above is wrong. You need to restore the purchases on your own without their support, since you chose to not use auto renewing. From the IAP guide
You are required to deliver non-renewing subscriptions to all devices owned by the user. Non-renewing subscriptions are not automatically synchronized to all devices by Store Kit; you must implement this infrastructure yourself. For example, most subscriptions are provided by an external server; your server would need to implement a mechanism to identify users and associate subscription purchases with the user who purchased them.