I am using the latest versions of XCode and Admob and am trying to validate my app so I can submit to App Store Connect. My core code is unchanged since my last successfully validated submission except that I now have implemented AdMob as per their instructions.
When I attempt to validate my archive I get the following:
Validated with Warnings
App Store Connect Operation Error
The app references non-public selectors in Payload/MyApp.app/MyApp: setConsent:
I am slowly going through and resolving the plethora of errors stemming from implementing AdMob and have solved similar-ish issues, but I cannot find an actual resolution to this issue anywhere. Has anyone seen this issue or know enough about AdMob to suggest potential fixes?
Related
Please Help Me Fix this issue.
Recently when I updated my application(OXOO movies streaming app) I receive this email from Play Console:
Your app contains content that doesn’t comply with the Device and Network Abuse policy. We found your app is using a non-compliant version of an SDK which contains code to download or install applications from unknown sources outside of Google Play.
The SDK can be identified using the classname com.dcastalia.localappupdate.DownloadApk.
Affected Version(s):
App Bundle:3, App Bundle:3, App Bundle:3
But I have checked everything but have not found anything like this in the application.
Please give me some advice to fix this.
It is really important for me to release an update.
remove
implementation 'com.github.Piashsarker:AndroidAppUpdateLibrary:1.0.3'
from your build.gradle
Upon uploading a binary to App Store Connect, I receive this email from Apple:
ITMS-90338: Non-public API usage - The app references non-public selectors in [PROJECT NAME HERE]: callWithArguments:, estimatedProgress, frameInfo, getVersion, initWithFrame:configuration:, isMainFrame, navigationDelegate, navigationType, setNavigationDelegate:, setProcessPool:, targetFrame, toDouble, toString, userContentController. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/
However, other than the build number increasing from 1.2 to 1.2.1, this is the exact same Binary that has been previously uploaded (and is live).
I've checked other questions on StackOverflow, such as this and this, however are typically in reference to third party SDKs.
I am completely baffled as I don't use these method names at all, anywhere in the project...
Is this an issue with iOS 16 having been just released?
Thank you.
UPDATE
This issue has been resolved on the app validation backend. Resubmitting should work.
source
Original Answer
I'm also experiencing this issue this morning. A simple search of my project reveals many usages of these WKWebView APIs that are clearly public.
I suspect the issue is due to an issue with App Store builds linking against the freshly announced iOS16/Mac updates this morning. Unless those APIs have been outright banned today with no warning (unlikely), I'd put money on it being an Apple issue which they will resolve ASAP.
I tried many ways online but finally found one way out. Refer to this comment on the gihub issue. Hope you find this helpful!
I developed a small SwiftUI app that uses FMDB as a framework. I've done this with several other apps in the past and encountered no problem. With this one, I ran into the problem that though it would run on my test devices and the simulator, it failed App Store upload with a message that signing the FMDB framework failed (using "embed and sign" option; this is a problem for another question, for sure). After lots of frustrating research and unsuccessful trial-and-error attempts, I decide to remove the FMDB framework and bring in the FMDB source, so I could get it to the App Store.
That seemed to work, as I can upload the app to the App Store and run it on simulators, but when I run the app on a device, I get the message, "dyld: Library not loaded: #rpath/FMDB.framework/FMDB" and accompanying stuff. I can find no remaining reference to the FMDB framework, but obviously Xcode can. I've cleaned the build folder, deleted derived data, deleted the app from the devices for a fresh install, cursed and moaned, and tried multiple devices.
Any ideas where to look to remove references to the FMDB framework? Ideas on why this is happening?
I want to submit my App to the Apple App Store today, however I'm having some trouble when I attempt to "Validate" my archive before submitting from the organizer.
My app is using the LiveSDK (specifically to use One Drive) but during validation I get the following error message:
iTunes Store operation failed.
Invalid Info.plist value. The value for the key 'MinimumOSVersion' in bundle MyApp.app/LiveSDK.framework is invalid. The minimum value is 8.0.
I have no idea how to fix this and any help is appreciated. Thank you!
Apple recently decided to stop allowing the simulator architectures to be included in the submission to the iTunes store. The LiveSDK framework is built with the simulator architectures, for a work around please include the LiveSDK source directly. You can find steps here. There are more details in the discussion around this GitHub issue.
I am going to upload my first mac app to Apple Store
And fixed all validation bugs of icon,category...
But after then I passed validation with warning :
The resulting API analysis file is too large. We were unable to validate your API usage prior to delivery. This is just an informational message.
And my upload be rejected with the reason : "Invalid binary"
Is there anyone has experience of this case ?
UPDATE : this warning is not the reason of rejecting, it maybe the app archiving problem. I successfully released my app to store.
So, we can safely ignore that.
Apple forbids using private or undocumented APIs in iOS apps. Any calls you make to methods that have the same name as private or undocumented API methods will be flagged as a private API use, even if the method being called is something you have defined yourself.
App Loader does an initial scan, checking for method names, instance variable access, and even #selector usage with private method names. App Loader doesn't always do a great job, and the more source files you have the more likely it is to give you the warning that the API analysis file it has generated is "too large".
Fortunately, you can still submit your application, despite of the warning. Apple will check it internally, and if something gets kicked back because of overlapping names, you'll have to wade through the review process again.
Erika Sadun tried to make an app called API Kit that would do the scanning for you, but she appears to have abandoned her work and removed any trace of the application from her website.
Chimp Studios created App Scanner to do the same thing, but it hasn't been updated since 2011. Unfortunately, for large projects -- and this includes projects with a lot of extra pods from CocoaPods -- there is no current (2014) good way of solving this problem other than proactively naming things such that they won't conflict with private API method and instance names.
You can proactively learn about Apple's Cocoa Naming Conventions and try to anticipate. That will reduce future headaches. Until Apple introduces something like namespaces, however, we may continue to run into this problem from time to time.
The "invalid binary" error can come from a number of causes, but it is entirely unrelated to the API analysis document created by App Loader.
You should know that even with the scanning, there are still ways to get around the prohibition on using private/undocumented APIs. :)
After hitting this issue for the first time on my first Swift project, it looks like the most common answer to this question is now:
If you use Swift 2.x and XCode 7, you'll get this error. Just ignore it.
[UPDATE: XCode 7.3 & iOS 9.3 rollout seems to have fixed this issue!]
Here is an easy way to get around them... store the selector name in reverse, like "dlroWolleH", then reverse the string before you call the method.
If Apple gets wise to that then you can encrypt them.