With introduction of iOS 6, I read apple added Contacts privacy settings as explained here.
However, in prior iOS versions, this setting is not present and user privacy is at risk especially after people realized that 'Path' was dumping iOS contacts on its servers.
If an application wants to collect phone book data in iOS 5 or previous versions, which is the better way of doing it?
Ask for permissions explicitly once via UIAlertView.
Ask for permissions every time the back up is made via UIAlertView.
Create an application entry in Settings and ask user for permissions once.
Shun the idea of Phone Book backup altogether.
I think personally you may want to think about bailing on the idea as it seems to be a bit of a quagmire security wise, we are building an app at the moment that uses the address book for invitation purposes and we present a UIAlertView informing the user that we are access and not storing every time the view loads, annoying but it covers us.
Related
I am thinking to make my own app like Find My iPhone app . But I am confused that whether apple allow developers to have access to play with the security or is there such Apple API's that can help us to include features as in the above app. Any suggestions?
Well I just can't comment because of low reputation. But people must give a reason to down-grade a question. Its quite a valid question.
Creating an app like this is semi possible. Due to the fact that you are not allowed to keep running in the background, except for certain special cases. Such as Music or a guidance app (navigation apps)
Your app can register to receive updates from the GPS location and process them.
The problem is it will use your gps all the time.
The find my iphone app is a combination of wifi location/sim card location/gps location.
It uses a combination of all these items which it has to keep track of your location as close as possible. Now back to your question, the fact that you cannot keep running in the background, will mean the app needs to stay open all the time (open I mean running, not necessarily onscreen). Not like the application from apple itself, which of course is allowed to go outside these developer restrictions.
The APIs exist for you to create the main functionality of this app. Core Location and APNS
When use A is looking for the location of user B, A would tell a server that it needs user B's location.
A push notification could fire up user B's app, at which point...
User B's location services would kick in, in the background,
Send this information to your server
Then update user A with another push notification.
There's a forbidden function by apple for getting a user's phone number because this may be intrusive and so on.
this is the code as far as I know
NSString *num = [[NSUserDefaults standardUserDefaults] stringForKey:#"SBFormattedPhoneNumber"];
I was wondering... what about before doing that the app should be displaying in a UIAlertView the approval of the user for such action, is that a valid solution???
thanks in advance folks!
The thing with undocumented functions is that they can't be relied upon. Any version update could break them. That said, the bigger issue is if Apple will approve an app that uses such a call. If not (consensus seems to be that they are not in favor of using SBFormattedPhoneNumber) then simply asking the user for permission before doing it will probably not buy you any points in the approval process. My suggestion would be to avoid this and simply ask the user for their phone number if you need it.
Your app will be rejected by the review team if it uses any forbidden API at all. Alert view or no alert view.
SBFormattedPhoneNumber is not present anymore after ios4 version. Basically there is no way to do it. Trying to access the number by some undocumented way would risk your app getting rejected.
Here is Apple response about this functionality
"For security reasons, iPhone OS restricts an application (including its preferences and data) to a unique location in the file system. This restriction is part of the security feature known as the application's "sandbox." The sandbox is a set of fine-grained controls limiting an application's access to files, preferences, network resources, hardware, and so on."
The device's phone number is not available within your application's container. You will need to revise your application to read only within your directory container and resubmit your binary to iTunes Connect in order for your application to be reconsidered for the App Store.
I'm facing this problem while designing my iOS app. Suppose that a user purchases an app and downloads it to the iPhone. I would like to provide him with a default consumable item the first time he runs the app to use whenever he wants , however I would also like to track if the user has already consumed the item. This way if he decides to reinstall the app we can restore the transactions (if he used the item) or we can avoid possible intents to download different kind of content by reinstalling app and consuming default items each time. (Guess NSUserDefaults is not an option here).
One approach that came to my mind was using UDID(or any iOS 6 alternatives) to keep a record on server of the user's device the moment he uses the default item. But this will limit items just to the device from which they consumed content.
It would be great to support all the user's devices (like inAppPurchases), but I can't figure out a way to implement this.
Any suggestions or help would be great.
Thanks a lot.
In order to tie information to a user (not just a device she used at one time), you'll need to ask the user to identify herself and save it someplace other than the device. In other words, a backend that implements registration and login.
From scratch, this can be a lot of effort that an iOS developer didn't count on. Fortunately, there are several services in the world that provide a substantial head start. Here's a nice round-up. I've had direct experience only with Parse.com, and think it's excellent.
http://developer.apple.com/iphone/news/archives/2010/february/#corelocation
Can anyone tell me what is the exact description of an ad and just a hint for a user?
We are developing a library that shows small banners depending on user's location. E.g. we are passing a cafe - we have a banner about this cafe, we are passing a church - we have a banner about this church. The library is to be re-used in other apps.
So from one point of view we are advertising a cafe, but from another point of view we are giving the user an advice about places to eat around him. So what is the border between an ad and advice to a user?
I think the problem is that such an app tracks the location of the user and location specific ads will constantly remind the user that their physical location is being tracked.
This is an obvious privacy and security issue but I also think Apple wants to prevent users from experiencing that creepy feeling that comes from knowing somebody is tracking you against your will.
In order to feed the iPhone location based adds, you have to upload the location of the iPhone to a server, process the appropriate adds for the location and push them back. That means that an external 3rd party, that neither Apple nor the user can control, is constantly tracking the location of the phone while the app is active. Since an app can capture info identifying individual phones, that turns the app into spy program.
Even if you actually did all the processing inside the app on a single phone e.g. looking up an internal local database, the user would still most likely assume they were being tracked remotely.
There is no way Apple will risk the damage to the iPhone's brand that would come from news stories screaming, "iPhone App Secretly Tracks User's Locations Anywhere in the World!"
The library you have in mind is clearly verboten. You could might get way with it if had a mechanism for constantly asking the user if they wanted to load location specific ads.
(BEGIN RANT: As an aside, I would say this sounds like something the explicative-deleteds in marketing came up with. They think "Hey, we can push location targeted ads at users and force them see those ads when they use any of the apps with the library! Think how great that will be for advertisers!"
Marketing driven design is almost always a disaster. If they started the design with the idea, "Hey, I think I as a user would like to have the option of seeing ads relevant to my location with a mechanism I control and which protects my privacy and security," then they would come up with a much better library.
In the long run, you make money by giving end users more power and control over their work and lives. You don't make it by strapping them down and force feeding them what you want.
If you personally wouldn't want the functionality and no users have asked you for the functionality, then its probably a bad idea. END RANT)
Edit01:
Let me address this:
So from one point of view we are
advertising a cafe, but from another
point of view we are giving the user
an advice about places to eat around
him. So what is the border between an
ad and advice to a user?
I used to work at Apple in several capacities so I understand a bit how they think.
An ad is something pushed onto the user with any prior action of the user's part. The user doesn't request the ads, doesn't select the ads may not even want the ad but they just appear anyway.
Advice is something the user ask for explicitly. An app with a button that says "Show adds for businesses in your immediate vicinity" would fall under the heading of advice. Even an app whose stated function was to show adds for businesses in the vicinity would be fine. In both cases, the user request specific information. It is not pushed onto them. More importantly, the user can control if they send their location or not.
I got caught in the nutcracker back when Apple thought it was a good idea to have dialogs popping up telling people how to upgrade to Quicktime pro. It caused no ends of problems for end users especially those in institutions because it took control out of the hands of end users and administrators. I got to stand between irate customers and the genius that thought of the idea, which turned out to the actual genius Steve Jobs. Eventually, he saw the light and the desktop ad experiment was terminated.
Jobs and Apple learned their lesson. Don't force ads on end users. Especially don't tie ads to the functioning of the software (in this case, the location manager.)
The big thing in Apple's announcement is the part that says: "If your app uses location-based information primarily to enable mobile advertisers to deliver targeted ads based on a user's location, your app will be returned to you by the App Store Review Team for modification before it can be posted to the App Store."
Is the major function of your app to advertise to users -- regardless of the fact that they may ask for the ads or not? If the major function is to advertise to users based on their location or the greater portion of Location Services usage is for the purpose of advertising to the user then Apple will reject the app. Period.
I need to implement trail period in my app. How to do it? Store day count in NSDefault? or some other?
You could store a counter in the preferences as you mention, although that counter would disappear if the user reset their phone.
However, I think it's all slightly besides the point. In general, Apple frowns upon apps that have this kind of functionality, so don't be surprised if your app gets rejected. Consider launching two different versions of your app instead, a "Lite" app and a "Full" app. The Lite app should have a reduced feature set, but it should never stop working.
Apple is against the idea of you disabling features to prompt people to pay money for something. Your app needs to be fully functional and a 'lite' version and a paid version seems to be how things work at the moment.
That being said - if you implemented it properly you could add in app purchase items to enhance your app. Your original 'lite' app could be $0 and additional features can be added for a fee.
The most bullet-proof method would be to send and maintain a copy of the iPhone's UUID in a database.
Then if the App is not "unlocked" it requires a "key" form the database every time it launches. You can then implement the trial period on the server side.
However, if you decide to use some type of encryption to store or transmit keys etc you will need a licence to distribute the App.
You make a light version of your app. There is no official way to have a trial version at this time. Hopefully Apple will eventually address the need, but I can't say I would hold my breath...