I am getting this warning when submitting an iOS binary to Apple:
"This app references non-public selectors in Payload/x.app/x: base64EncodedString, dataFromBase64String"
I do not get a warning during the build in xCode.
I am using xCode 5.0.2 and Phonegap 3.3.
I don't know if Apple will reject the binary for this reason, but I don't want to wait to find out. Also, I like to resolve all warning errors the "right" way.
I have found other people having similar issues (different third party libraries) and it seems their solution is to get updated third party libraries. I am already using the latest phonegap and there has been plenty of time for this to have been resolved, so I suspect this problem is unique to something I am doing.
I have greped by project and the two symbols are referenced here:
Cordova/NSData+Base64.h:+ (NSData*)dataFromBase64String:(NSString*)aString;
Cordova/NSData+Base64.h:- (NSString*)base64EncodedString;
My two questions are:
1) Will Apple reject this binary because of this warning?
2) How can I resolve this warning message the "right" way?
I am answering my own question....
Upon further investigation we determined the problem was that we only
included libCordova.a in the project. This worked okay when testing
in simulator and on device, but gave the above warning on submission
to the appstore.
The solution to avoid the warning on submission was to copy all the
source code for libCordova.a into /platform/ios. That source code
originated from the "cordova create" command.
Related
I am really frustrate whats going on with iOS application new version uploads. Here are the story.
On the date of 25th Jan 2018 we have uploaded new version 3.3.27 build number 1.0. That successfully process and available on test-flight for testing. After that we found some issue and on 26th Jan 2018 we fix it and uploading new build 1.1 and we get email from iTunes Connect said:
Dear developer,
We have discovered one or more issues with your recent delivery for "appname". To process your delivery, the following issues must be corrected:
Non-public API usage:
The app contains one or more corrupted binaries. Rebuild the app and resubmit.
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.
If you think this message was sent in error and that you have only
used Apple-published APIs in accordance with the guidelines, send the
app's nine-digit Apple ID, along with detailed information about why
you believe the above APIs were incorrectly flagged, to
email#apple.com. For further information, visit the
While i am validate build before upload its success:
While i am uploading app i get following success:
In mail i did not get proper information what's the name of corrupted binary or framework. What is the method we used that non-public we have uploaded 100s update build of that application before 25th Jan everything is good and acceptable.
Then i have try following changes:
Rebuild app and submit again get same email.
Uninstall Xcode9.2 and Install again get same email.
Remove changes and upload build number 1.0 again get same email.
Change Mac and try to upload new build again same email.
Try to upload old version that live before and again same emai
We sent an email to iTunes Connect Review but since 3 days we did not get any reply from them side. I do research and from 26th Jan many user face that kind of issue while submit application.
If any one know that solution who face that kind of issue in past or recently Please help us
After a LOT of investigations on this part we finally found the problem for this issue:
It seems like Apple gives this error for applications that suport both 32 and 64 bits.
Apple gave this reminder for Mac Appstore, but it seems that iOS applications are affected as well.
So a solution for this is to support bitcode OR to drop support for 32 bit devices by removing support for ARMV7 and ARMV7S or bellow from Valid Architectures from build settings. This will mean your application will work only on iPhone 5S and above.
I hope this helps someone.
Thank you and happy coding!
There is not one solution for this issue Apple not mention anything now a days about that errors or invalid binary related news on their official account or forums or their official Developer site. Even they are not reply of your email.
Some of get that issue solved by BitCode enable, Some of solve that issue for update PODFILE, Some of Solve that issue by remove some old swift framework used in project.
But finally I get solution by my self that works for me. When i build the project i found some warning at left side panel of Xcode like following.
I think apple now removed old swift support so in case your project use any swift class or podfile we need to update to swift 4.
Once i conversion to swift 4 i get following warning:
The use of Swift 3 #objc inference in Swift 4 mode is deprecated.
Please address deprecated #objc inference warnings, test your code
with “Use of deprecated Swift 3 #objc inference” logging enabled, and
then disable inference by changing the "Swift 3 #objc Inference" build
setting to "Default" for the "appname" target.
For fix this warning i use following link The use of Swift 3 #objc inference in Swift 4 mode is deprecated? and in swift class i used #objc before public declaration.
Also i review all the source code and remove unused library of podfile and class from project.
by above way i fix that issue and after uploading 13th of build finally that accepted.
The non-public API refers to Apple API methods that are not documented and offered to the programmer.
Apple does not guarantee that this part of the API will work in future upgrades. They can freely change this part.
They forbid usage, so that your app won't break in iOS updates, and so protect your future users/buyers of your app!
The webservice is external, hence does not fall under non-public. This part you need to guarantee, not Apple.
In Target -> Build Settings -> Other Linker Flags, remove -interposable. Rebuild app solved the problem.
We found 2 solutions for the issue. Remove 32 bit support, which was referred above. And remove CommonCrypto usage. We replaced CommonCrypto by CryptoSwift (https://github.com/krzyzanowskim/CryptoSwift).
We chose to replace CommonCrypto as we didn't want to loose our 32 bit users (iPhone4S, 5 and 5C).
When submitting our app to the app store the validation process for the build keeps getting rejected with the following error.
Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path.
Has anyone else had issues with this error? I feel like I've tried just about everything. I'd done the suggested otool -L on the main app as well as the watch app. The only library that it shows linked for is the Mixpanel library. The only other two libraries we are using is Fabric and Crashlytics. From my understanding those are not actual real frameworks? I've also tried to set ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES to YES as many posts online suggest. The project builds and runs fine so I'm completely lost as to how to resolve this issue.
This is a React Native iOS app if that has anything to do with it. I'm not the most experience when it comes to iOS stuff but I can find my way around xcode. Anyone have any suggestions? Maybe the best solution is to just create a new xcode project and set everything up again and copy/paste in the code from the previous project?
I am having issues uploading my app to iTunes Connect for Testflight testing. I don't receive any errors when uploading the build through Xcode 7.0, but after my build attempts to processes on iTunes Connect I get the following automated email from Apple:
Dear developer,
We have discovered one or more issues with your recent delivery for "MY_APP". To process your delivery, the following issues must be corrected:
Address Sanitizer Detected - The executable ${executablePath} links in the Address Sanitizer. Please remove Address Sanitizer usage before submitting to the App Store.
Once these issues have been corrected, you can then redeliver the corrected binary.
Regards,
The App Store team
I've ensured that "Enable Address Sanitizer" is unchecked for all of my build schemes. I cleaned the build folder and attempted to upload a clean build, but am still having the same issue. I don't see anything in the build settings related to Address Sanitizer.
Is there something else I need to do to remove Address Sanitizer?
we hit this same problem and our team spent the last 48 hours trying to isolate it. Turns out that it was a naming conflict in one of the bundles that we were including. Since the bundle is part of our standard SDK stack that we include in every game submission and we never had any issues with it before, I am assuming that something was upgraded on Apple's back-end to include checks for a lots of the new xCode features which caused the naming conflict during the post submission auto-code checks.
it took us over 20 submissions to isolate the offending bundles and renaming them fixed the problem. If you're hitting this issue, I suggest going through your plist to see if any of the bundle names have used keywords that are reserved for Address Sanitizer usage. It was one of our engineers that identified the problem and he's away on vacation for the next week but apparently, he replaced the hyphens in the bundle name with underscores and the problem disappeared.
Wanted to share this one quickly and hope it helps folks that are stuck on this issue as it was an absolute nightmare for us to pin down.
Thanks to some help from #Erik-Kerber, I managed to get a build through.
I was running the GM of Xcode 7 (7A218). After updating to the release build (7A220) from the App Store my app successfully passed iTunes Connect processing.
My build also get rejected.
I am using Fabric / Crashlytic library in my project.
I was also having the same issue and the same mail i got from Apple when my build rejected by Apple.
But after replacing my Fabric/Crashlytics library with updated library it get solved and accepted by Apple Succefully.
Today I cannot submit the binary to App Store, with the error "Invalid binary, the binary is missing architectures[arm64]".
But in "build settings"->"architectures", it does have arm64.
The previous version can be submitted successfully, and I haven't modified project settings.
As TimT stated in this thread: https://devforums.apple.com/thread/244448, It is apparently a bug.
However, it's still not resolved...
Not enough reputation to post image, please search "TimT" for his reply.
UPDATE:
It has been fixed. "Yes, there was a fix recently applied to the server. Everyone should be able to submit 32-bit apps again." - by TimT in the same thread. I tried again and everything is fine now.
After a long period of trying and trying to fix this issue, I haven't got any solution, but to install the older version of Xcode 5.0.2 and submit the binary with that one.
Cheers :)
I had the same error in the morning and apparently it was one of the 3rd party library/framework that it was missing architectures[arm64].
Seems that app must support arm64 now.
In my situation, I used some third party Library which doesn't support arm64.
I deleted the Libraries, and it's OK now.
The Architectures setting looks like below:
Once I tried to validate my iOS application on the appstore, I got the following error on XCODE:
Your app contains non-public API usage. Please review the errors, correct them and resubmit your application.
The error doesn't provide an explanation on which are the non-public classes that we used. How can I get it?
The app references non-public symbols in Payload/...app/libsqlite3.0.dylib: _dispatch_sources_type_vm, guarded_close_np, guarded_open_np
I have tried to solve the problem by removing libsqlite3.dylib from xcode and by adding linker flag '-lsqlite3' or '-libsqlite3' (with the last flag the app did not compiled).
How can I solve it?
You could also just download the sqlite amalgamation and include the sqlite source code into your app. That would not link to the system libsqlite3.0.dylib and the problem would be avoided. Your app binary would get a little bit bigger, but the build/validation problems would go away.