Apple just rejected my app saying the following:
"Upon further review, your app's previous submission was improperly rejected for 11.1. Since the sensor functionality of your app is dependent on the associated hardware, it would be appropriate to offer the sensor functionality to all users through achievements or In App Purchase."
Does this mean, I should resubmit the first version because it was ok?
If not, do I have to implement achievements from the Game Center, or what kind of achievements do they mean?
Any thoughts that can help me to get this app on the App Store?
Thank you
Additional information:
first version
In the first version I had "a kind of"-achievement, where users can provide a code they receive with the purchased associated hardware. And they could buy this functionality if they wanted to test for example the device of a friend or a public one.
Rejected: Because they claimed that the user can bypass the purchase of the function by providing a code.
second version
In the second version I took out the In App Purchase because we do not want that our clients need to pay again.
Rejected: see above.
From my experience with the App Store I can say that except for some definite rules (no pornography, hate speech, etc...) most of the review process and decisions are ambiguous and inconsistent.
In fact Apple's App Store policy is vague on purpose so they can exercise a bit of freedom with App rejections. However, from my own anecdotal experience and research, they've always been fair. I have yet to come across an issue where they've rejected an app without having a valid reason for it.
In your case, I believe your app was rejected the first time around since a user could bypass a purchase through purchasing something outside the App Store environment. This means you could sell your code without going through in app purchases and having Apple get its 30% share. This will most likely get rejected again if you submit it.
I'm a bit unclear on what happened with the second case..
Related
I'm implementing IAP for SaaS application. I nearly finished with Store Kit's integration, receipt validation and other development related stuff. But I still have 2 more questions regarding Apple's guidelines which I couldn't find answer to on the docs.
The first question: I read on few places on the web that my app should provide minimum functionality even if the user is not subscribed. I offer a SaaS app and I don't want the user to be able to use the app if he's not subscribed. I will allow him to purchase a subscription if he is not subscribed. Is it enough for minimum functionality? (I suspect that these minimum functionality restrictions are old and obsolete, as they sound absurd).
The second question: I want to offer the user a possibility to try the app for free without subscribing at all (Without Store Kit's Free Trial option), because I don't want make the user make a commitment to pay before he tried the app (Apple also doesn't provide a convenient way to cancel the subscription, which may cause abandon-users to be charged even if they don't use the app, which will cause bad reviews etc). So the question is, can I do this without risking my app to get rejected? Does apple allow such kind of Free Trial feature which is managed solely by my server?
Forgive me if this info is somewhere on Apple's docs, but I couldn't find anything related. Thanks!
Okay after sending a query to Apple (Which didn't help me much to understand) and submitting an app to the App Store, I may have an answer:
Apple do allow SaaS apps and did approved my SaaS app. I honestly don't know if they checked my app enough to tell if it is okay but it was approved.
My app implements the Free Trial mechanism without App Store's free trial option. It is clearly written on the registration view controller that the app offers 3 month of free usage without obligation, and then continues without popping and App Store free trial page or something. My app was approved so I guess it is actually okay and within Apple's guidelines.
Hope it'll somehow help someone.
Concept on howto maintain a trial and purchasable full version of an IOS-app today:
There are lots of dicussions on this topic, but I would like to look at this for my case and how it would be designed TODAY (2015), with actual Apple restrictions.
I have an app which initially loads data from the internet to be displayed. (Trial-Content -> 80MB, 20%, Full-Content -> 400MB, 100%)
I would like to offer the Users to try the app with limited content first.
With limited content: 20% works as like the fullversion. 80% are marked with a question mark. If the users clicks on the question mark I would like to guide the user to the fullversion.
I prefere to have 2 apps (2 builts), because of having 2 separate rankings. Users, which buy an app are rating better, because they are really interrested in the app and will only buy, when they are pleased with the trial app. So an app with inapp purchase has a lower ranking in avarage then a isolated full version (built). But I guess this concept would be rejected by apple, because you have to mention the fullversion in the trialversion and you have to name the trial version as "trial" ? (Sorry for the bad english)
How will this be designed with IOS apps ? Howto guide the User to the fullversion, without beeing rejected by Apple ? (I read popups like "Would you like to purchase the fullversion?" will be rejected. )
In Android I did the following:
I created one app with the full functionality, which is at the same time the trial-version.
I created one purchasable app, which is only an unlocker app.
The trialversion app checks if the unlocker is installed. That way I can differentiate between trial and full and will load the corresponding content.
When clicking on the question mark, I will show a popup saying "Would you like to purchase the full version?".
This is quite a common pattern, you just can't call your "trial" version "trial". Quite often such versions are called "light".
To send the user to the app store to buy the full version you can use the SKStoreProductViewController to display the app store page for your full version directly in your app. This should be OK with Apple.
Your Android solution with the paid "unlocker" app would be possible too. Your apps need to expose an URL scheme and using that you can check if the other app is available. They also could use an app group to communicate. But this will most likely not pass review as apps must do something useful by themselves. They will probably test your unlocker on a device that doesn't have your other app installed and immediately reject it.
I would strongly suggest to reconsider an IAP for this. That's basically the ideal use case for it. You must not be afraid of bad reviews for offering purchases. Trying to send the user to buy another app will probably give as many bad reviews if not more. The IAP flow is much more user-friendly.
As #Sven suggested IAP is recommended in your case.
If you want to maintain two different apps for trial and full version, you can give your trial app name as "APP NAME FREE", I think Apple will not reject the app with name "Free" in App name (I successfully uploaded free and paid versions of same app with this trick).
We have a print magazine and we're going to release an app with subscription model, sort of kiosk app but with extended functionality.
Well, what we want is to solve the following cases:
Case 1 (complex)
User buys a print issue and discovers a promo code in it. This code should allow user to download free digital copy of this issue from our app.
User launches the app, opens a dialog box where he can enter the promo code.
Voila! User gets his free digital copy of purchased print issue.
Digital issue always remains in his list of purchased issues and is a valid purchased issue with all App Store options available for them (restore, etc.)
Case 2 (simple)
User does not have a print issue. He launches the app and buys the same digital issue using IAP.
So, both issues are the same (i.e. "blablabla magazine", November, 2014) but 1st was downloaded using a promo code, and 2nd was purchased with IAP, and they both should have the same properties and "weight" for App Store.
Problem is I don't know if this model will be approved by Apple. Or, if they do, how do I develop this? AFAIK, list of purchased and non-purchased items is provided by App Store and there's no way to intervene this process.
I didn't find any samples of using 3d party promo codes in iOS apps. Can anyone provide a solution for this, please?
Thanks
To keep a record of the promo code usage, I think the simpliest way to do it is to require an account. Once the user is logged with his account, you can tell a server that the promo code have been used with that account. If the user delete/reinstall your app, you will be able to restore all his promo codes from his account.
For your issue with IAP and promo codes, here is the App Store Review Guidelines
See the 11.16 section:
Apps may enable additional approved features or functionality when
used in combination with specific approved physical products (such as
a toy) as long as the additional features and functionality are either
completely dependent on such hardware (for example an App that is used
to control a telescope) or also available through the App without the
physical products, such as by way of reward for achievement or by use
of IAP
So basically, what you want to do shouldn't be rejected.
But by experience when you do something that borderline with Apple's money (possibility to "undercut" IAP), you should expect a review failure, whatever the guidelines review says.
Keep in mind that the guidelines can be interpreted in your advantage, or in you disadvantage.
I am working on a mobile iOS app that is customized to each client, with their own app icon, startup screen, and a few other changes. Each is then submitted to the app store as an individual app.
This is working just fine so far, but what will happen if there's 1000 clients instead of around a dozen? Does Apple have any rules on quantity, submission rate or uniqueness? Any reviewer would clearly see that the apps are basically the same outside of the branding.
Don't do it. You will get kicked out of the appstore.
Read 2.20 of Apple iOS Guidelines which says that developers that spam appstore with similar apps will be kicked out completely!
Notably developers like AppGratis got kicked for this and many others reasons.
Sorry can't disclose, if you have a developers account though you can check the requirements
from https://developer.apple.com/appstore/resources/approval/guidelines.html
I know this is an old thread but somehow it popped up and the answer selected is not entirely correct. The requester needs the custom B2B program here:
https://developer.apple.com/programs/volume/b2b/
That is specifically made for the purpose she/he asked about: to distribute customized apps to a business without cluttering the app store. There is no cost but your customers will need to join the Apple Volume Purchase Program for Business though that doesn't cost them anything.
The reason I say the accepted answer is partially correct is because obviously one should not spam up the app store with similar apps intended for one business, which is entirely correct. But that does not answer the underlying why they wanted to do this and how they could achieve the result they need which is to use the B2B program.
For these 2 rules:
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.
Is the applicability of these rules reduced/removed if the enablement/disablement of the features/functionality (11.1) or the content purchase (11.2) does not actually occur within the app on the device.
For example, you write an app that requires free registration but if you visit a website outside of the app (and not linked to from the app) to "upgrade" your registration (by paying money) the app gains some more functionality or content next time you use it.
Thoughts?
My thoughts: you'd be violating the guidelines, but your app could get approved, of course. The payment does indeed not occur inside the app, but the application "utilizes" such a system (which is very broad) thus is in violation.
This reminds me of the Newsstand/subscriptions discussions going on before. Basically, if you offer something outside an app, you have to make the same (or better) offer inside the app (via IAP subscriptions). Perhaps this is applicable in your case, too. Although, according to 11.3, you may not offer services outside your app if purchased via IAP (so you may not unlock features on e.g. a website too.)
You'd also try and offer a free app. Once users (somewhere, somehow) upgrade their account, they can access the members only app, a new, separate app. But approval is still questionable, which brings me to my last part:
"We will reject Apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll know it when I see it". And we think that you will also know it when you cross it."
— https://developer.apple.com/app-store/review/guidelines/
In short: submit, pray and find out.
What you describe sounds similar to the situation that resulted in apps that used Dropbox being rejected (Link). Apple determined that since the apps that used Dropbox functionality required the user to visit the Dropbox site to sign up those apps were in violation of those rules and were thus rejected.