When I upload IPA on app store, I get this error:
Too many symbol files - These symbols have no corresponding slice in any binary [0B523B17-252B-35C1-A94E-EC1B5FE7AC6E.symbols, 1202FC31-64F7-35A5-A83A-BE08401F5617.symbols, 2CE5B047-5CDC-3C9B-B5FF-106501E63EB7.symbols, 2DF3956E-9B95-398E-9A4C-19CDF609E899.symbols, 6D4E71D5-9B85-3D1F-9E36-ADF9C56BC827.symbols]
So it seems that this issue happens when you are including debug information of your libraries with the project archive but are not including binaries as stated in this SO post. Furthermore, a recent blog featured the same issue:
The issue came up because the application has disabled bitcode in the
build setting, therefore libraries produced by CocoaPods doesn’t need
to produce symbols for unused architecture. For instance arm7 for
arm64 only apps.
Some steps you can follow to check which target has a valid architecture:
Open Xcode -> Window -> Organizer
Select the archive and Reveal in Finder
On .xcarchive file, Show package content
Open terminal and give path of dSYMs folder.
Enter command dwarfdump --uuid * and it will show list of UUIDs with valid architectures.
You will find the matching UUID's in the email you've received from Apple.
Try to check as well the existing GitHub issues related:
https://github.com/CocoaPods/CocoaPods/issues/7111
https://github.com/Instabug/Instabug-iOS/issues/188
https://github.com/flutter/flutter/issues/59237
https://github.com/CocoaPods/CocoaPods/issues/9664
To dig deeper into your issue, its good to provide more details like output of your flutter doctor -v and more context describing how you end up with this issue.
Related
I have a lot of frameworks in my app. App works fine in adhoc/enterprise release. Only if I submit to the app store for testflight testing I get this error email from apple:
Dear developer,
We have discovered one or more issues with your recent delivery for "My app's name here". To process your delivery, the following
issues must be corrected:
Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path.
Once these issues have been corrected, you can then redeliver the corrected binary.
Regards,
The App Store team
there is no specific information here. How can I debug it?
Got an answer from Apple Developer Technical Support which says it is a bug on Apple's side. this is the suggested workaround below which did not work for me:
To diagnose this issue, you should export the IPA you are sending to
the App Store from Xcode. Since IPAs are zip files, you can
decompress it by right clicking and saying Open With > Archive
Utility. You should find your main executable inside the unzipped
folder structure and run otool at the command line to see the library
list: otool -L
The list of paths you get should match what you find inside of your
IPA. All of your libraries should start with #rpath. A simple
comparison of everything in this list with the unzipped IPA folders
should reveal what is missing.
Once you know what is missing, go to your Xcode build phases setup.
There should be a build phase for either Copy Files or Embed
Frameworks that includes the missing library — you should just add the
library to the list. If you don’t see either of these build phases,
you can recreate it by adding a new Copy Files build phase, setting
the Destination to Frameworks, and adding the library to the list,
ensuring that Code Sign On Copy is checked.
If you don’t find anything missing in your main binary, make sure to
do the same search on any other binaries you may have, like for a
watchOS app or an iOS app extension.
If you find that all of the frameworks are in this build phase, please
take a look at the Embedded Binaries section of your app target’s
General page, and let me know if you see multiple levels of ../ next
to the binary that you found is missing.
Please let me know if it works for you!
I have encountered the same issue when uploading an app with watch support to the app store.
I was able to solve it with the hint from the first answer, using otool -L to analyze the binary from the ipa or xcarchive.
However, the problem was not with my frameworks (at #rpath) but with a swift lib. I noticed that libswiftWatchKit.dylib was missing in the frameworks folder.
The solution that worked for me was as simple as to set EMBEDDED_CONTENT_CONTAINS_SWIFT=YES in the build settings of the watch app (or the watch app extension, but not both). After that, all necessary swift libraries were correctly copied to the watch app path in the archive and upload to app store was working correctly.
Apparently, the watch app works and upload passes if you provide the necessary swift libraries only in the main app's folder.
After adding the custom Swift framework to my project I got this email after uploading the app to iTunes connect.
I got this email from iTunes store,
Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path.
The fix is simple for this issue,
Step 1: Make sure your Custom framework is added to Embedded Binaries in General tab of your target.
Step 2: Under build settings,
Set Always Embed Swift Standard Libraries = Yes for your main project target.
And Set Always Embed Swift Standard Libraries = No for your custom framework target.
This solved my problem and I was able to upload binary to iTunes connect.
Ref
Tried all the above solutions and did not work for me.
I was experiencing this issue in Xcode 10.1 recently and all my frameworks were referenced correctly (did otool -L and everything lined up).
Seems there were some changes in the apple validation process, may be a bug, may not be on Apple's end, but all my prior builds uploaded and validated fine -- and I did not add any new frameworks since.
Upon uploading the binary to iTunesConnect, I'd see the following error:
Invalid Bundle - One or more dynamic libraries that are referenced by
your app are not present in the dylib search path.
Invalid Bundle - The app uses Swift, but one of the binaries could not
link to it because it wasn't found. Check that the app bundles
correctly embed Swift standard libraries using the "Always Embed Swift
Standard Libraries" build setting, and that each binary which uses
Swift has correct search paths to the embedded Swift standard
libraries using the "Runpath Search Paths" build setting.
MY SOLUTION:
After days of debugging, what worked for me was to disable 'Include bitcode for iOS content' upon uploading the archive from Xcode organizer. Seems that this option modifies the binary which caused the validator to fail.
Or you can disable bitcode in your Build Settings
My Problem:
I had the same error with embedded frameworks.
The App project has Custom Framework project
Inside the Custom Framework project is another Custom Framework project
The app built to the simulator and to devices with no problem but failed the Apple test, returning "Invalid Bundle".
I inspected the package just like Taha had been told to by Tech Support and everything was present and correct!
My Solution:
I restructured the project so that the two custom frameworks sit side by side and one is no longer embedded within the other.
This looks to be an Apple validation problem since everything works fine on devices and the simulator but the work around was straight forward.
In my case, in the build settings, this was fixed when I added the following to the build settings for the library:
DYLIB_INSTALL_NAME_BASE = #rpath
The clue was a linker warning: 'YourLibrary has an install name beginning with “/”, but it is not from the specified SDK'
Had same issue. This happened to me because one of my Framework target was added to main target in "Link Binary With Libraries" but was not added to "Target Dependencies" and "Embedded Binaries"
I also received a similar mail from Apple:
Dear Developer,
We identified one or more issues with a recent delivery for your app,
"********. Please correct the following issues, then
upload again.
ITMS-90562: Invalid Bundle - One or more dynamic libraries that are
referenced by your app are not present in the dylib search path.
Best regards,
The App Store Team
I used my own framework for my watch app. I solved this issue by changing the framework option to "Embed Without Signing" in the Extension Target. The default option was "Do Not Embed".
I had the same problem, it was due to one framework not being present in the Frameworks subfolder in the app bundle.
I fixed it by adding a Copy Fields build phase, and adding the missing .framework file there.
This error message is also addressed in Apple Technical Note TN2435
Embedding Frameworks In An App: https://developer.apple.com/library/archive/technotes/tn2435/_index.html
You can find the error message under the heading "Missing Framework Bundle" with troubleshooting steps.
We had the same problem, and even after going through all the steps (see "Missing Framework Bundle"), the only thing that worked was disabling Bitcode.
So I struggled on this for two days. What it turned out to be was I had UITests checked in Archive for the Build for the Scheme I was archiving.
After unchecking it from Archive, re-archiving it, validating it (although validating it before always passed), and "Upload to AppStore" I did not get the e-mail from Apple informing me of Invalid Swift Support. Instead I got the e-mail that it'd been processed and is good to go!
In my case, I've had to add a framework from Notification App Extension to the main target (embed & sign in the main target, do not embed in the extension) - even though there was no mention about it in otool -L output.
Funny thing that Iterable official doc says that the framework should be embedded & signed in the extension - which would lead to another upload problem because of nested bundles.
I've Googled this extensively, and either the situation someone's experiencing involves a different Xcode version (and therefore different build options), or a presence of a dSYM file.
So, here's the situation. I received a crash report through Xcode. It's just memory addresses. Trying to open it in project gives me the same memory addresses. Thought about manual symbolication but for that I need my dSYM file corresponding to the archive I built. But when I 'Show package contents' for the archive I built in finder, its dSYM folder is empty.
My Xcode settings at the time of archiving were:
DEBUG_INFORMATION_FORMAT: DWARF with dSYM File
STRIP_INSTALLED_PRODUCT: Yes Switching to No makes no difference.
DEPLOYMENT_POSTPROCESSING: No Switching to Yes makes no difference.
Also, I selected 'Include symbols' when uploading the archive to iTunes Connect.
The process for deployment with Apple is confusing-as-hell enough, without having to worry that when a crash does happen, the resport is in fact readable!
So my questions are:
1) Why was my archive missing a dSYM file?
2) If the dSYM file would've been generated, where could it be?
3) If I really do not have a dSYM file, can I still somehow get human-readable symbol names? I've got the original archive I uploaded and access to source code for that build.
3a) If I Product>Archive again (and assuming this time a dSYM does get generated), can I use this dSYM file instead? Or will it have a different UUID, causing it to be incompatible with the crash log cause...well...Apple?
Xcode version: 6.4
Here's what my crash log looks like in Xcode Organizer:
Thanks.
EDIT:
I upgraded to Xcode 7.3 before trying this but it may also work for version 6.
The solution to question (1) is to set the following in project build settings:
GCC_GENERATE_DEBUGGING_SYMBOLS
On XCode 8.3.2, select Yes on Generate Debug Symbols
For question 1), I also don't know. It may be a bug of Xcode. You can archive
the same code again, then generate a same dSYM file.
For question 2), you can search 'dSYM' in the folder '~/Library', because 'dSYM' file output in there generally. If not found, try searching it in the entire disk.
For question 3), you must have the system library symbol file that the crash log listed in 'Binary Images' section. You can find it in '~/Library/Developer/Xcode/iOS DeviceSupport'. If not found, you can connect an iPhone with the same OS version showed in the crash log to Xcode. After Xcode finished processing it, the system library symbol file of the iPhone can be copied to the folder. Then, you can re-symbolicate the crash log.
For question 3a), For the same app code, different Archive may be have a different dSYM file(UUID). If you use it to symbolicate the crash log, the symbolicated crash line is very close to the real crash line, so this can also help you to infer the real cause of crash.
From your screenshot, there only one line from your app code not be symbolicated. Now, you can generate the dSYM file of your app through using the app code which causes the crash to archive again. After you generate the dSYM file, use command line dwarfdump -u yourApp.app.dSYM to get UUID of it,Then check the uuid if contained in the first line of 'Binary images''. If NO, you can modify the UUID in the first line of 'Binary images'' to same as the new UUID which got from dwarfdump -u XXX.dSYM, Note the cpu architecture. Finish this, you can re-symbolicate the crash log in Xcode, or use command line symbolicatecrash crashreport.crash yourApp.app.dSYM. Note, you must guarantee the version of your app code same as version in the crash log, if not, the result is unbelievable.
Last week i was able to upload my ipa to iTunesConnect just fine. But as of today I am getting the following error when uploading via Application Loader:
ERROR ITMS-90635: "Invalid Mach-O Format. The Mach-O in bundle "Application.app/Frameworks/PSPDFKit.framework" isn’t consistent with the Mach-O in the main bundle. The main bundle Mach-O contains armv7(machine code) and arm64(machine code), while the nested bundle Mach-O contains armv7(bitcode and machine code) and arm64(bitcode and machine code). Verify that all of the targets for a platform have a consistent value for the ENABLE_BITCODE build setting."
I am aware of the solutions proposed here: Xcode - Error ITMS-90635 - Invalid Mach-O in bundle - submitting to App store and in many others.
I have however no idea how to apply any of the proposed solutions to a Xamarin iOS project. I am not using any pods, instead I am using a Binding library for PSPDFKit, which I have created as described in the official documentation https://pspdfkit.com/guides/ios/current/other-languages/xamarin/.
As far as I can see there are two ways for me to go, either to enable bitcode in my project (which I have no idea how to do) OR to disable bitcode in the binding project for PSPDFKit (which I have also no Idea how to do).
I am grateful for any help or propositions.
I finally was able to do it, with one of the solutions from this post https://stackoverflow.com/a/37624641/2702513
What I had do do, was stripping the Bitcode from my library, which can be done with this command:
$ xcrun bitcode_strip -r {PATH_TO_LIBRARY} -o tmp.dylib
The command extracts the machine code from the library into the tmp.dylib file which then can be used instead of the library itself. In case of PSPDFKit the library is inside the framework.
XCode:4.6 Lion:10.8 IOS 6.1 error: SBTarget is invalid , how to solve this?
After hundreds of times testing, I find a way that can help the programme run,
here is it:
When you first meet SBTarget is invalid, choose Product --> Clean
Run again, this time you may also get error: SBTarget is invalid, it doesn't matter.
Turn off the XCode totally, 'totally' means that the Xcode icon should not appear in the Dock.
Double click your project file(xxx.xcodeproj , the blue one) to start Xcode, run again. (Do not Clean this time), and it runs ok.
Let me know if this can help you or you have any other methods. Thx
I had this issue while incorporating the Facebook SDK into my app. The error would alternate between SBTarget is invalid and telling me that my architecture was incompatible with my device so it would not launch. If I followed alexqinbj's advice it would run the app once but then it would go right back to having the same error again. I tried messing with architectures and build settings and removing derived data but in the end it really was just a duplicate file in my file structure. Facebook told me to add their SDK and then to add a folder (that the SDK file already contains). Once I saw that it was just a matter of removing the duplicate file. I've heard of this error happening with duplicate plists as well. Good luck
Indeed, the root cause (in Facebook integration) is the duplicate resources in the Facebook SDK (as per their instructions). When I deleted the resource files (remove references only), this problem went away permanently. Not sure why Facebook instructions ask you to drag the resources bundle over to the Facebook SDK framework you just brought in...
TARGETS -> Build Phases, remove info.plist from Copy Bundle Resources. Clean and run. It works for me.
Unfortunately, the accepted answer didn't work for me. I can provoke this error with 100% certainty. It is not necessarily an internal consistency issue with XCode that can be resolved through cleaning, rebooting and rebuilding.
SBTarget is Invalid is an internal XCode error. It happens when attaching a debugger and the architectures specified in the XCode project do not match up with the binary.
On OS X, you can diagnose this by going to the binary on the hard drive and typing:
lipo -info <bin>
Then comparing this to the build settings ARCH and ONLY_ACTIVE_ARCH. They must match. It is not enough for ARCH to be a subset of the possible architectures contained within the binary.
There are any number of reasons why they might not match up. Here are some suggestions:
You are using an external build scheme. XCode therefore does not dictate the contents of the binary. The build settings merely tell XCode what to expect when launching GDB or LLDB.
The executable specified for launch in the scheme is not correct. If it can't find the executable, the architectures will not be present.
This error has a very distinct cause in my case. Whenever "Expand Build Settings in Info.plist File" was set to "NO" in Xcode's "Build Settings", this message came up. Will submit rdar to Apple.
We have a pretty major application suite for a client with a couple application targets utilizing several static libraries that we made in house. All targets are contained in one XCode project file.
For some reason when archiving an application the dSYM file does not contain any debug symbols for static libraries. The result is when trying to symbolicate crash logs from field agents we cannot see what is going on inside those static libraries.
I attempted to create a new simple XCode project with one application target and one static library. Even then the debug symbols were missing. I fiddled with the build settings according to this https://github.com/TheRealKerni/QuincyKit/issues/91 without luck.
If I build FOR archiving the debug symbols are included. I ran dwarfdump on the resulting dSYM file and was able to see the symbols for the static libraries implementation files. However when I then attempt to archive the project the symbols are excluded.
Am I missing something? XCode version 4.4.1
I m using XCode 5.1.1 and was having the same problem.
The fix was to set "Strip Linked Product" setting under "Deployment" section to "No" for each dependent library project. For more detail, please see my post at
can i debug ios app installed from ipa archive
This appears to be fixed in a later version of XCode, currently using 4.6 and the problem went away.
If you are stuck using an older version then do the following:
Product > Build For > Archiving
Product > Archive
Open the built product from derived data, you can do this by right clicking on the Youapp.app file in Products group and selecting show in finder. Ensure you are in the Release-xxx folder. Copy the dSYM file generated there and replace the one produced by the archive process. To find where archived files are go to Organizer, Archives tab, right click on an item and show in finder.
Hope this helps.
By default, archive uses release build, which already stripe debug symbols. you can change archive build option to 'not stripe'.