Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
In my app people can send each other virtual gifts which they can use within the app.
Gifts can be purchased using Coins.
Coins can be purchased using Consumable in app purchases.
I am storing everything on my server.
Here is what I got from apple.
As indicated in the previous correspondence, your app includes "gifting" feature allowing users to send virtual gift using the purchased Consumable coins and the recipient can use the received item.
It would be appropriate to remove gifting feature from your app.
There is nothing in the AppStore Guidelines regarding "gifting" features. Can someone shed some light on this matter ?
How can I get my app approved while keeping the Gifting feature?
I think, one better solution.
a) you use Terms & conditions page in your app and explain all things.
b) include two things in `Terms & conditions page
1)include an explicit statement in the contest or virtual gift using rules that specifies that Apple is not a sponsor nor is involved in any way
2)insure that the contest or virtual prizes are not Apple products; using Apple products as prizes suggests an inappropriate association with Apple.
I will suggest you to ask them in Resolution Center why should I not use gifting feature in my application as I am following HIG ? Then they will elaborate in more details the reason of rejection and then if they tell you valid reason then you will have to make changes in your app otherwise they will accept your app.
Hope it helps you.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 4 years ago.
Improve this question
My App was just rejected with a reason:
“You have selected the Kids category for your app, but your app does
not appear to be designed specifically for kids aged 11 and under.
Specifically, we noticed that your app is a CRM app.”
Actually, no terms or conditions can be found in App Store Review Guidelines that indicate how I can solve this. So funny. I mean, I didn't select "Made for kids" and my app doesn't contain violence, horror, sex… so my app is rated automatically for Ages 4+. ¿?
Update
I uploaded a new binary and added new lines of codes. The app has been approved.
if SKPaymentQueue.canMakePayments() == true {
// Your subscribe code here
}
I guess it checks if the user (a kid) could make payments or not because the parental control is activated.
As per rejection reason its not looks like its rejected due to that ratings or selections on above image you said.
Its rejected because might be you have selected Kids or relevant to kids category or subcategory. So that is what it causing the rejection.
So the possible solution is make sure in your application selected category or sub category should not be kids or relevant to kids.
Still if it not works than you can ask for the more clarification under the rejection comment. By this way either they will give clarification or app will directly go into the review status & again & will get approval.
Note :
The above solution I have given as per the experience of uploading 150+ apps & resolving 50+ rejection issues.
Hope it will help you.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
My App is rejected by the reason :
"We found your app inappropriately unlocks or enables additional functionality with mechanisms other than the App Store, which is not in compliance with the App Store Review Guidelines"
"It may be appropriate to revise your app to use the In App Purchase API to provide content purchasing functionality. "
What I have done is as below:
As this app is for my specific customer companies to use, I only want the companies who get the Invitation Code from me to use my app. There is no charge. I don not know is it necessary to use the In App Purchase API instead? if it is true , can you give me some tips?
Your application cannot be used by members of the general public, and thus does not belong in the App Store.
If you only intend your application to be made available to a few specific people, you should use Ad-Hoc Distribution to make it available to them.
Explain the purpose to the review team, sometimes they listen.
Also, maybe have that message as a "login page" instead. Have a username and password rather than a verification code. The verification code message may look more like you are selling the app behind the AppStore. Also provide the review team with an access code / login details if you haven't already so they can actually review the app.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I developed an app for the company who sells professional e-books by their website. In order to keep the content in sync with web data, app enforce login/registration and without that doesn't provide any functionality.
This is the reason why it has been rejected for Review Guidelines 17.2 Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
My question is: is there a way to convince Apple to accept an app?
It is directed to the very specific proffessionals.
In the future the company want to add the possibility to sync books available on their website.
Also the books bought by in app purchase would be available on their website for the user account.
Isn't that enough reasons for Apple to accept this app? My client strongly want to have an account based app, the whole system was designed for that.
There is possibility to track user by udid but still it is not good solution because it is deprecated and Apple rejects apps using UDID for tracking reasons.
Does anyone have similar situation recently?
You say:
"app enforces login/registration and without that doesn't provide any
functionality."
Apple says:
"Apps that require users to share personal information in order to
function will be rejected"
So the answer is kinda obvious.
The app should provide (at least) some basic functionality without sharing personal data.
Maybe some book previews? 1 or 2 free books? App info? Why not apple's-bookstore? Does the website (before seeing anything) force you to signup too? Otherwise just make a web-app.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
My app let the user input very specific types of data, and offer online synchronization. To use the app, you must pay a subscription (auto renewing subscription in-app purchase).
However, I would like to include a free trial. I cannot use the free trial option of in-app purchase products because this is only allowed for newsstand apps (according to WWDC 2012 session videos, session 308 "Managing Subscriptions with IAP")
Here is my idea of workaround to achieve similar functionality :
The user creates an account on my app
This account is given a short free subscription for testing the app. Subscription is managed server-side. During the trial, there is no restrictions on the app
When the trial is over, the user will not be able to insert new data, or sync with the server. He will be prompted to subscribe to continue using the app
I have a doubt if this is acceptable for the App Store. Any ideas?
Thanks
Technically that would work but two problems arise:
One: if you don't use in app purchasing then the users can't buy your service from the app (its in the dev agreement)
Two: if you do use in app purchasing then you trust the IOS devices to say "hey I just bought one year service so hook me up" one could hack this http://zd.net/LkY9Ra and make your server give service to illegitimate users. Will this happen? not likely but it can.
Kinda sucks apple forces developers to a clearly flawed model
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I would like to do the following:
Sell a game for $0.99 at launch with no feature restrictions.
If it's less than successful, make it free, but limit some features to in-app purchase (I would do this via an update to the existing app).
BUT, I would like users who originally purchased the app (before it was free) to still have all of the features. In other words, I want to find a way to credit the new in-app purchases to those users, so that they don't have to pay twice.
I would like to do this all with the existing app, instead of making two separate versions of the app (paid and free).
EDIT: it is essential that not a single user ever have to pay twice (i.e. that users who previously paid for the app, do not have to purchase the in-app upgrades in the future).
EDIT 2: It seems like this question has already been answered here: From Paid to FREE w/IAP: Preventing double-charging
Certainly.
The company I work for has done this in the past.
If you know you might want to do this in the future, in your first version store a flag to NSUserDefaults indicating that the user has had the paid version. Then, on your In-App version check this flag and provide the content immediately.
If you already have a version released, you may have to look for something that you are already storing, e.g. the user has a highscore greater than zero to indicate that the user has already purchased the app. (There will be a small number of users that may have downloaded the app but not opened it and these users may be charged twice).
Yeah, it is. Before you Update your app with FREE version, you add all users that have paid for it serial number "PAID"(or something), and everything else is just conditional statements(if-else). Congrats!