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!
Related
I have been facing this problem since yesterday. Although I have published an app in the play store before so I am aware of the policies. But I am trying to upload a new app in play store and it's saying me the following error,
Check these warnings before starting the rollout of this release. Addressing the warnings on this page will ensure your existing users are able to upgrade to the latest version of your app.
In addition, I have tried all the way like as
Removing unused code
Unused libraries and resources
Furthermore, I have tried some of the previously asked questions but none of them saved my problem.
I am adding the details of the apk in the following image,
So it would be great if someone can help me with this problem.
I have resolved this issue.
By going Analyze->Inspect Code
This process will provide you all the unnecessary code or resources.
I've spent the last two days trying to submit my app to the App Store. I get the message below:
ITMS-90338: Non-public API usage - The app references non-public symbols in Frameworks/Flutter.framework/Flutter: _kCTFontOpticalSizeAttribute. 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/
Here's what Ive done so far:
a) I've scoured my code for any reference to Font Sizes - I had some that were constants - I changed the constant name to:
k_fontSizeMyName
b) I tried to download the latest flutter sdk version
c) I rebuilt my entire keychain.
Im so desperate right now. im tired.
What do I do?
the internet has no mention of this bug.
I've got the same message several times from the App Store Team a few minutes ago.
I think the problem was the Flutter SDK version...!
I used to use the latest version(Flutter SDK version 1.12.3-pre.26) at first but changed the Flutter SDK version to 'v1.9.1+hotfix.3' and the problem is resolved!!!
I solved the problem with the following instruction below:
Switching Flutter SDK version to 'v1.9.1+hotfix.3' with the command:
flutter version v1.9.1+hotfix.3
Archive and upload again ...
Problem Solved!!!!!! 🤩
This may be a recently-introduced Skia regression.
The code was included in Flutter v1.12.3, so v1.12.2 on the dev channel should work.
Flutter's Bad Build wiki page will be updated when there is a fix for this issue.
Update: This has been resolved in Flutter v1.12.5.
Since there have been a lot of problems with flutter recently(when I tried the fix mentioned in another answer I different error) I though I should include this https://github.com/flutter/flutter/releases
Just type flutter version [version code]
Trying to post to CocoaPods, but when the project goes through it doesn’t generate docs (site + docs button, instead of expand). Alternatively, when I specify a docs url the docs button doesn’t work either. According to the guides, it seems like jazzy isn’t parsing, but when I run:
jazzy
or...
jazzy —podspec MagicCloud.podspec
…it throws no errors and generates 100% documentation (which is hosted here). At the 404 page, If I select the Alternatively, click… or Potential error info buttons no luck. I’ve tried with and without a .yaml file generated here. When I try to use the following…
http://api.cocoadocs.org:4567/redeploy/MagicCloud/2.9.x // x = 5,6,7,8,etc…
http://api.cocoadocs.org:4567/error/MagicCloud/2.9.x // x = 5,6,7,8,etc…
…safari can’t find the server. I’ve posted so many versions at this point, any help would be much appreciated. The project is here, along with it's podspec file. Thanks in advance.
So after contacting Orta (the developer) directly, I eventually found out that he had handed the project off to Buddy Build. With their acquisition by Apple, they're holding off on new clients and are no longer offering support to Cocoapods.
As far as I can tell, no new Cocoapods have been able to compile their docs (at least through jazzy / swift), since the announcement January 2018. If anyone knows different, or if things change, please post here. Thanks.
I have an App that uses Admod and Firebase from Google. Since I am using Swift they want me to use frameworks when loading them from CocoaPods. When I try to archive/validate the App I get the error:
No suitable application records were found. Verify your bundle identifier 'org.cocoapods.GoogleToolboxForMac'
What is the correct way to provision an app that uses someone else's frameworks so it can be uploaded to iTunes Connect? I tried to find something in Apple's documentation but I haven't found anything.
UPDate:
I previously had answered my own question, since I had thought I had found a solution. My reply was:
Problem Solved. Turns out I was using an App-ID that I am having Apple look into as being corrupt. I had already created a new App-ID to prove the one I want to use is not working and retried with that and it Validates. This required a lot of help from the Google Ads Mobile SDK team. Thanks.
So the correct answer is: Now Incorrect
You should not get this error unless you are using a Bundle-ID that is not already registered on iTunes Connect, but, you should never be able to create an archive that does not have a Bundle-ID that is not already registered on iTunes Connect. So this is caused by an abnormal situation.
This is no longer true
I used my new working project and got 4 whole builds out of it and into iTunes Connect. In the process I was trying to clean up the mess caused by trying to solve this problem, like loosing my git history. I tried to modify my old App to get it to work and without modifying my new working project, But my new project started failing with the above error. I even used my time machine and went back to the directory as it was when I made the last build, but no help. So, any answers?
Further Update:
I pulled all the code related to Google Firebase and Admob out of the code and removed the cocoaPods and Archived/Validated and now I get the error:
You must supply a CFBundleIdentifer for this request.
Which is the error message I was getting with my other App-ID that tracked that App-ID in iTunesConnect. This time it does not track the App-ID so it must be something in my project. Will report what I find.
UpDate:
I think Apple has been modifying their code for validation at the same time I was trying different things. At one point it told me I was using CFBundleSignature instead of CFBundlePackageType set to APP and I fixed this and got the code to validate. Understand I am copying complete projects and renaming everything to debug this problem, so this must have come from the original program. I ended up with a project that was renamed from my original but archived/validated but when I went to compile for Test I got errors that I debugged until I got lots of Mach-O link errors. I decided to complete the loop and go back to my original code and try using the new Bundle-ID which points to the new App-ID, the one that works, and add all the knowledge I have learned. But when I get it done I have an project that can test but does not validate. The only difference is this project has the old identifier which has the same name as the suffix of the App-ID that has a bug.
Am I missing something?
Final UpDate?
On a whim I renamed the Scheme file to be the same as my Suffix to the Bundle-ID and I got my original Project to Validate! I have worked on this for over a month and you might not believe the astonishment I feel in this.
Back to Unit Test!
I have come to the conclusion that the Identity of the App, the name at the far top of the right side Utilities window, has something to do with the way iTunes Connect validates the App. This is the name in the left hand column of the Organizer window. It is like it overrides the suffix of the Bundle-ID and since I can't use that Identifier because the associated App-ID is corrupt. Or the name of the Scheme.
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.