iOS Default-Info.plist gets overridden

[molbertz]

If the user provides a Default-Info.plist in src/ios it gets used to merge it into the final Info.plist. However since the addition of scanning for partial plist files from attach modules those keys override the users'. It seems that: com.gluonhq.substrate.util.ios.InfoPlist#Path:processInfoPlist() line: 246 simply replaces possibly existing keys in the dictionary.

Expected Behavior

The users' Default-Info.plist keys should have priority

Current Behavior

The partial plist keys have priority

Steps to Reproduce

Provide a custom Default-Info.plist file at: src/ios for an app that uses e.g. barcode-scan attach module. Make sure you have a custom NSCameraUsageDescription in the custom Default-Info.plist. Custom description won't show up in the app's consent dialog.

Your Environment

pom.xml <javafx.version>17.0.1</javafx.version> <charm.version>6.1.0</charm.version> <attach.version>4.0.13</attach.version> <gluonfx.maven.plugin.version>1.0.13</gluonfx.maven.plugin.version> <javafx.maven.plugin.version>0.0.8</javafx.maven.plugin.version>

GraalVM graalvm-svm-java11-darwin-gluon-22.0.0.2-Final

The app builds fine and usually gets through Apple Review. But today the reviewer noticed the standard NSCameraUsageDescription from the barcode-scan attach module and blocked the review process.

[jperedadnr]

Thanks for the report.

In the meantime, could you try adding a partial plist to your project instead of the full plist?

Like in here: https://github.com/gluonhq/hello-gluon-ci/blob/master/src/main/resources/META-INF/substrate/ios/Partial-Info.plist

[molbertz]

Thanks for the quick reply. That seems to be a good workaround. The correct message now makes it into the final Info.plist.

I think if in the future the users' Default-Info.plist keys get priority over the (e.g. Attach's) Partial-Info.plist keys, then that would be enough for now. I mean, if the user forgets to put in those required consent keys, a default one would definitely benefit the build process. But if Apple now requires consent messages that "sufficiently" describe the app's need to access something... I don't know how much of a benefit that is when the App potentially doesn't make it through the review process.

What are your thoughts on this conundrum?

[jperedadnr]

Good that it works for now. Default key-values have been working so far until now, but Apple is always pushing... or maybe it was a picky reviewer? Usually there is an issue referred in their reply, do you have it?

[molbertz]

I guess default messages don't cut it anymore. Or it was indeed a very thorough reviewer this time. I didn't even notice that our message from the Default-Info.plist wasn't shown in the app's consent dialog anymore. And last week the app went through as it was just fine...

Anyway here's their message: Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage

We noticed that your app requests the user’s consent to access the camera, but doesn’t sufficiently explain the use of the camera in the purpose string.

To help users make informed decisions about how their data is used, permission request alerts need to explain and include an example of how your app will use the requested information.

Next Steps

Please revise the purpose string in your app’s Info.plist file for the camera to explain why your app needs access and include an example of how the user's data will be used.

You can modify your app's Info.plist file using the property list editor in Xcode.

[jperedadnr]

Ok, that doesn't seem to come from a new policy. I've just found this old post with the same comment, so it looks like maybe having a more descriptive reason, but still generic enough, to the Attach services might suffice?

[molbertz]

Difficult to say. It probably comes down to the reviewer and the permission. The barcode-scan Attach for example could have something like: "This app uses the camera to scan barcodes/QR-Codes" instead of "This app requires access to the camera". But who's to say that even that will be sufficient enough. A thorough reviewer could argue that you'd need to explicitly explain to the user what the barcodes are used for.

To not run this risk in our app for example I wrote something like "The app uses the camera to import user profiles from a QR code".

But what to do with services like: Location (I actually don't know if there is an Attach service for it yet). Anyway, my point is this would be a service that would really require a non-default consent key. Because obviously every app uses location data for different reasons. More descriptive but generic messages seems like a good idea, of course, but it could prove difficult to come up with them.

I guess we'll see if more people run into problems with the default keys. Could be that Apple told their reviewers to pay special attention to the consent keys. Could also be just a thorough reviewer.