All,I am making app for reminders & its kind of social reminders. I can share my reminders with my contacts. I want to make it like whatsapp. Can we use user's mobile number for this purpose? Or will apple reject it? Please tell me more, if anyone has done such app before?
Thanx.
You can ask user for any information, no matter how personal. In terms of Apple guidelines, here's a few things to bear in mind:
asking is fine, but taking (via a hack or whatever) will get you bounced.
the ask has to be essential to the service the app delivers. in other words, it's perfectly okay for a retirement calculator to ask about how much money user has in the bank, but not so okay for a tic-tac-toe app.
editorially, be very clear and honest about how you'll use the information (Apple might not catch you here, but you should do this anyway to motivate the user's answer).
the app must remain functional even if the user opts not to provide the information. for example, the retirement calculator should supply a default bank balance and carry on.
Related
I'm in the process of making an iOS app. This will be my first iOS app. It is based on making phone calls using calling cards. The customer will buy the calling cards in the real world and they will get a pin which they would need to enter in the app. Through this pin they will get the credit to make the calls.
I went through the submission guidelines. Usually when a app requires the user to buy something from with-in the app, then IAP is used but here the purchase is being made in the real world, without using the app. Do I need to integrate IAP into the app? Will Apple accept the app into the app store?
Any help is appreciated.
Thanks
As your requirement suggest
The customer will buy the calling cards in the real world and they will get a pin which they would need to enter in the app. Through this pin they will get the credit to make the calls.
It means you are dealing with somewhat physical stuff like customer will buy the calling cards in the real world so at that time he/she must have to pay something for that. so there is no need to integrate IAP in this scenario.
IAP is only for the stuff/service that will provide within the app by service provider. for physical service you can exclude the IAP. if you give proper description and explanation to apple when you submit your app for the review apple will definitely approve it
hope above answer will help you
I think you're in a grey area because it all depends if Apple thinks the credit is consumed in the app. If considered consumed in the app, you may have a problem. Try to find another iOS telephony app that uses cards, one that's well know enough to be sure that Apple may have had a good look.
If you'd give users game credit with physical cards, it's clear that Apple would not allow this.
What makes this a grey area is the telephony side: If it's a VoIP app you could argue that the the credit is (partly) consumed while using the app. But you could also argue it's outside the app on the VoIP/telephony network.
If it's not a massive investment, I'd try the calling card route first.
You could try ask Apple, but you'll probably won't get a clear answer as they want to see the app first. I've tried this a few times in the past. Makes sense because they don't want to make promised based on what you write in an email.
I have been extensively searching through Internet but I could not able to come across so far then I have decided to ask the following question in SOF.
My idea is to implement a selling and buying product in my application. There will be no charge from both sides(seller or buyer). However, I only want to receive user feedback to increase my app reputation in the AppStore.
I would like to know how to check whether or not that an app user rate or leave comment for my application in the App Store. I need to know because I want to give him more advertising opportunities within the app.
Sorry again, I wish to provide a sample code but I could not able to come anything to start with.
As far as I'm aware, there isn't a way to do this. Most apps just direct people to the app store and then assume they rated the app. You can have the user copy and past their review into your app and store it so you can double check that they actually did it. That will ensure more people don't try to cheat the system. Essentially, the more work you make it to unlock the feature, the less likely people are to cheat.
From Apple via #Paulw11's comment:
Developers who attempt to manipulate or cheat the user reviews or chart ranking in the App Store with fake or paid reviews, or any other inappropriate methods will be removed from the iOS Developer Program
link: https://developer.apple.com/app-store/review/guidelines/#metadata
Preface:
I know this issue has been raised here before on SO, but those posts are old and I believe not currently relevant to Apple's decision making.
Rejection reason:
17.2 Details
We noticed that your app uses Facebook login for authentication purposes but does not include account-based features offered by that site, which is not allowed on the App Store.
Next Steps
Please modify your app to include account-based features of that social network or use your own authentication mechanism.
My App:
My App implements Facebook authentication and grabs the user's first name and profile picture only and displays them at the user's discretion (when the user performs a certain function).
I stated this to Apple twice and they replied that this was not enough.
They kept parroting that I needed to add "account-based features" of Facebook. I asked them to elaborate and these were the examples I was given:
"It would be appropriate to implement friends lists, social graphs, and game scores when applicable. "
So these questions arise:
What if my app doesn't benefit from the above examples?
What's wrong with using Facebook as an authentication method and for grabbing basic data?
And the kicker - what are more examples of "account-based features" of Facebook that I could implement that would qualify for the privilege to use Facebook authentication?
I'm sure I won't get any straight answers from Apple, so I am appealing to the experts here to hopefully enlighten me.
Thanks in advance.
Based on my experience with the Apple Review Process, what bothers them most in this case is:
If your app "forces" the user to login with Facebook and doesn't allow him/her to login any other way (or not login at all).
If your app has no "account-based features" as they indicate in their rejection details (even if these features are not specifically related to Facebook.
Things you can do to pass the review process without damaging your app's user experience:
If you don't already have an option to use the app annonymously or login with an email address or any other non-Facebook method of authentication, you should definitely add one. Not only will that increase your app's chances of being approved by Apple, it will also provide your users a way to try your app without providing you with their Facebook information. A lot of users need to gain trust in an app before logging in with their precious Facebook account, so this can actually help your on boarding process and is highly recommended.
Add some account specific features to your app. It doesn't necessarily have to be Facebook specific data. It can be anything that will convince the review team that you're not just collecting data about your users, you are also providing them with some sort of benefit because they logged in. Examples for this can be game related features, like Apple suggested: score count, leader boards, friends list, invitations, rewards, chats, etc. It can also be non gaming related. Things like: content management (allowing the user to save data based on his/her account and accessing it later, "liking" certain elements in the app, saving app related content in one place, sharing content on Facebook, etc.
The best thing you can do (if it works for your app) is just find some significance to a "user" in your app. Something that will give meaning to the user's having to login. If you have that, even if it's not necessarily Facebook related, you should be good to go.
An example that can be good for both the review team and your app's chances of going viral, which is relatively "cheap" to implement, would be to add the ability to invite friends to use the app. This would justify logging in with Facebook and give your users an extra value. However, I would highly recommend not forcing the user to login unless it's absolutely necessary. Let him/her learn about your app, learn to love it and then, when he/she trusts you and is willing to "commit", then you give them the option to login. When it comes from them and not because they had to, the chances of your user feeling good and safe about logging in to your app, is significantly higher.
I hope this helps, even a little. Good Luck!
I had the same problem and I told them about the UI experience and basically the issues you mentioned. They approved it shortly after I explained it. When did they approve it? About 8 hours ago. So while I do think Apple is still strict regarding these requirements, I do think they are understanding if you can explain yourself well.
The changes I made:
Added a HUGE "login anonymously" button, to make it clear you don't need to login to use the app.
The app was for "voting" for businesses, and I said that logging in with Facebook is the best way to accomplish this without killing the user experience.
This worked for me. Hope it helps. But I think the bottom line is, if you use Facebook connect for authentication and you are using it in a good and valid way, then Apple will most likely accept it.
Good luck!
Our app has its own costume photo album that we are taking from the assetsLibrary.
This photos are sent to another user via server.
I have read that i need to get a user permission to get into their album, is it right? Isn't it happen automatically? seems there is some confusion about it. Right now I am not asking permission, but its pretty obvious because the user hit button to get into this album, and pick photos.
Second, when the app starts, we send lots of data to server, with sockets-tcp such as iPhone name, version, and some other const number from the software.
Does it require the user permission?
If the connection using encryption ssl, do we need apple's permission?
I believe you do need to get the users permission. Recently after the whole mess with congress and all the privacy breaches for collecting users info by some of the developers apple informed the developers that a notification for accessing personal info of the users is required. That is the reason you see any app that is trying to use the photo album or the contacts of the user are equipped with a pup up notification that the app is trying to use your photo album EtC ETC. it is being practiced widely. So I would say just plug in UI alert and ask the users permission. It is a good idea to stay safe and away from this legal stuff. That's my opinion.
To answer your second question, no you don't need apples' permission to send those data to your server.
There are technical answers and there are legal answers.
For the legal side of this, you would do best to consult with a lawyer. There's a lot of potential privacy issues at stake, and a web of laws you may need to wade through, especially when you consider international issues (depending what App Store you're going to sell your app in). Plus how say the interaction of user in one place interacting with server in another place (e.g. crossing countries) could come into play. Yes, find a good lawyer.
If nothing else tho, consider the backlash that occurs when "tracking" of user information and behavior happens without letting the user know. When they find out (not if, when), do you wish to bring ill-will to your app and to your developer/company reputation? Often it's better to be up front and explicit. Allow the user to choose what to do, even if that means choosing to not use your app.
As for SSL, you don't need Apple's permission, but use of encryption CAN have implications upon store submission and distribution. This is covered extensively in Apple's store documentation. Check the FAQ's within iTunesConnect as well.
So I know that there are no promo codes for in-app-purchases in iOS. What I am wondering, is will Apple reject this mechanism:
Provide two in-app purchases, one at full price, say $9.99 and one at discount price say $7.99 (for the same thing)
When you click on the $7.99 one, you are first asked to input a coupon code to be allowed to use the discount price. This discount code would have been found elsewhere - bloggers giving it away, coupon sites, etc.
Thoughts?
I believe your proposed method would work because a) you are not linking to an outside site to purchase the product (i.e., you are still using the App Store iAP method) and b) there are other programs that use similar features (e.g., entering in your OpenFeint username to enable that service).
Good luck!
I really think only Apple can tell but it is a good chance that it is okay.
I sometimes just went ahead and called them and often I was lucky and had a real competent guy on the phone telling me answers to stuff like that right away sometimes I had someone more cautious but pointing me into the right direction within the legal contracts. And whatever they said at the end the very much shielded app approval team (no phone numbers, no e-mail addresses) will decide. The worst that can happen is that you have to resubmit your app without it. Costs you time but no more.
I always used this link for phone numbers I think they still work.
I had same problem... so I called to the apple developer IAP helpdesk and they redirect me to email the App Store Review section.
Next day they wrote me:
We understand that you would like clarification about a business model you are developing for your app.
We are unable to provide pre-approval or guidance on app ideas or concepts. After you have submitted your app, we will provide feedback during the review process, if applicable.
So I wish you luck... There is no one clear option 😔