IDFA usage explanation on the website

Hello,

We have a problem related to Expo builds and iOS appstore.

Apple rejected us with the following reason:

We noticed that your Kids Category app includes analytics, advertising and collects, transmits, or has the ability to share personal information or device information with third parties. …
Third-party analytics or third-party advertising with the ability to collect, transmit or share identifiable information, including, for example, IDFA.

We’ve been deploying this app for months now with no problems… We’re aware about Expo’s IDFA and this issue on Github (Disable/remove IDFA tool(s) from Expo project · Issue #1320 · expo/expo · GitHub) where you explain your IDFA usage.

But the new twist now is that, since the app is targeted to kids – recently Apple became stricter and now they require us to remove IDFA. Which we can’t (unless we eject).

We understand that IDFA isn’t accessible to us and it’s used for low-level Expo SDK usage. And it doesn’t send any identifiable information about our users. That’s why we think the app should still fall under this exception (from Apple’s guidelines):

In limited cases, third-party analytics may be permitted provided that the services do not collect or transmit the IDFA or any identifiable information about children (such as name, date of birth, email address), their location, or their devices.

Now, it would be nice if your usage of Segment and Amplitude could be more prominent on the (expo .io) website. At the moment, I have to send a link to a 2 year old (closed) github issue where the third comment explains your IDFA/Segment usage. It would be a lot simpler if that were a page with its own URL or part of the the page explaining app stores.

If we can’t explain clearly how IDFA/Segment/Amplitude is being used in our app – there is a danger that all kid-targeted Expo application will start being rejected .

Hey! Thanks for writing in about this and starting a thread here

I’ve updated our documentation to reflect this a little bit better from our deploying to app stores documentation.

But the new twist now is that, since the app is targeted to kids – recently Apple became stricter and now they require us to remove IDFA. Which we can’t (unless we eject).

After letting Apple know the special circumstances, they responded saying your app does not fall under that exception and you must remove those third party libraries?

I should also note that very shortly, moving to the bare workflow will be much easier and it will have all the same APIs that the managed workflow does, allowing you to build apps with OTA updates, notifications, and all that good Expo stuff :smile: Plus, we plan on just making it better and better

I added this github issue recently and charliecruzan pointed me here to an ongoing discussion here.

What I did, when apple rejected the kids app for the first time, was quoting and pointing to expo documentation, making it as clear, as a message might be, that there is no tracking implemented in the game, absolutely no ads, no data is collected, sent, whatsoever and never intended to do any of that in the future for our game.

Still from the review process we’ve only got as a second reply:
“We noticed that your Kids Category app includes analytics, advertising and collects, transmits, or has the ability to share personal information or device information with third parties.”
They clearly became stricter, since February, it seems, and they clearly say: “or has the ability” for Kids category.

I didn’t want to eject, actually, it is not encouraged by the expo documentation, for various reasons, that I agree on. I struggled to find a solution to this but the only thing we can do to comply is to eject and remove Segment and Amplitude.

Charliecruzan, your note on bare workflow is encouraging, thanks for that.

Yes, we have the same a similar situation. We don’t send anything to third-party services. They rejected us for the same reason as Dogotaru pointed out.

Now, I’m not sure about you, Dogotaru, but I hoped to make a case that this specific case falls under this exception from their guidelines:

In limited cases, third-party analytics may be permitted provided that the services do not collect or transmit the IDFA or any identifiable information about children (such as name, date of birth, email address), their location, or their devices.

Because AFAIK, there is no way I can retrieve the IDFA and/or segment code used by Expo and embedded in the binary.

We need a way to explain that we (as developers) can’t actually use Expo’s Segment/Amplitude/IDFA and that this code doesn’t send our user’s data. And to do that, I think we need a better place than a two-years old github issue.

That’s why I think there should be one place on expo.io where this is clearly stated (quoting that 2yo github issue):

  • We collect anonymous usage statistics through Amplitude which aren’t specific to your app and help us figure out how people are using Expo, as covered here.
  • By default there is no data being sent to Segment at all, unless you use the Segment API in your app for your own purposes.

Even though no Segment calls are made by default, since the code is statically present in your binary that could run Segment, you still need to check the IDFA boxes listed in our https://docs.expo.io/versions/latest/guides/app-stores.html#ios-specific-guidelines.

PS. I understand and appreciate the coming changes in the bare workflow. It’s just that we didn’t plan to eject now :frowning:

I wrote a long response, but the akismet spam-filtering thought it’s spam (which, I can guarantee it wasn’t). So, here’s a shorter version:

We had the same experience as Dogotaru.

Maybe, just maybe a better explanation in the official Expo documentation would make Apple change their mind.

If not. Either Expo drops IDFA/Segment/… from the builds (any remote chance for this to happen?) or you just clearly specify in the docs that kid-targeted apps will be rejected for managed apps.

I just posted a related question here Segment 4.0-beta without IDFA

Hello @dogotaru I have the same problem, ¿did you solve in any way with expo or did you just stop using expo?

@tkrajina Have you received any answers or solutions to this problem?

Hello @charliecruzan , we have been using Expo for 3 years for our iOS application within the children category. It is very sad to know that Apple only in the last few months changed its privacy policies to demand to stop using this feature that we did not decide to use or use in our application. In a phone call with an Apple member, he mentioned that we have two options: “Delete the application from the store, upload an application without the category of children” or “Stop using the technology that the IDFA incorporates implicitly”, both decisions they are very drastic and complex for us.

  • Is Expo planning to disable IDFA in its future versions?
  • Does Expo have plans in its future versions to enable an option where the IDFA is omitted?
  • We are not the only users with this problem, what quick solution do you have for us?
  • Is the solution that all developers with this problem stop using Expo in our applications?
1 Like

Answer is to eject.

It’s not the end of the world, believe me :slight_smile:

1 Like

We are being rejected by both Apple and Google for our fire safety app for children, which has no ads. We were approved as recently as July2, but when we upgraded to SDK 38 both are now rejecting us. Google has a list of approved ad servers in the children’s category - can Expo get certified for that?

2 Likes

I’ve not been following up on this because the problem was sort of solved for me. Of course I ejected the app and built ios bare. It was not the end of the world, @tkrajina, but it has been a big pain in the butt, to be totally honest, I don’t own a mac and the entire Applle dev environment was very far from me. I hated it. Actually this is why I chose expo managed flow in the first place, it sounded very tempting in all of the docs.
I kept using managed flow for android, because I couldn’t invest much more time in it, my deadlines didn’t take ejecting into account at all, and I lost time manually building the ios version already.
But recently I got a notification from Google that my app is going down if I don’t do anything about the: “after recent review … we have detected that your app includes non-certified ad SDKs or SDKs not approved … for child …”, dammit.
I don’t know, the fact that all this was not obvious in the first place is so disappointing. @charliecruzan, I feel tricked and misled by expo team/docs. Sure, I can deal with it, I cannot hold expo responsible for this, I know, there were a few expo components, not part of the core, that have been great to work with and time-saving. Just that being new with react native and expo, I hit this awful wall of delay, uncertainty and indifference. Definitely not very fair.
Have I known there is such a twist would I have ever used managed flow? hell no, I would have planned accordingly.
I am not quite sure I even can revise the app on google, unfortunately.
All the answers on this matter, every bit of documentation constantly explains how it will be possible to not load all universal modules soon, and that actually the auto-bundling is for devs sake, or that these are no issues, many closed, expo team forwarding devs from one post to another. Simply googling you can see how many issues are related to this new GDPR reality, that I don’t really get why they don’t just find a solution. This is very disappointing again.

1 Like

@dogotaru I’m really sorry you feel like you’ve been misled, that’s definitely not our intention at all. We feel we’ve been pretty upfront with the fact that all the native code for the SDK is included in all managed apps (and that that includes code for the IDFA, and what that means for developers), and if you need to be selectively excluding modules (or including outside modules) then the only way to do that is the bare workflow for now. Can you explain a little more about how you feel we tricked you? I’d really like to avoid anyone else feeling that way in the future, so maybe by you explaining what we did that was misleading, we can correct it

On a related note, we’ve put forth a good amount of effort to upgrading libraries to IDFA-free versions of them (Segment, Amplitude, soon Branch as well), but the Facebook iOS SDK also contains code for IDFA and they don’t seem to be planning on releasing a version without it like those other libraries have, so it’s unlikely that the managed workflow will be completely-IDFA-free anytime soon :confused:

I don’t feel misled, because when we just started - the expo workflow just worked. It was such a nice experience. When the problem arose – it was because of decisions out of Expo’s team area. It was Apple’s decision.

The only thing where I felt more should be done is explaining to developers the potential problems with IDFA and the managed workflow. Because switching from managed to bare can be a lot of work. I said “it’s not the end of the world”, but if you have a complex app it can be a couple of weeks of work. My experience is similar to @dogotaru . I switched iOS to bare, but used managed for Android for e a few weeks more because I had other things to do. Only later I switched the Android to the bare workflow.

It was probably 2-3 weeks of work. I knew I’ll eject sooner or later. But I expected I could choose the time.

I felt that this explanation should be a lot more prominent on Expo’s web page. I think that you should explain very clearly that there is a high probability that managed workflow will be in conflict in Google/Apple reviewing process and that users will have to eject. So, for every serious application – play with managed until you have a proof-of-concept to show to your users/investors/friends. But have a backup plan to eject any time.

But I appreciate your efforts with all the expo libraries and tools and the recent changes in the bare workflow. I still think it’s a great set of tools, and I’ll definitely recommend it to anybody starting e new app with react-native.

1 Like

Thanks @tkrajina! I appreciate your feedback, although:

I think that you should explain very clearly that there is a high probability that managed workflow will be in conflict in Google/Apple reviewing process and that users will have to eject.

this just isn’t the case. There are plenty of serious applications built with Expo on the managed workflow that are live on the app stores and have been for quite some time, and haven’t run into problems with the reviewal processes. Since you want your app to target kids, then the stores want to take extra measures to ensure the data is treated even more carefully, which makes sense. This rule applies to any app that has the ability to collect the IDFA but is targeting kids, which is why there are plenty of developers asking those libraries to provide options for excluding that code (this applies to managed, bare, even pure native development). I think Apple is trying to address this issue with the new changes in iOS 14, but only time will tell.

Hey @charliecruzan, misled and tricked because never there is written anything related to kids apps. It might be tempting to discard that part of development as secondary, but I wouldn’t agree it’s right. For what it’s worth, for Common App Rejections, it might be stated that: solely the existence of IDFA code is a 100% reason an app for kids will be rejected, sooner or later, both for android and ios. It might have not been the case 2 years ago, but it is now.
I bet the rules will become increasingly more strict, for any other type of the app, though, and it is probably right. So fiddling with tracking must be as careful as it can be, for everyone, really.
Bare workflow is nowhere near managed, you said: “I should also note that very shortly, moving to the bare workflow will be much easier”, but it isn’t. You are not the only one, in expo community many say similar things, expo team or not. As much as I would like it to be true, that is falsely encouraging. It feels that you could wait a little bit more and you can eject, but have the same experience as managed flow.
Don’t feel attacked, please, that’s not my point, I agree with @tkrajina, I recommend expo 100% percent, for so many reasons, one of those is the huge amount of effort put into developing and maintaining it. I never said I wouldn’t have used expo, I just said that given my own current context, I wouldn’t even have considered managed flow for the application that I needed to deliver, hence the misleading part.

1 Like

because never there is written anything related to kids apps

Our documentation is all open source, so if you believe there’s something that should be added, you can always open a PR. I agree that it’s a good thing to add, so if you recommend me as a reviewer I can make sure we prioritize that.

Since the App Store guidelines can change, it doesn’t really make sense for us to document all the possible reasons for rejection ourselves, it’s better to link to them, which we do and those guidelines state:

Apps in the Kids Category should not include third-party analytics or third-party advertising.

That being said, the reviewal process can be a mixed bag, as I’m sure you know. Some folks are able to appeal and explain how although that native code is included in the binary, it’s never used and is essentially dead code. This is done a case-by-case basis, though.

@dogotaru we now do probably over 90% of the native project configuration for you when you eject, so ejecting is easier, but of course you’re going to lose some of the convenience of the managed workflow when you do so. It’s a trade off between more control, and less automation. We’re working on that, but it’s a big project so it does take time. I don’t think that saying it’s something we’re working on and incrementally improving is a bad thing, though

I know it’s open source. In fact I did send a couple of pull requests (one being a minor documentation change) and I’ll send more if I find bugs. But I think that this explanation is something that should be explained by a person from the core team. I’m not a native english speaker and this needs some very good wording (if you want Apple to take it seriously).

One (last) note about rejections. We also found that the requirements were getting more and more strict with time. Previously we were able to argue and explain the existence of IDFA. But now that’s most definitely a reason for rejection. And I don’t think this will change with time.

Hi @tkrajina ,

I was having the same issue as you. I have ejected the app, is idfa not included now? or is there any other steps I need to take? I don’t want to resubmit the app and have the same issue

If you succeeded in building a binary, that’s it. There’s no IDFA in there. Just replace the binary in your previous submit with a new one.

1 Like