The AI2 iOS compiler always inserts unnecesay permissions in the info.plist manifest for the NSCameraUsageDescription, NSContactsUsageDescription, NSBluetoothAlwaysUsageDescription and NSBluetoothPeripheralUsageDescription even when the aia project does not use Camera, Contacts or Bluetooth components. This causes unnecessary App Store reviews, warnings and rejections from the Apple.
The Ai2 iOS compiler write inside this info.plist the text: “This feature is requested by a library but not used by this app.!”. For Apple this is not well and claims to no declare these permissions in the ipa. Apple says:
These lines (permissions) are generated in the info.plist even for an empty app. I had no issue publishing two apps to the App Store four days ago. One of them was approved within 48 hours.
So, there is likely some other issue with your app.
The challenge is that Apple performs static analysis of iOS binaries to determine what strings should be in the Info.plist file. The App Inventor components are compiled into a single binary (AIComponentKit.framework) from our repository and so the app therefore contains references to all of the APIs we use, even if a particular component isn't used by the app itself. Apple does allow for this when the app uses a third party framework so long as you provide a statement that the API is not actually invoked during the application flow, so we do that automatically unless you override it by providing a value for the appropriate project property.
But the Apple robot detect this as a not compliance privacy and after the users receive message as not aproved and the process with Apple is very hard and confused every time we have a new realease. The users need re-confirm and re-clarify the correct permissions used and not the declared for the AI2 framwork compiler. My reported issue is to can have a more good AI2 compiler features.
That means if we write anything in the Project Propierties > iOS Settingg > NSxxxpermission, for example a blank-space character or other character, the compiler than generate a info.plist with this character as a text permissions? When generate automatically the compiler the text permission for Apple review and not the user text?
In my App I use only the prior 3 permissions. The 4 others are generated for the compiler (I don’t use in the App). The Apple robot detect these permissions as not defined text and I need every time to clarify after initial rejection App from Apple.
@Ferran_SIMON I messaged you I can solve your issue but you have not sent me your app for developing the tool. We can easily remove those unwanted entries with a tool and your app will pass the review. We can achieve this
I can pass Apple's review. The problem is that every time when I release the app, Apple first always rejects it, and then I have to explain why it happnes for the internal process of the AI2 compiler libriries. It's a tedious and slow process. That's why I was asking MIT if they could fix it by only requiring users to declare the permissions used in the app, since the current system is very confusing and surprising for them. Fortunately, Apple eventually approved it at the end.
Those are actually very critical permissions, though —especially the mic permission— which cause Google to complain as well. In fact, the latter effectively got one of my apps banned from Play Store search results.
We could explore having an option where if you put in whitespace it would remove the Info.plist entry, but my understanding is that will just automatically fail your build for not having the key despite the framework referencing the corresponding API. This is why we put the default message as saying that a framework used in the app references it but the app itself does not use that API. It's possible we may need to tweak the language a bit to make it more acceptable to Apple reviewers.
A longer term fix, which we don't really have the resources to implement at this time, would be breaking up the component library into smaller pieces based on the permissions needed. The downside is then the build process would take longer because we would have to recombine the different binaries into a single application package and the linking will take time. At the moment there isn't a huge load on the iOS build server but it could eventually force a need for more hardware there.
Hello @ewpatton
As a suggested improvement, it would be helpful if users could specify in the current iOS Settings which permissions they actually want the compiler to declare, using the text they enter in that iOS permissions configuration. Those permissions that are not selected would not be declared. I understand that this solution would require a minor change to the current compiler.
If the users select the permissions to declare for the compiler I understand then is not necesary inspect in the source aia what permissions need to be declared for the compiler.
