Every time pushing a new build to iOS, wait for rejection before asking them to reconsider, saying you never use camera or location.
Make up some excuse for “using” the permission when you don’t use it. “The camera is required to… what?” “Location is used (for what?) but never leaves your phone”? How can anyone trust that?
It seems like if someone wanted to introduce these modules through OTA it would be better for them to submit a full new build, just as if they had to change a setting in app.json. I’m sure there are many apps that don’t use the camera OR location and have no plans to ever use them. This would also make the behaviour consistent with setting permissions for Android in app.json.
Sorry you are dealing with this. From our experience, this seems to be a random occurrence by Apple (as indicated by the post you linked to where Apple eventually just accepted the app). As for the best course of action moving forward, I think there are two options (one a fix and the other more of a workaround).
The fix would be to eject and manually remove these modules yourself. It would ensure you won’t get flagged for these but also comes with the ramifications of ejecting.
The workaround would be to add customized strings for the under ios.infoPlist as you indicated in option 2. Certainly not ideal and far from a fix, but there’s a decent chance it’s enough to have your app approved.
"infoPlist": {
"NSCameraUsageDescription": "<Appname> does not use the camera in this version.",
"NSLocationWhenInUseUsageDescription": "<Appname> does not use location in this version."
}
And it’s just been accepted. Hopefully this helps someone too - maybe the workaround was not as bad as I first thought - I’m glad giving the text that I don’t actually use it (rather than making some artificial usage reason) still worked.
Sweet. Thanks for sharing your solution with the community! Hopefully others don’t have to deal with this but it’s nice to know there is hope if they do.