Hi All I had a very nice call from a very friendly Apple reviewer today (all the way from US to UK!) Basically stating that a current App I have in review is violating their TOS with regards to 'User Privacy' and that they have seen this a LOT from Buzztouch apps being submitted, and due to some recent policy changes, any apps that are doing this are being REJECTED The upshot is that the 'reporting usage back to Buzztouch' feature (what generates your usage pins on your apps map) is in violation of user privacy And also, in the Quiz, where the 'High Scores' are sent back to Buzztouch (or wherever) the same violation occurs I have agreed iwth the Apple reviewer to have this fixed on my current app within 24 hours and they will accept the App (poss even removing the quiz and turning off the reporting feature) BUT as it is across the board for ALL apps, is there a fix that can be made at the Buzztouch end for this? Steve PS: Also emailed this to infoATbuzztouch.com

just a thought, may be just a case of changing the app templates (permissions, quiz template, etc) don't know - I'll hand this over to BT guys :(

Would it be too difficult to ass a pop up and ASK the user whether he Agreees or not each time? If he says YES, no violation of privacy. Could Buzztouch folks edit their feature to do that?

Interested to see where this goes! I wonder if removing the lat/long part of that string would help.

This is an ongoing feature vs. privacy issue and we (app owners) should always do what we can to protect the users privacy. The difficult part is balancing what Apple wants, features, and what the user wants. There are lots and lots of apps that send location data, and other data (think games that share scores) so your app should be OK doing the same type's of things. However, users should be made aware of this and be offered a way to prevent it from happening. buzztouch v1.4 makes this tough from an app owners perspective - it's not easy to modify the code to prevent this type of behavior. Another reason we moved towards v1.5 and it's features. I think it makes sense that we build-in some sort of message or I Agree type screen / pop-up like @michalis suggested. Any thoughts on how you think this should work (anyone with an opinion) are appreciated. We'll continue to do what we can to help folks build apps that are within the guidelines but want to make sure we don't jump to any conclusions about how the alerts or approval processes should work without first asking the group. Looking forward to your feedback...

I have been using 1.5 and with a GPS screen. So the app first asks the user if they want to share position information (yes or no) and the user has the option of turning it off if they want. But I usually try to have some sort of feature that uses map functions. I havent had any trouble with approvals yet. I hope this is an isolated opinion from Apple...but it is concerning.

I dont use location data or have not yet made a quiz app so in my case it doesn't really matter. But for the review process to be smooth maybe the suggestion that @michalis suggesetd is a good solution? Thanks to @Steve for the heads up on this issue. BR/Stefan

It may or may not be isolating. Either way, it's important that the phone does not send device information (unique id, model, make, etc) This is different than location data the user can turn off. In v1.4 tons of places send the device model / id to the backend and the user have not authorized this unless the owner made special considerations for it with an entry screen or something. v1.4 makes this super tough. In v1.5 it's easy to remove the device data because the URL's are managed in the contorl panel. I think we'll just end up introducing a Terms Of Service screen that app owners can modify with their own message depending on the needs of the app. The Terms of Service screen could explain what's happeneing when the app is used. Agree / Disagree, etc.

Like the idea of a TOS screen, should solve any future shenanigans from Apple and means we can all continue as-is.

I think a TOS screen is good, I may just start putting some of this in my apps' info page. Having said that, if our app has the GPS screen allowing them to turn it off if they wish, wouldn't that cover us?

@David I agree. Sounds like a good and flexible solution.

@ mutzy: The turn-off GPS feature, that iOS already manages, is only one part of the problem. The other part is that the device's unique id and model is also passed to the server. Even though there is not personal info in this data, Apple still wants the user to know whats being sent to a backend. GPS: One issue. Device Data: Other issue.

Just read this on Allthingsd.com, apparently this is a bigger issue and probably tied in with recent lawsuits like the one in Korea. My guess is they are trying to avoid future legal nightmares: http://allthingsd.com/20110819/apple-takes-a-key-tracking-tool-away-from-developers/ Apple is making a key change in the way developers and other third parties interact with the company’s mobile users. The company is taking away access to the “unique device identifier” associated with every iPad and iPhone. As Techcrunch notes, the change will be particularly meaningful for ad and game networks that used the UDIDs to track user behavior. It’s also worth noting that Apple has announced big changes in its developer policies before, and then backed down, to at least some degree, after public outcry.

Great info coming through on this thread, love the BT community.

Great thread! I'm about to send a v1.5 app to the App Store. Should I change (clean) all the URLs that request deviceId and deviceModel? I have no interest in this info for this app anyway. I do have interest in the location (latitude and longitude) of the device though (even though its not in use yet, just for the usage map). What do you guys suggest?

Yes, About to submit v1.4 app, i dont have any map functions or quizzes...any ideas on what i should remove from source code possibly? thanks!

You can do this a few different ways. For sure the easiest way will be to remove all the references to the device info from the URL's. If it's not useful for you then no need for it. In v1.5: The Core Settings, Data URL and Report To Cloud URL may contain [deviceGuid] and other device info placeholders. Remove these. Be sure to leave the [appGuid] and [apikKey] placeholders so the app can identify itself to the backend. For v1.4: It's a bit trickier because you'll need to do this in code, not in the control panel. It's not tough, you should be able to do this in one spot. Find DownloadFile.m in the miscObjects folder in Xcode. Have a look at the downloadFile method, you'll see where 4 variables are appended to the URL. This starts on line 98. deviceId, devicModel, deviceLatitude and deviceLongitude. Comment out this section of code. Do not comment out where it appends the command variable, the backend needs this to output the right data.

Hi David, so it's just these lines to comment out? //append device and app vars [postVars appendString:[NSString stringWithFormat:@&deviceId=%@, [appDelegate.currentDevice deviceId] == nil ? @ : [appDelegate.currentDevice deviceId]]]; [postVars appendString:[NSString stringWithFormat:@&deviceModel=%@, [appDelegate.currentDevice deviceModel] == nil ? @ : [appDelegate.currentDevice deviceModel]]]; [postVars appendString:[NSString stringWithFormat:@&deviceLatitude=%@, [appDelegate.currentDevice deviceLatitude] == nil ? @0 : [appDelegate.currentDevice deviceLatitude]]]; [postVars appendString:[NSString stringWithFormat:@&deviceLongitude=%@, [appDelegate.currentDevice deviceLongitude] == nil ? @0 : [appDelegate.currentDevice deviceLongitude]]]; */ The simulator still asks... APP Name would like to use your current location...when first installs...is this still ok or will it be a problem?

Yup, that should do it. All you're doing is preventing the app from sending device specific information in the URL. This seems to be Apple's new found beef. Funny.

Sweet! So I do not need to worry about the ('app' would like to use your current location ) message that pops up when app is launched? Won't that send a flag to apple? Edit: also for future reference if I use maps I would just un comment the device latitude and longitude parts of the code? This is v1.4. Thanks

Good point. Because you're not sending this in the URL anyway, you should probably turn off the GPS too. To do this... [appName]AppDelegate.m file in the /config directory. Comment out line 127 (or so) where it does: [self performSelector:@selector(startLocationUpdates) withObject:nil afterDelay:.2]; and it will NOT turn on the GPS or ask the user for location permission.

Got it, works nicely! Thanks as always.

I have a v1.5 app that is waiting for review. I submitted the day before this post started, so I wasn't able to remove the report to cloud settings with vice data. I will keep everyone posted as to what happens. Hopefully it will slip through the cracks and makes it to the app store.

Hello, I am doing a quiz and I want to turn off the gps. I could not find line 127 or so, and what is the change that I need to make. << [appName]AppDelegate.m file in the /config directory. Comment out line 127 (or so) where it does: [self performSelector:@selector(startLocationUpdates) withObject:nil afterDelay:.2]; >> I need help Thanks Pete Here is the AppDelegate.m file THIS POST HAS BEEN MODIFIED. The contens of app-delegate were far to long and not useful for the discussion.

@gatorcade, the line 127 refers to v1.4 apps...yours looks like v1.5...did you try the suggestions David made for v1.5...let me know..cheers!!

Thanks for the info!

So, here is what a current Report to Cloud URL looks like : http://www.buzztouch.com/appdata/v1.5.php?command=reportToCloud&appGuid=<XXX>&apiKey=<XXX>&deviceId=[deviceId]&deviceLatitude=[deviceLatitude]&deviceLongitude=[deviceLongitude]&deviceModel=[deviceModel]&userId=[userId] If we make remove deviceID, deviceModel, and userID (assuming we don't have them logging into something), it give us this: http://www.buzztouch.com/appdata/v1.5.php?command=reportToCloud&appGuid=<XXX>&apiKey=<XXX>&deviceLatitude=[deviceLatitude]&deviceLongitude=[deviceLongitude] I have two questions on this: 1. Is this enough information to trigger a content reload? I am sorta interested on where people use my app, but I don't really care too much about the details of the device. Or are those details required for the trigger? 2. Would this, do you think, satisfy most of the TOS changes? What about if we remove everything after apiKey...is THAT enough to still trigger a content reload? Thanks! Mark

@ GoNorthWest: This should be fine for Apple and for the backend. The device model is only useful when viewing things on a map (usage stats) and isn't necessary, it will work without it. As far as we can tell, the functionality was fine with the TOS...but...as you know, Apple tends to make judgements and decisions on a case-by-case basis so it's tough for us to tell. Funny. You should be fine with that setup...submit away.

I have a question about fixing this for an App already submitted to Apple for review. My question is related to David's suggestion In v1.5: The Core Settings, Data URL and Report To Cloud URL may contain [deviceGuid] and other device info placeholders. Remove these. Be sure to leave the [appGuid] and [apikKey] placeholders so the app can identify itself to the backend. If I change this now will it update the BT_Config.txt when Apple opens it for review or do I need to download the source code again for this type of change to be updated.

@Moto110 I believe you can still change the binary files if your status is waiting for review on iTunes Connect. Can anyone confirm this?

The config.txt file will not automatically update when apple views your app. If your app is still waiting for review then you can go into itunes connect and reject your current binary and upload the new one.