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.
Related
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
I got my app rejected because it had a registration form that required too much information that the app never used. The simplest solution would be be to remove the registration and just let the user login inside the app (it can also be used without login but with less functionalities). What I was thinking was to remove the registration button and just add an UILabel where I tell the users that if they want to register they can visit the site (I won't provide a link for registration).
Does anyone know if my app is going to get rejected again just for telling the user to register on the site?
This is the reason Apple review team gave me:
17.2 Details
We noticed that your app requires users to register with personal
information. Apps cannot require users to enter personal information
that is not relevant to the app features.
We've attached screenshot(s) for your reference.
The screenshot was of the registration form that required some informations that weren't used inside the app.
The message in App Store Review Guidlines is quite clear:
Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
which, of course does not stop you from asking for it while letting the user register, however - you MUST have a good reason for it, like:
Apps may ask for date of birth (or use other age-gating mechanisms) only for the purpose of complying with applicable children's privacy statutes, but must include some useful functionality or entertainment value regardless of the user's age
OR
Apps that include account registration or access a user’s existing account must include a privacy policy or they will be rejected
So my guess is that they think your registration is slightly fishy. I would suggest really making sure that the reasons for collecting that personal information are very visible to the Apple reviewers. They probably thought that your reasons for collecting a lot of info from the user is unnecessary for what your app does.
My recommendation is - take out what you don't really need and justify why you need what you're asking your users for and let Apple know in the notes for the reviewer.
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!
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.
I do know how to ask permission for contact's list accessing, is a very simple implementation, also I know Apple checks all this in case of going live to the App Store.
I'm about to receive a AdHoc bundle to a third party client, very very picky with privacy issues and I want to be certain that you cannot in any possible way in iOS7 access to the the address book, without previous and clear authorisation, nor storing some file in local or sending it through a web-service.
If there's other sensitive information than a programmer can access without the operating system firewall please let me know as well.
I read some subroutines can go through...
QUESTION: Can a developer access to the addressbook or personal information, directly or indirectly using a third party API or subroutine to the personal data, without explicit permission? Is an AdHoc bundle as secure as an AppStore reviewed App in that case?
Please do not punish me with negative feedback if you are not interested in privacy issues or think was that obvious, actually Apple's documentation is not clear and is focused on AppStore, mostly.
Thanks!
This answer came up in every search I did trying to find, CNContactPickerViewController, so I figured I should respond for posterity.
In iOS 9 and later you can call CNContactPickerViewController to present a system controlled contact picker that doesn't require permission to access the user's contacts. You can't hoover up all their contacts, which is what the original question implied (and is super creepy), but at least you can prompt the user to select a contact (or multiple contacts), which is sufficient for many legitimate use-cases.
Docs
The Address Book cannot be accessed without permission. No third-party API can get in, because internally, these API's need to go through the same permission checks as you need to. No app can get into a user's address book without the user's permission.
This is because of a security issue that Path, and some other apps, uploaded its users' address books to their own servers to use for whatever reason. To read more about it, look here
After this surfaced, Apple required the user's permission to access the user's contacts. Apple's iOS platform is possibly the most secure operating systems today, and there are few security holes that exist in their API's (minus the goto fail; mess-up).
App Store reviewed apps are more secure for the user than Ad-Hoc apps. The developers at Apple make sure that you do not do anything malicious with the user's contacts. In Ad-Hoc apps, there is no checkup. So, if you wanted to do anything dirty with their contacts in an Ad-Hoc app, you technically could (if the user gives you permission at all). You do not need to state what you will be doing with the permission, and so you are able to take advantage of the user's trust in you.
If you want the company to trust the app, suggest that they look it over with their own reviewers. If they don't think you are doing anything fishy, you are good.