DTMF call mechanism is my app.To access the app's feature first the user needs to sign in. If the user is new without any account created he can even sign up. The reasons to get rejected are the following.
11.13
We found that your app provides access to external mechanisms for
purchases or subscriptions to be used in the app, which is not in
compliance with the App Store Review Guidelines.
New user registration is not appropriate. Please see the attached
screenshot/s for more information.
To be in compliance with the App Store Review Guidelines, it would be
appropriate to remove the access to these mechanisms - including fully
qualified links to your site that could indirectly provide access to
these mechanisms, such as links to web pages for support, FAQ, product
or program details, etc.
On occasion, there may be apps on the App Store that don't appear to
be in compliance with the App Store Review Guidelines. We work hard to
ensure that the apps on the App Store are in compliance and we try to
identify any apps currently on the App Store that may not be. It takes
time to identify these occurrences but another app being out of
compliance is not a reason for your app to be.
Please help me by giving a solution for this problem. It will be very helpful if I could get the exact reason for rejecting my app.
You are probably trying to sell something, that could be part of your app. For that you should use the IAP api, that means 30% to Apple. You should demonstrate to them that what you sell is not a part of your application or a subscription service.
The whole 11 chapter of Apple store guidelines is about purchasing.
You must be really sure that what you are selling cannot be "part" of your application or you need to use In App Purchase.
Can the user sign up within the app?
If not (if the user needs to open a site to sign app) that is the problem.
You should add a signup procedure inside the app.
Related
For last few days this cat and mouse game is going on between me and App Store Reviewers. And despite searching everywhere, I have not been able to find an answer to this question, so seeking help here.
I have submitted an app with auto-renewable subscriptions in it.
My app requires that users sign-in in order to see additional options, which includes subscription option as well.
App Store Reviewers keep rejecting my app citing this same text every time:
Regarding 5.1.1, we continue to notice that your app requires users to register with personal information to purchase non account-based in-app purchase products, which does not comply with the App Store Review Guidelines.
To resolve this issue, it would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices and provide them a way to register at any time, if they wish to later extend access to additional iOS devices.
We look forward to reviewing your resubmitted app.
Best regards,
App Store Review
What is non account-based in-app purchase products by the way?
I have also made it clear in my app what App Reviewer have asked above, i.e. make clear to the users that registering will enable them to access the content from any of their iOS devices. I didn't say iOS devices specifically, but said other devices since I'll have the same app on Android devices as well.
While I appreciate App Store Reviewers to help me improve my app, but I am totally lost here. I have submitted two updates to my app but every time it got rejected with the same reason.
Over this period I have also read their guidelines, read many similar cases online, but am still not clear what is required of me here.
Do they want the users to be able to purchase subscriptions even if they are not signed in? If so then technically how does this work? First it'll break the core functionality of the app since without registration I don't have user's info to create an account for them. Secondly how will I know which user purchased the subscription? I have to tie the subscription to the user's account on my backend. This means first I need to create an account for the user before user can purchase a subscription.
Please help me to get this right.
Currently I am waiting App Store's reply and my screens looks like these, with all other options removed when not signed in, and added text bottom of the Sign-In option, and help icon on top right of the screen where there is more information available for the user; and the one when user is signed-in.
If I would be a user of your app, I think I would find this behavior quite odd.
I would expect a login/registration screen when starting your app. If I decide to create an account, the Subscription button would always be visible within the settings.
However, there would also be an option "Continue without registration". If you do not create an account, the settings page could show some info text like "Some features are only available for registered members. Please tap here to create an account". Tapping the corresponding cell would show the registration page that is also shown when starting your app for the first time.
Maybe some users created an account in the past but forgot their passwort? Then they would not be able to restore their purchases, right?
Your login/registration form should also contain a "Forgot Password" option.
My app was eventually approved last year. The change I made was to remove the Subscriptions button from the Settings menu. And move it inside the user profile page. This means that user can see the Subscription option only after signing in and by going to their profile page. While this doesn't make sense to me, but that's how probably Apple wanted it. Subsequent updates to my app were also approved without any problem.
we are developing an iPhone app as an extension of a classifieds system (web site). On that web site users can buy (prepaid) credits and use them to boost and promote their ads. Will Apple reject our app if we implement consumption of credits? We are not gonna allow buying the credits, just using them (users will still have to buy credits on the web site).
Only worrying thing I found is item 11.2 in App Store review guidelines:
11.2 Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be
rejected.
Is there a way to contact Apple directly regarding this question?
And a add-on question. I suppose we can implement a payment gateway system like Amazon and Ebay and get a way with buying credits? I don't see any restrictions in guidelines regarding non in-app purchase system.
"In-app purchase" is only required to purchase content or extra-functionality or extra feature or to remove any type of limitations inside the application. To achieve these things you shouldn't use any other external purchase mechanism (per App Store review guidelines ยง11.2).
In your application, the user will only use the available credits which are already bought on your website, so there is not an issue, although you shouldn't provide any type of link to your website inside your application.
Genererally "will Apple reject this if..."-questions can only be answered as such:
Apple does as they like. If they feel this in some way breaks the review guidelines, they will reject it and tell you, but you have no way of knowing for sure until you have submitted the actual app. In your case, I can't see why they would ban it, as you are not able to use real money within the actual app, but as I said, you don't know.
If you want to try to get an answer from Apple, you can try to contact them from this page.
I finally got an answer from Apple. It took a while and it wasn't worth a wait. I think Siba was right, but I'll get back to you after we submit our app just to verify everything.
Apple replied:
Thank you for taking the time to contact us about your app design and concept questions. I understand that you would like to know if you
implement consumption credits into your app would be acceptable for
your app.
While we cannot pre-approve apps, we can address compliance questions
about specific App Store Review Guidelines or sections of the iOS
Developer Program License Agreement (PLA). I understand that this may
be a little frustrating and I apologize for any inconvenience this may
cause, however, we may only answer specific questions concerning the
following resources, unless the app is submitted for review so that we
may test the functionality.
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
The app we're working on in my company has been "almost rejected" this morning because Apple needs more information about the aquiring of user accounts and payment for the service our app provides. Here's the words from Apple (adapted, as I cannot include the app name):
How does the user acquire login credentials to APPNAME?
Is the service free?
If accounts are free is there an option to upgrade to a paid account in anyway?
That's the questions, now here's a description of what our app does:
We have an online service based on a website that allow users to upload pictures and a description from a pc, mac or any smartphone platform. This service requires a user account, which one buys from us. After that, the user can access the website, upload pictures to it etc.
But they're also able to login with their smartphones (android, iOS and WP7), making it possible to upload photos from the phones camera to the website.
What I'm trying to say is that the app it self is NOT the main product, the website is, and that's what the users pay for. The app is just an accessory that we've made available for free for the existing users.
But how do we write this to Apple in a way that they won't misunderstand, and reject the app because it must have IAP or something?
Hoping someone out there has some nice tips!
I think you will have to restrict the user from paying for anything via the app. Have a look at the following guidelines Apple impose:
Purchasing and currencies
11.1
Apps that unlock or enable additional features or functionality
with mechanisms other than the App Store will be rejected
11.2
Apps utilizing a system other than the In App Purchase API (IAP)
to purchase content, functionality, or services in an app will be
rejected
11.3
Apps using IAP to purchase physical goods or goods and services
used outside of the application will be rejected
11.4
Apps that use IAP to purchase credits or other currencies must
consume those credits within the application
11.5
Apps that use IAP to purchase credits or other currencies that
expire will be rejected
It's probable that you may have to remove the feature that allows users to sign up via the mobile devices (or at least the feature that asks them to pay) and use the app as 'just an accessory'.
Seems that problems with your application is that you are proving some username and password in your application. Now consider following case.
Someone downloads you application but do not have any account in your website.
-> Will he be able to make a new account from iPhone Application?
if answer is no then he has to go to your website to make a new account. and maybe there you will be asking for some payment. Thus it is not fitting apples policies because you may sell application from appstore and collect payment from somewhere else. So provide provision to make a new user account in you application.
Do your website allows to upload any number of photons free?
-> If answer to above is no then you must provide provision for making payment in you application also.
Apple's main problem is that your application has some possible way to access content(like Storage space in your case) which was sold outside apple store.
So find some workaround for that......
Good Luck
We intend to launch a free iPhone/iPad app on the AppStore.
The content will actually be accessible thanks to a subscription model (login/pwd authentication in iPhone app).
The subscription (about 100$ a month) is handled via a dedicated web server.
If used without subscription, this app will provide minimum value.
Does anyone know if this kind of subscription model can be rejected by Apple ?
I know some apps follow this model, but I'd like to have your thought on this before starting in this direction.
Thanks for your answer.
This is fine AFAIK - As long your app is free and you put in the description that it requires a subscription to whichever service. When you submit the app, you'll need to hand over details to a test account to Apple so that they can test it, but other than that it's no hassle at all.
I know of an app which works just like that on the app store right now - Spotify for iPhone. It's a music playing app which streams music from the web - but you need a Spotify premium account. When you first open the app, you have to sign in, and if you don't have a premium account it just tells you that you're not allowed in!
Javawag
There are plenty of apps which only work if I have an account somewhere, and some for which I have to pay for that account so, without knowing the specifics, there is nothing which immediately rules out your subscription model. There are even Apple apps, iDisk for example, which are useless if you don't have a $100 mobile me subscription.
If there are issues you can look at selling your subscription as an in app purchase (apple will take their 30% which should make them happy) or look at making the app more functional without the subscription.
Either way, when submitting for approval make sure to set up a sample account with a full subscription that the apple testers can use (there is space in the submission for including logins for this kind of thing).
Our app, previously approved, update was just rejected because we sell subscriptions through our website. (We have been doing this for 15 years, without giving Apple 30% of our money.) They are requiring that all subscriptions for iphone/ipad content go through in-app purchasing. I guess we will be looking at building a browser based app instead.
Cheers,
Gerry
Can iphone web apps be sold on appstore, without requiring user to do manual bookmark, etc?
Yes, you can create webapps and put them in the IStore under webapps
As per the page ...
To submit an iPhone web application, review the following guidelines, then log into the submission system using the Apple ID and password associated with your ADC membership.
You must be an Apple Developer Connection (ADC) Online, Select, or Premier member to participate in this program. If you are not a member, you can join for free and then return to this site to complete the submission process.
To be considered, you submission must meet the following guidelines:
You must agree to the iPhone Web
Application Submission Agreement for
all materials submitted for
consideration.
Your submission must conform to the
iPhone web development guidelines in
effect at the time of your
submission.
Your submission should have a
complete feature set (stable releases
and demos are preferred to beta
software).
Your submission (and the content
displayed in or through your
submission) must not violate or
infringe the intellectual property
rights (including trademark rights)
of others. You must either own all
rights to your submission and the
content displayed in or through the
submission or have written
authorization from the owner(s)
thereof.
You must provide at least one working
link to access your submission. By
submitting applications for
consideration to the iPhone Web
Application Submission page, you
understand your submission is subject
to review by Apple. Apple reserves
the right to omit, edit, or reject
submissions.
Just build a hybrid app. Hybrid wraps your html/css/javascript code in a native container which will give your app the ability to be distributed on an app store.
Technically, no. But you could potentially create a native iPhone app that just contains a UIWebView pointing to your mobile optimized site. I highly doubt Apple would approve this but I'm not positive.