App rejected because of NFC used in third party

We use CoreNFC feature for few clients. For clients who don't use NFC or add NFC related permission, the app is rejected on App Store.

is there a way to make CoreNFC optional in the library and not lead to app store rejection for parent app who do not use this feature?

Answered by DTS Engineer in 791597022

If I understand correctly, you are the third party supplying a library that includes NFC functionality your clients are not using.

Not knowing what these apps are, how they are built, and what the actual rejection causes are etc., I can't make any comments or promises about the success of this solution, but the answer to your question about making CoreNFC optional is this: (things might look/work differently depending on which Xcode version or possibly 3rd party build tools your clients are using, but this is the general gist)

In the Xcode project Build Phases, the "Link Binary With Libraries” section, add the CoreNFC.framework, and then mark it as Optional

This will weak link CoreNFC, and unless there is code that is referencing it, CoreNFC will not be included in the build.

For that, you could make use of a custom Info.plist entry to check if the app is supposed to be using CoreNFC and not engage any features of your app that would require the use of those features.

Again, a lot of the specifics will depend on what the rejections are exactly for, what the apps are trying to do, and how they are built.

If CoreNFC is the main cause of headaches for your clients, you could also consider shipping a version without any references to it to make configuring and building their projects easier.

If I understand correctly, you are the third party supplying a library that includes NFC functionality your clients are not using.

Not knowing what these apps are, how they are built, and what the actual rejection causes are etc., I can't make any comments or promises about the success of this solution, but the answer to your question about making CoreNFC optional is this: (things might look/work differently depending on which Xcode version or possibly 3rd party build tools your clients are using, but this is the general gist)

In the Xcode project Build Phases, the "Link Binary With Libraries” section, add the CoreNFC.framework, and then mark it as Optional

This will weak link CoreNFC, and unless there is code that is referencing it, CoreNFC will not be included in the build.

For that, you could make use of a custom Info.plist entry to check if the app is supposed to be using CoreNFC and not engage any features of your app that would require the use of those features.

Again, a lot of the specifics will depend on what the rejections are exactly for, what the apps are trying to do, and how they are built.

If CoreNFC is the main cause of headaches for your clients, you could also consider shipping a version without any references to it to make configuring and building their projects easier.

We have added CoreNFC as a weak_framework in our podspec

s.weak_frameworks = [CoreNFC]

Few clients don't use the NFC feature and few clients use it. People who use don't have any issue with it. People who don't use it, will they have an issue when their app is submitted for review ?

They have not added the NFC permission in their Info.plist and have not added the capability as well. Will it still be an issue for such clients?

We can't help you with what happens in the build with that podspec. Anything we say will be assumptions.

As for app rejections, unfortunately, this is all hypothetical. App Review will handle each app on a case by case basis and it is not possible for anyone to say there will be an issue without knowing how the app is built, what NFC APIs are being referenced or not, and what the app is for. And also, what the rejection is for exactly.

If they get a rejection, the app developers can ask for a technical review and determine what exactly is causing the rejection and how they can fix the problem.

App rejected because of NFC used in third party
 
 
Q