I'm developing an iOS app, and ideally I would like to include Google Analytics and AdMob (through Firebase).
I would also like to avoid showing consent forms if it's not necessary - potentially by not accessing the iOS Advertising Identifier (IDFA). But I can't find any clear answers as to whether consent is necessary in that case.
I know that:
We must ask for Analytics consent on a web page accessed by someone in the EU, because the ePrivacy Directive requires consent for the cookies used. An iOS app doesn't use cookies, but the same law applies for other types of local storage. (Source: gdpr.eu)
We must ask for consent to show personalized ads to a user in the EEA or UK, because the IDFA is required and this counts as personal data under GDPR. We must also ask for consent to show non-personalized ads, because Google also uses the IDFA for these. (Source: Google AdMob policy document)
Google's own policy requires we ask EEA/UK users for consent for the use of cookies and local storage, and for the use of personal data to provide personalized ads, in order to use Google's services. (Source: Google EU user consent policy)
The only other relevant question I found was this one which suggests I can just put this information in my privacy policy, but that answer is from 2015 which is before GDPR came into effect.
So my questions are:
Does Google/Firebase Analytics on iOS use local storage? Does it collect anything the GDPR would call "personally identifiable information" like IP address? And if the answer is yes to either of these, am I right in thinking I need to get explicit consent from EEA/UK users to use analytics?
Does AdMob only require consent from EEA/UK users because of its use of the IDFA? If so, can I just not include the AdSupport framework (thus disabling the IDFA) and so not have to obtain consent?
Is there anything in the App Store policies that require consent to be given before analytics or non-personalized ads are used?
To be clear, I'm not trying to hide anything from my users. If personal data has to be sent to provide these services and there's no way around that, then I'll happily show the consent form. I'd rather not send any identifying data off of my users' devices, but I need to be able to show some form of ads to support the app, and I'd like to be able to view simple analytics.
Good questions.
There is no such thing as "personally identifiable information" in GDPR. The term is "personal data", and it is not limited to data that is identifying, officially:
any information relating to an identified or identifiable natural person
For example the colour red by itself is just data, not at all personal, and the GDPR doesn't care what you do with it. However, if you store it as a specific person's "favourite colour", it then becomes personal data in the GDPR sense.
Part of the reason for that is that individual fields may not be identifying, but they may become so when used in combination with other (possibly also non-identifying) fields. For example, John Smith in London, is probably insufficient to identify a specific individual, but John Smith in Greenland probably wouldn't be too hard to track down. This of course becomes easier the more fields are involved, no matter how innocuous & anonymous they may appear individually. This is the entire basis for browser fingerprinting, common in bad ad tech.
The ePD and GDPR don't contain rules about cookies that you can work around by using other technologies (e.g. local storage, as you note); if they achieve the same end, they qualify as things that would typically need the same level of consent.
In the wake of the Schrems II judgement and the entirely expected collapse of Privacy Shield, you effectively can't use any of Google or Facebook's services from the EU. Both of them have issued statements about using SCCs in place of Privacy Shield, however, they misrepresent what the ECJ found (SCCs are valid in general, but can't be used in jurisdictions that don't provide sufficient protection, which includes the US), and those policies will not survive. The proverbial hasn't hit the fan on this in court yet, but it will happen, and soon. For example the UK is likely to lose GDPR adequacy status in January 2021 over their onerous surveillance laws and lack of GDPR enforcement, on top of the complications caused by brexit.
You can avoid wider problems with google analytics by using a self-hosted analytics system like Matomo, where you can be absolutely certain of where your data is going.
Contextual ad services without behavioural tracking do exist, and they're generally not much less effective than the nastier bits of ad tech, despite what the ad networks will try to tell you!
Remember that consent is the basis of last resort in GDPR; if you can use another basis, such as contract, then you should use that in preference. This means for example that you don't need consent to process someone's data that has created an account on your system, so long as the administration of that account is all that the data is used for. If you want to use that same data for marketing though, that does require consent (that's ePD, not GDPR). Also remember that you can't contract out of fundamental rights, though consent can be stretched quite a long way in practice. This also means you can't just wriggle out of obligations by hiding something in a privacy policy. A privacy policy is not in any way binding on the user – they can't "agree" to it like a contract; it is there to inform them how you handle their data. A good check to do on a policy is to look at all uses of the work "may", as it often hides a multitude of sins. If you can't explicitly name all third parties a user's data will be shared with, you shouldn't be using those services.
Now while I've said quite a bit here, I don't actually know enough about how Apple uses data in the IDFA to be more help on that specific case, however, the background is all the same, so I hope some of this helps.
The key legislation here is the EU's ePrivacy Directive and its national laws. The most important article is 5(3) which was amended in 2009. It says:
"Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.’;
You'll notice that it does not mention cookies as the scope of the applicability is much wider. It applies in 2 scenarios:
When you (or the 3rd parties you use) store 'information' (e.g. cookie) on your end users' end terminals (e.g. a mobile phone); or
When you (or the 3rd parties you use) gain access to information already stored in the end terminal.
Please note that this article applies even if your activities does not involve the processing of personal data. If you also process personal data, then the GDPR applies as well.
So answer to your 1st question is: You need consent under the ePrivacy Directive for Google Firebase. The information it collects is also personal data so you'll need to comply with GDPR obligations as well (privacy notices, data subject rights, transfers to 3rd countries etc.)
The answer to your 2nd question is: You are likely to need consent anyways as you are 'storing' AdMob SDK (as information) to your end users' end terminals and it reads information from these end terminals (gains access to information already stored...).
The answer for your 3rd question: Haven't read those policies in a while, but they are likely to require you to be compliant with applicable legislation. This includes the ePrivacy and GDPR among other laws.
The final poit is that likely you won't find too many iOS / Android apps that would be fully compliant with the ePrivacy as the European authorities have not enforced it despite the above mentioned consent requirement been applicable since 2011!
Our team is developing a payment infrastructure that provides for payment via smartphone with NFC technology.
For Android no problem as we used HCE; while as far as iOS is concerned we have come to the conclusion that the best solution, given the strong limits on NFC technology imposed by Apple, is the use of NFC-enabled Passes.
We have collected several information unfortunately very fragmented as on the net and on the Apple documentation itself not there is a lot of space on the deepening of this type of Pass. I know the implementation is under NDA, but we need to understand which way follow in order to at least start the tests.
With regard to the above, I list the points that are vital for the continuation of the work:
We have already requested the NFC certificate through the
appropriate form but we have not received any response yet. There is
a way, a particular form that the request must have or a sum to be
paid so that the request for the certificate can be processed
faster?
When the certificate is obtained, how should it be used? As already
mentioned, the implementation is protected by NDA, in fact I was
interested understand who I should talk to or how to get Apple's
documentation.
I thank in advance to those who know how to answer these doubts.
You are right, the entire process is under NDA.
I applied, like yourself and also reached out to a Developer Evangilist in Apple. I was told that the process was outside of their control and that you just had to be patient.
When you get the certificate from Apple, it will include an entitlement that enables the NFC support. I believe you just use the cert as normal when creating the pkpass bundle.
As I understand it, Apple will provide all the instructions to you if they approve your NFC request.
You can embed information within the pass that is sent via the NFC tag.
I’m afraid I can’t be more helpful.
App Store guidelines state,
Apps in the Kids Category should not include third-party analytics or
third-party advertising.
Can we use other Firebase features like authentication, database excluding Firebase analytics?
Firebase Authentication and Firebase database offerings are not considered analytics products that track user behavior or provide advertising.
Formally, you should consult a lawyer to know for sure if your use of Firebase is considered lawful for the purpose of App Store guidelines. I am not a lawyer, but personally, I do not see a problem with it.
I have a question about setting up auto-renewing subscriptions on iOS.
In my app, a user is able to be subscribed to multiple subscriptions at the same time. Is there a way to find out which subscriptions a user is currently subscribed to. In android is is as simple as loading the owned purchases from google via the billing processor. Is there an equivalent in iOS or do I need to do something else. Thanks.
You cannot determine on your own whether a user is subscribed or not. The only possibility for you to determine if a user is subscribed is to either validate preexisting receipts or restore purchases. I recommend you to watch the WWDC sessions regarding StoreKit at developers.apple.com, use Swifty StoreKit as it saves you some of the hazzle and read Apple's documentation.
After some research, I found the best way to do all InAppPurchasing was to use the library: SwiftyStoreKit. It makes everything a lot simpler and streamlines the whole process. It is well supported and well documented.
Here is the link to the github repository: https://github.com/bizz84/SwiftyStoreKit
I have a requirement in which we need to programmatically set the date and time (or sync the time) from a server.
How is it done in iOS?
Is there any Apple documentation which says we cannot do this?
You can't set the date and/or time on iPhone/iPad programmatically. Those APIs are considered protected by Apple. In other words if you were to use those APIs and submit an app using them it would be rejected.
Edit:
To get documentation on this you can contact Apple Developer Technical Support using one of your free tech support incidents included with your developer program. LINK
As the comments to your posters are saying, you can't, because although there is an API to do that, it is "private" and can only be used by Apple. Thus, if you do this, Apple will reject your app because the use of private APIs is verboten on the App Store.
There is no alternative solution. You'll have to explain to your client that as a third party developer, you cannot change system settings, end of story.