I recently submitted a multiplayer trivia app to the app store. There are 2 versions of the app but they are essentially the same thing just for different trivia.
One app was accepted but the other rejected
Here is the rejected reason
17.2 Details
We noticed that your app requires users to register to access non account-based features. Apps cannot require user registration prior to allowing access to app content and features that are not associated specifically to the user.
My app has followed the process that is similar to other major apps like trivia crack and words with friends.
The user gets a screen to sign in with facebook or sign in with email. When they click on sign in with email it brings them to a screen where they enter their email. We then create an account for them in the app.
This is required so that we can keep track of the user in each of the games they are playing and who they are playing against we also keep stats for that user based on how many questions they get wrong and how many right, also how many wins. We are storing all of this on our webserver so that the user can also use his account on a different device so that they can play their games on their iphone, ipad, ipod and so on.
We ask for nothing other than email, and if we dont have them register then we cant maintain all this information for them, especially if moving from device to device. Again, this is how almost ALL other larger multiplayer apps in the store do it. I mimicked them exactly.
I dont get it. Plus, one reviewer accepted one of the apps and another rejected the other app.
Should I appeal?
Yes, you can appeal.
You can explain your position to reviewer, we had similar problem and after we've created appellation application was published.
Related
I have currently an app that through in-app purchases a user can unlock content on the app. What I have noticed is that some users "abuse" of this by logging with their Apple ID in multiple devices and I'm currently looking into possibilities on how to limit the use of the content to the device where the purchase was done. I understand that Apple doesn't allow that, so that means the payment system should go away from the app.
Therefore, introducing logging will help me to be able to identify the person that is using the app against a backend but still, I need to be able to limit on a device. As far as I know, the UUIDString of the CurrentDevice is not really a way anymore. What other options are?
I saw this library, which seems to promise unique identification:
https://github.com/fabiocaccamo/FCUUID
Another solution probably would be to create a licensing system, so one license can only be used at the time.
Thanks!
I will describe our experience with using same account on different devices (VOD):
User is able to use application on how many devices he want, but he able to watch content only on 5 uniq devices.
Each time user try to watch content, app check if device registered with some UUID, if not then try to register. UUID is uniq per installation, it mean that if user will watch content, then delete app, download again and watch, then he basically lose 1 device.
In same time user able to unregister device via web, but he had only like 25 unregistrations (I don't know what happened if user use them all).
We don't use in-app purchases and accounts are cross-platform (android, iOS, web, tvs, etc), so not sure if it helps you.
AFAIK, Apple does not have limit on how many devices you can user Apple Id. You can have 6 family members so number of devices could be lot more.
I feel it is bias how Apple's guideline talks about limiting music, movies, shows and books to 10 devices but does not say anything about Apps!
Apple - Family Sharing
If your family has purchase sharing turned on, music, movies, TV shows, and books can be downloaded on up to 10 devices per account, five of which can be computers.
I have not seen any application limiting IAP on devices. You could run into risk of Apple rejecting your app, potentially on every update you submit. I would reach out to App Store or if your company have Sales rep contact and get their suggestions/buy-in before spending lot of time and money.
Also, create issue/radar and give specifics about issue. More people request this feature, has better chances of it getting added.
One way you can achieve this is to keep track of receipt you get for IAP and check how many users/devices using that receipt. You would need to build entire flow to educate user about device limitations. Like updating App Store page, warning before purchasing, option to add/remove device and more...
If you are planning to implement device limitation, please beware of the rejection risk.
I want to let users of my iPhone app invite people from their contacts to a group they're creating. I can use deeplinks for people that already have the app installed to have an invitation automatically show up, but I was wondering if I can somehow pass custom information to someone downloading the app for the first time so after they initially open the app they'll have an invite waiting.
As far as I can tell this is impossible but I was wondering if there's any other way to somehow associate a contact with that person making an account on their own device. My application uses gmail authentication for account creation so if everybody had each other's gmails saved in their contact this might be possible, but that's not the case unfortunately. If I could get a user's phone number then it would be easy but I know that's not allowed without specifically asking the user.
Does anybody know if it's possible to do something like deeplinking for people installing the app for the first time?
You can do this with Google Firebase Dynamic Links. Google has a guide for this here:
https://firebase.google.com/docs/dynamic-links/
If I understand the question correctly, here is what I'd do:
Scenario: Send Invite
If the email invited by a user is a registered email, done.
If the email invited by user is not a registered email, store it in a separate table (pending invites)
Scenario: Sign up/ Sign in
User registers using email, store user information.
When the user logs in, check if email exists in pending invites table, if exists, present invitation.
Delete user from pending invites table
Not sure if you have it already but you might need a db table to keep the invitations sent by your users.
What you're describing is called Deferred Deep Linking (Deep Linking refers to using a link to open your app directly to a specific piece of content, and Deferred means that it works even if the app isn't installed first).
As you noted, there's no native way to accomplish this on either iOS or Android. URL schemes don't work, because they always fail with an error if the app isn't installed. Apple's newer Universal Links in iOS 9+ get closer in that they at least don't trigger an error if the app isn't installed, but you'd still have to handle redirecting the user from your website to the App Store. You can't pass context through to the app after install with Universal Links, so you wouldn't be able to present the invitation. Additionally. Universal Links actually aren't supported in a lot of places.
To make this work, you need a remote server to close the loop. You can build this yourself, but you really shouldn't for a lot of reasons (not the least of which being you have more important things to do). Free services like Branch.io (full disclosure: Branch is so awesome I work there) and Firebase Dynamic Links are designed to solve exactly this requirement, and can handle all of the backend infrastructure for deferred deep linking so you don't have to. From your perspective, as the developer, you'll seamlessly get exactly the same data to work with whether or not the app was installed when the link was clicked.
It would be appropriate to include significant account-specific features from Amazon and not just an authentication method in order to be in compliance. You may also implement your own optional registration, iCloud or Game Center as another option.
Great Apple rejected my game 6 times due the above reason, first of all, they rejected my game because they said it need a user registration to save purchased data even if user changed the device and they can access all purchased things if he have a registered user id with the game, i done the user registration using amazon login sdk, and three other games approved with the amazon login, but this game rejecting showing the above reason., is there any sample login view form for cocos2d for user registration? i dont know how can we do a login with iCloud or game centre. all i want to do is a simple login form for cocos2d.IS there any samples out there how to make a login form using iCloud or game centre ,, i have some ,but they al are native iOS sample, cocos2d samples is not there.
hope anyone can help me to get rid of this situation.,
In an iOS application, When I detect a users improper action (for example posting violent content), I wan't to suspend the user from using my application. The basic idea to implement this feature is to create and save an unique id for each application installs and suspend the usage from server api's.
My question is, how can I implement this feature even if the user re-installs the application, and still pass the Apple's iTunes submission?
I came up with two ways to technically implement this feature, but wondering how Apple would respond.
Store the IDFA (I understand that users can reset the id on their behalf)
Store an app generated udid to the Keychain (which should not be deleted even if the user deletes the app)
I know there are no perfect answers, but would appreciate to discuss this issue with anyone that have tried submitting a similar application, or anyone that is well aware of the Apple's guidelines. Thank you.
Apple will reject apps that inappropriately use the IDFA.
If your app does not use server login (at which point, whatever flags you require could be delivered to the client), keychain storage would be the only real solution.
However, if you don't use server login, you block the device, not the user. Is this your intent?
BTW, without server login, a determined user can still get around keychain storage: Reset keychain on the device
You can block a given account. Most people these days key an account with an email address. Some require a credit card (Facebook fully validates accounts using credit card numbers), others require a bank account (PayPal has to send money somewhere!) and it is growing in popularity to request a phone number (Twitter is getting there). In the end, to really be effective, you have to block something that is difficult to produce.
With email, your users can always create a new account. Check out mailinator.com. Alternatively, all you need is one domain to have as many email addresses as you want -- I use five different email accounts daily, and I use about two dozen more on a monthly basis.
Installation ids are ok but users can always just uninstall/reinstall. And if you do manage to get a device-identifying number (easy to do really, even in the post-UDID era) so that you can block a given device, your users can just get a new device, or hack your app to use some random value, or spoof your API with cURL. I own three iPhones, two iPads, two Samsung tabs, three other Android phones, two Mac Book Pros, a mini, two PCs, and I run three virtual Linux boxes, and one virtual XP box. And what happens when somebody sells a blocked device to a non-abusive user?
So just block the user's account, keep excellent log files, and keep fighting the good fight.
I have a website which offers (FREE) account based services. Iam working on a iphone app for the site. Can somebody help me with these questions?
1) Registration: In my case, the app is meaningless without an account/registration (all free). There is a lot of chatter in the internet that apps that do not offer a "registration-free" experience will be rejected. (example : http://readitlaterlist.com/blog/2010/08/version-2-2-rejected-new-rejection-reason-from-apple-may-have-major-implications/) Thoughts?
2) Email Verification: On my website, a user has to "Verify his email" before he can login.
Basically, can I do this one time only thing in my app: (a) ask email -> register (b) ask user to copy verification token in email & paste in the app (c) Hit verify & let them inside the app upon success. Is this alright?
3) Is it against Apple's rules if the iphone app only supports existing users(who already signed up via website & have a user name password)? This way I need not worry about 1 & 2 for now & still have a full fledged app.
Please note that I have read the guidelines but still cannot come to a conclusion.
I am aware that "will Apple reject my app" - is a question nobody can answer
All I am looking for is your opinion based on your prior experiance & your interpretation of guidelines. Thanks much.
UPDATE: To all users who land here: Apple approved my app few weeks ago. All I did is explain(in review notes) that my app is truly account based & would be meaningless without an email. On my home screen, I have 2 buttons, "I have an account" & "Create an account". There is no registration free experience other than a series of graphics focused on "what is " & indirectly emphasizes that it is an account based appln. Apple seem to be convinced & approved the app the first go. Hope it helps.
I made an app that sounds very similar to yours. I host some websites that are basically forums (they require registration). So my app is an app that allows the user (once they have logged in) to read, post, edit profile etc. Without logging in they get nothing, they see a login screen/Signup button. Which takes them to a form to sign up, it then sends out an email and they approve it via the link it then allows them to login. So as you pointed out No one can really tell you if your app will be rejected or by apple, but my app was very similar to yours and made it through just fine. Also think about a service like Spotify, gmail, or facebook. They require the user to login/register before the app works at all. I believe these rejections dont come from the fact that they are requiring users to login, but they are making it difficult for them to login in or they did not have a website that this was tied to, they just want the user to login to use the app. Its a very fine line, and again apple will be the judge of this in the end.
*Apple very well could have changed this since I submitted my app, but this is just my experience.
In general this sounds fine. The most important piece of advice I can give you is to make sure that you create an account for the reviewers to use - use the 'review notes' box to give them a login and password so they can type it straight into the app. You'll probably get rejected if you don't do this (reviewers dont' have time to check out your site, sign up, wait for the email, click .. etc).
EDIT: Also you should ensure there's a link to the registration page on the web from the front-page of your app (or at least somewhere very obvious).
If your submitted iOS app requires email verification from within the app for the app to function, this sounds it could very likely be a strong reason for a rejection by Apple (apps are not allowed to require personal identifying information.)
If your app requires a pre-existing login/password, and you give Apple a pre-existing fully functional working login for review purposes, what any user has to do to get this login outside and before running your app may be outside Apple's purview (for instance, joining some club or professional organization, opening a bank account, etc.).
But the only way to know for sure is to submit an app for review by Apple.
Our empirical knowledge is that we had submitted a fully featured app with more then one reasen to get rejected. One of them was, of course, that we enclose a way to get balnce in the app without using the IAP (https://developer.apple.com/in-app-purchase/) from apple. That thing was a killer. I think, because of this feature, the reviewers told us even more reasons to get rejected. One was the signup button in the login screen. After we disabled the topup and the signup feature, the review was fine and we're happy and online. Since that rejection, over a year ago, we had never tried to enable signup and upload it again. Now, we'll do that and I will report here what is happaning...
Update #Ravi Jul 31 at 16:18
It's like what I said! We're now online with a singup button at the start screen of the app. Apple does not disallow it. FYI