my company wants to distribute out app via redemption codes at an expo. We do not want the app to be public, and we need more than 100 codes. We are enrolled in both programs, and the most recent build is approved on itunes connect but not released. What steps can I take to achieve this? Thank you.
You cannot get more than 100 promo codes for an app's version. You would need to update your app. For each version you get another 100 promo codes.
You can request up to 100 promo codes for every version of each platform of your app, or for your in-app purchases.
With in-app purchase promo codes, users can download your app (if the price of the app set to free) and redeem the code for the in-app purchase item. Codes can even be used before your app is available on the App Store. You can provide up to 100 promo codes for each in-app purchase item, with a limit of 1,000 total in-app purchase codes per app every six months (resetting on January 1 and July 1). These codes are for non-commercial use and expire 28 days after they were requested.
Source: https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/ProvidingPromoCodes.html
Follow this link for detail instructions in creating promo codes. https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/ProvidingPromoCodes.html
Codes can be used if the version’s status must be Ready for Sale or Pending Developer Release. For in-app purchases, the state must be Approved or it won't appear as an option.
In your case since app is approved by apple but pending developer release, you can use them for selective group.
Related
In the case when the shop has the RecurringApplicationCharge for example with a 30-day recurring charge. The RecurringApplicationCharge was created on for example August 01, and the application was removed on August 15.
As I understood from Shopify documentation, Shopify platform will automatically remove the RecurringApplicationCharge, but what happened with the refund? Does the Shopify automatically refund for the not used days? Or this part is the responsibility of the application owner?
Any information will be helpful I'm trying to find some clear description/documentation what exactly happens after the application was uninstalled.
Application using the latest Shopify REST API (https://shopify.dev/docs/admin-api/rest/reference/billing/recurringapplicationcharge?api[version]=2020-07).
Uninstalling apps with recurring charges
Make sure that you consider app billing cycles when you plan to uninstall an app. Recurring app charges are generated the first time an app charge is approved, and then on the first day of an app's billing cycle. Because of this, a charge will appear on your bill even if you uninstall an app only a day or two after you install it.
Shopify themselves will not refund the amount. There is no procedure for the same. Me being an APP creater has faced the same issue. The only way here is the App creator pays the amount back to the merchant if they decide to Uninstall the App.
Here are few documentations that may help you understand better:
https://help.shopify.com/en/manual/your-account/manage-billing/your-invoice/apps
https://shopify.dev/tutorials/charging-for-your-app-with-rest-admin-api-concepts
I have knowledge about in-app purchase, but stuck in implementing in app purchase in my case.
I have a list of videos coming from server when I click on any video I can download it in two formats, one low resolution and other is high resolution after in-app purchase. I have created two product identifier in itunes and have no any problem in implementing. But how will I keep track of the video and resolution I have purchased and also how will I use restore to get that product again if I purchased it once. Any advise will be highly appreciated.
Is it possible to sell consumable products via in-app purchase?
This looks to be fixed in Windows 8.1. http://msdn.microsoft.com/en-us/library/windows/apps/bg182887.aspx#two
Just to add my 2 cents to the answers:
There is a limit on the number of IAPs on Windows 8, and it is 200 (but has been removed in Windows 8.1). This might seem like plenty, but an app can easily have 10 or 20 different IAPs, which divides that number down to 10 purchases in 24h, which seems like a limit some users could very likely hit soon. To add two more complex ideas of a solution to this:
You could use analytics to get the maximum number of each in-app item users purchased in a 24h window and adjust the number of each IAP products per in-app item accordingly, i.e. assign more IAP products to most used in-app items, and less to items that are not purchased so many times in 24h.
You could have IAP products assigned to price tiers, i.e. define 50 products for $1.49 priced in-app items, 25 for $1.99 and so on..
For completeness, I'd like to quote #Chris Bowen's link to the workaround debate:
If the games are being XBL enabled they will have to use the built-in
Consumables solution.
The XBox Live, though, in my experience, is a very closed program.
The answer is no, but it is also yes.
Consumables, specifically are not supported. That is any in-app purchase you can make again and again and again and again. They are not supported.
However, durables (that you can purchase one time) can be set to expire in a single day. Many developers have created multiple durables, allowed them to be purchased in a day, kept a central record of their purchase somewhere, and let them expire so the user can purchase them again tomorrow.
So, no, you cannot set consumables.
And, yes, you can set expiring durables and act like daily consumables.
Consumables (e.g. buy a pack of gold coins for your character in the game, and allow the user to buy that pack multiple times) are not directly supported for Windows Store apps (though the Windows Phone SDK has ProductLicense.IsConsumable), but there is a type of workaround that you may find helpful, depending on the specific scenario.
However, support for in-app purchases of multiple different products is relatively simple to implement, shown in this article and sample:
How to support in-app purchases
Trial app and in-app purchase sample
I develop metro (windows 8, winrt) application for selling ebooks. I want to use Windows store as the payment processor to support Windows Store in-app purchases.
I am interested in next questions:
Can I add new in-app purchase products after my application will available on Windows Store without updating application?
(Or I will always need to update app when create a new in-app purchase product ?)
Can I add new in-app purchase product programmatically (dynamically) to Windows Store in-app purchase products list?
If I will add 100 new books every day - I will need every day add 100 new in-app purchase products?
Is there limitation to count of in-app purchase products?
You can always add new in-app purchases after your app is approved in the Windows Store; however, for your scenario it sounds like you might be better off rolling your own third-party payment system and using that instead.
That way you aren't bottlenecked by the Windows Store and don't lose a 30% cut (eventually 20% if your app exceeds $20k in lifetime sales, which includes in app purchases.) The trade off is that you have to convince users to provide you with some other form of payment information (PayPal, recurring billing on a credit card, etc...)
If you can tolerate the turn-around time of the Windows Store, that option would probably be easiest for you.
You should always update you app, but:
If you update only products - your app will be reviewed faster than
usualy.
Also, you can list some extra products. To have a some kind of
buffer.
I suggest you to ask your question here
we have created a publishing platform that is similar to Zinio,
We have a website where we upload magazines, and publish them to our mobile App on iPad
Apple is rejecting the App for the following reason:
Apps that use IAP to purchase items must assign the correct Purchasability type We found that the Purchasability Type for one or more of your In App Purchase products was inappropriately set, which is not in compliance with the App Store Review Guidelines.
Your In App Purchases are set to Consumable.
However, based on product functionality, it would be more appropriate to use the Non-Consumable In App Purchase type. Non-consumable products are only purchased once by users and are always available on all devices that are associated with that user's iTunes account.
We have Replied and Explained them Several Times the following:
We are using consumable type of in-app products since we have a lot and frequently released magazines with different prices therefore we cannot define the purchases to be non-consumable.
We have set pricing Tiers from $0.99 until $54.99 so that each magazine will be classified appropriately and assigned to a certain Tier.
our system has a lot of magazines where each one has many issue releases. Magazines issues are sold within an offer.
We have "single issue offers" (offers containing only one magazine issue) and "multiple issues offers" (offers containing multiple isses, eg: get 3 digital issues of magazine x for $19.99).
We are using the Tiers from 1 to 55 to assign prices for our offers. Note here that the in-app purchases are consumable but our system won't let the user buy an already purchased item another time.
The application will contact our server each time when the user attemps to buy an offer.
If the offer is already bought, the application won't proceed with the in-app purchase and the user will be shown that he has already bought that offer.
Anyone has an answer to solve this problem?
As apple is insisting that we should not use consumables and use non-consumables which is not logical, as we need to be submitting the app every time magazines has been added to the system.
Help is Much Appreciated
For magazines, you are unlikely to get consumable in-app purchase ability from Apple. They've made it clear in the past that the expectations for media, levels, and content of this type are expected to be present on all of the users devices.
However, based on your description of what you are trying to do, I'm not sure that this is a problem. Remember that consumables are not the same as subscriptions, in that a subscription gives you access to potentially more than one issue, whereas a consumable just means that is something that may not be available after you purchase it, I.e. that it might be consumed.
It sounds like the real problem here is a catalog issue. For episodic content, such as magazines, you don't want to hard-code your in-app purchases, instead look at the server-based model, as described in:
http://developer.apple.com/library/mac/ipad/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/APIOverview/OverviewoftheStoreKitAPI.html
With this model, your server can return a list of product identifiers that meet certain criteria, so you don't have to constantly update the app.