As I released my app in AppStore, some users made feedback said that our app crashed when open it, and this situation happened only on iOS 9.2.x devices.
I have debugged the app in my test device. But in Debug mode the crash not happened anymore and I download app from App Store the crash happens again. Even more strange is that Fabric can't catch any crash report.
What can I do to find the reason of the crash and resolve this issue. Is there anybody have similar conditions?
Resolved！
I haven't notice that I have compile and upload this version by the newest version of Xcode -- Xcode 8.2.1, After I change to the old IDE, I found every things turns OK. And I found some useful documents there and some developers had also counted the similar question, this is their discussion.
So the final way to resolve this question is DELETE the P3 color space and 16 bit images.
Steps:
Create an Inspectable .ipa file. In the Xcode Organizer (Xcode->Window->Organizer), select an archive to inspect, click “Export...", and choose "Export for Enterprise or Ad-Hoc Deployment". This will create a local copy of the .ipa file for your app.
Locate that .ipa file and change its the extension to .zip.
Expand the .zip file. This will produce a Payload folder containing your .app bundle.
Open a terminal and change the working directory to the top level of your .app bundle
cd path/to/Payload/your.app
Use the find tool to locate Assets.car files in your .app bundle as shown below:
find . -name 'Assets.car'
Use the assetutil tool to find any 16-bit or P3 assets, in each Assets.car your application has as shown below. :
sudo xcrun --sdk iphoneos assetutil --info /path/to/a/Assets.car > /tmp/Assets.json
Examine the resulting /tmp/Assets.json and look for any contents containing “DisplayGamut": “P3” and its associated “Name". This will be the name of your imageset containing one or more 16-bit or P3 assets.
Replace those assets with 8-bit / sRGB assets, then rebuild your app.
Related
How do I install the XCUITest runner app and ipa on a real device and get the results?
I have a runner.app that was generated by building it for testing, and a deployed/signed .ipa.
Now what I would like to happen is to have it installed on a real device, execute it, and get the device log.
You can use bundleId :
let app = XCUIApplication(bundleIdentifier: "yourapp.bundle.id")
You can try to use:
xcodebuild test-without-building -xctestrun somepath/YourAppName_iphoneos14.4-arm64.xctestrun -destination 'platform=iOS, id=some_id'
I moved YourAppName_iphoneos14.4-arm64.xctestrun, YourAppName.app,
YourAppNameUITests-Runner.app to some local folder from a regular Library/Developer/etc.. build folder. Then I opened *.xctestrun file, which is an xml file, and modified paths to my local folder manually.
I couldn't find any official information about it but it seems like the *.xctestrun file is used by xcodebuild in order to find all relevant artefacts i.e both app folders. I would guess that's how they manage to run tests just with app's or ipa's without source code on various clouds...
PS. The question was about IPA, but it's convertible to the app, right? At least there is a thread - How to convert .ipa to .app file?
Edited with answer...
It is possible to achieve this. In order to build an ipa of the UI Testing app bundle you can follow these steps:
Open your project containing in Xcode.
Select the device you'd like to build the ipa for next to the scheme. This can be an actual device or a simulator.
Product > Build For > Testing
Find [your_ui_test_bundle_name].app file in Derived Data.
Derived data by default is located at ~/Library/Developer/Xcode/DerivedData/
To locate this file, dive into DerivedData for your project, navigating to Build > Products and then the respective directory based on what you chose in step 2. If you chose a simulator, look in -iphonesimulator/ or if you chose a device look in -iphoneos/. The UI test bundle .app file should be in that directory.
Create a directory named Payload case sensitive and it must be named this.
Move the .app file into the Payload directory.
Compress the Payload directory.
Rename the compressed directory to have a file extension of .ipa. You'll be prompted and select Keep .ipa.
Now you have you UI test bundle application saved as an ipa. You can also upload this ipa to a device manually in Xcode via the following process (bonus info, yay!)
Window > Devices and Simulators
Select your connected device.
Tap the + button under Installed Apps.
Navigate to and select your UI test .ipa file that you compressed previously.
It should install onto the device.
Credit where it is due: https://medium.com/ios-os-x-development/how-to-run-your-iphone-test-on-aws-device-farm-98f18086811e
I've added a 1024 pt icon to the app as necessary. Here, it is on a screenshot:
But when I try to upload it to the AppStore - it says I don't have it.
Here when I try to choose Icon assets in Xcode - it strangely give me options only to use AppIcon file from the libraries which are empty and nonexistent, not giving me an option to use Assets from my Assets file in project
Here on a picture all these options are from the library and empty
So, as a result I can't use my real icons and get this warning :
Anybody know how to solve this issue??
I also faced this problem yesterday,i spent a whole day and finally i solved this problem.
Here is my environment
1.cocoapod
2.macOS Sierra/macOS High Sierra
3.Xcode 9
First of all,make sure you have already set the assets which cantains appicon,and make sure you have set the 1024*1024 icon for App Store.
If so,you still get the problem while uploading the binary to App Store.Then there are two situations.
If you use cocoapod
**Also,you can not see the app icon properly after you run you app on you device.**It's because cocoapod's bug.Open the project directory,open the file whose path is [PROJECT_NAME]/Pods/Target Support Files/Pods-[PROJECT_NAME]/Pods-[PROJECT_NAME]-resources.sh,pull to the end,replace the code
printf "%s\0" "${XCASSET_FILES[#]}" | xargs -0 xcrun actool --output-format human-readable-text --notices --warnings --platform "${PLATFORM_NAME}" --minimum-deployment-target "${!DEPLOYMENT_TARGET_SETTING_NAME}" ${TARGET_DEVICE_ARGS} --compress-pngs --compile "${BUILT_PRODUCTS_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}"
fi
to
printf "%s\0" "${XCASSET_FILES[#]}" | xargs -0 xcrun actool --output-format human-readable-text --notices --warnings --platform "${PLATFORM_NAME}" --minimum-deployment-target "${!DEPLOYMENT_TARGET_SETTING_NAME}" ${TARGET_DEVICE_ARGS} --compress-pngs --compile "${BUILT_PRODUCTS_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}" --app-icon "${ASSETCATALOG_COMPILER_APPICON_NAME}" --output-partial-info-plist "${BUILD_DIR}/assetcatalog_generated_info.plist"
fi
then run your app,you can see the right app icon now and you can also upload binary properly.If it still does not work, use the following method.
If you don't use cocoapod,
it's a bug of APFS.
Once your app was archived right click it and choose show in Finder. Open the package contents and open this file inside of it: /Products/Application/yourApp.app/info.plist
In there you have to change all the DTXXX Values to be the same as in the latest version of Xcode 8.
DTXcode - “0833”
DTSDKName - “iphoneos10.3"
DTSDKBuild - “14E8301”
DTPlatformName - “iphoneos”
DTCompiler - “com.apple.compilers.llvm.clang.1_0”
DTXcodeBuild - “8E3004b”
DTPlatformVersion - “10.3”
DTPlatformBuild - “14E8301"
Save the plist file and go back to xcode where you need to export the archive for the App Store.
Last but not least download Application Loader 3.0 from Apple and upload the just generated IPA file.
I also faced this same issue few weeks back, though I had added the marketing icon of 1024 X 1024 with .png format and no alpha channel in the Xcode, the submission was denied and failed continuously with warning as shown below:
WARNING ITMS-90704: "Missing Marketing Icon. iOS Apps must include a 1024x1024px Marketing Icon in PNG format. Apps that do not include the Marketing Icon cannot be submitted for App Review or Beta App Review
I am not fully sure about the cause of issue whether it is because of Xcode 9 or Mac OS High sierra or Cocoa-pods, but I could solved the issue with following :
Added the 1024 X 1024 .png Appstoreicon with no alpha channel.
Archieve the Xcode project. (Just do Archieve, do not upload or export .ipa in this step.)
Locate your app's .xcarchive file clicking show in finder as shown below:
Then right click -->> Show Package Contents, go to Products folder -->> Applications -->> on your application's name, again right click and -->> Show Package Contents. Locate the info plist from there (you can clean up files by clean by kind in order to locate info.plist fast).
And change the BuildMachineOsBuild value to 16A323.
Then save the .plist file
Now export the .ipa file and upload that .ipa file to iTunes with Application loader.
The app submission should success, even with the WARNING ITMS-90704: "Missing Marketing Icon.
Hope it works for your case too.
The thread discussion is here:
Marketing icon missing issue:
Thanks
I had the same problem. I just dragged and dropped all icons to the assets. It fixed the problem
You can ignore those Error. You can upload a marketing image on iTunes Connect later.
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.
Xcode 5 organizer had a view which would list all the crash logs. and we could drag drop crash logs here. But since Xcode 6, I know they have moved devices out of organize and have a new window for the same. But I do not find a place where I view the crash logs which i drag-dropped in Xcode 5 after upping to Xcode 6. Anybody knows the answer ?
Writing this answer as much for the community as for myself.
If there ever are problems symbolicating a crash report, one can overcome them as follows:
Create a separate folder, copy Foo.app and Foo.app.dSYM from the corresponding .xcarchive into the folder. Also copy the .crash report into the folder.
Open the crash report in TextEdit or elsewhere, go to the Binary Images: section, and copy the first address there (e.g. 0xd7000).
cd into the folder. Now you can run the following command:
xcrun atos -o Foo.app/Foo -arch arm64 -l 0xd7000 0x0033f9bb
This will symbolicate the symbol at address 0x0033f9bb. Please make sure to pick the correct value for the -arch option (can be obtaned from the first line in the Binary Images: section, or figured out from the Hardware Model: in the crash report and the app's supported archs).
You can also copy the necessary addresses (e.g. a thread call stack) from the crash report directly into a text file (in TextEdit, hold Option and select the necessary text block, or copy and cut), to get something like this:
0x000f12fb
0x002726b7
0x0026d415
0x001f933b
0x001f86d3
Now you can save this into a text file, e.g. addr.txt, and run the following command:
xcrun atos -o Foo.app/Foo -arch arm64 -l 0xd7000 -f addr.txt
This will give a nice symbolication for all the addresses at once.
P.S.
Before doing the above, it's worth checking that everything is set up correctly (as atos will happily report something for basically any supplied address).
To do the checking, open the crash report, and go to the end of the call stack for Thread 0. The first line from the end to list your app (usually the second one), e.g.:
34 Foo 0x0033f9bb 0xd7000 + 2525627
should be the main() call. Symbolicating the address (0x0033f9bb in this case) as described above should confirm that this is indeed main() and not some random method or function.
If the address is not that of main(), check your load address (-l option) and arch (-arch option).
P.P.S.
If the above doesn't work due to bitcode, download the dSYM for your build from iTunes Connect, extract the executable binary from the dSYM (Finder > Show Package Contents), copy it into the directory, and use it (i.e. Foo) as the argument to atos, instead of the Foo.app/Foo.
You can refer this one too, I have written step by step procedure of Manual Crash Re-Symbolication.
Crash Re-Symbolication
STEP 1
Move all the above files (MyApp.app, MyApp-dSYM.dSYM and MyApp-Crash-log.crash) into a Folder with a convenient name wherever you can go using Terminal easily.
For me, Desktop is the most easily reachable place ;)
So, I have moved these three files into a folder MyApp at Desktop.
STEP 2
Now its turn of Finder, Go to the path from following whichever is applicable for your XCODE version.
Use this command to find the symbolicatecrash script file,
find /Applications/Xcode.app -name symbolicatecrash
Xcode 7.3 and newer (Xcode 8, ..., Xcode 14, ...): /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
STEP 3
Add the found symbolicatecrash script file's directory to $PATH env variable like this: sudo vim /etc/paths.d/Xcode-symbolicatecrash and paste the script file's directory and save the file. When opening a new terminal, you can call symbolicatecrash at any folder as commands located in /usr/bin.
Or
Copy symbolicatecrash file from this location, and paste it to the Desktop/MyApp
(Wait… Don’t blindly follow me, I am pasting sybolicatecrash file in folder MyApp, one that you created in step one at your favorite location, having three files.)
STEP 4
Open Terminal, and CD to the MyApp Folder.
cd Desktop/MyApp — Press Enter
export DEVELOPER_DIR=$(xcode-select --print-path)
— Press Enter
./symbolicatecrash -v MyApp-Crash-log.crash MyApp.dSYM
— Press Enter
That’s it! Symbolicated logs are on your terminal…
Now simply, find out the Error and resolve it ;)
Ok I realised that you can do this:
In Xcode > Window > Devices, select a connected iPhone/iPad/etc top left.
View Device Logs
All Logs
You probably have a lot of logs there, and to make it easier to find your imported log later, you could just go ahead and delete all logs at this point... unless they mean money to you. Or unless you know the exact point of time the crash happened - it should be written in the file anyway... I'm lazy so I just delete all old logs (this actually took a while).
3a. Make sure the log file has the extension .crash (rather than .txt or .ips)
Just drag and drop your file into that list. It worked for me.
For me the .crash file was enough. Without .dSYM file and .app file.
I ran these two commands on the mac where I build the archive and it worked:
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash /yourPath/crash1.crash > /yourPath/crash1_symbolicated.crash
There is an easier way using Xcode (without using command line tools and looking up addresses one at a time)
Take any .xcarchive file. If you have one from before you can use that. If you don't have one, create one by running the Product > Archive from Xcode.
Right click on the .xcarchive file and select 'Show Package Contents'
Copy the dsym file (of the version of the app that crashed) to the dSYMs folder
Copy the .app file (of the version of the app that crashed) to the Products > Applications folder
Edit the Info.plist and edit the CFBundleShortVersionString and CFBundleVersion under the ApplicationProperties dictionary. This will help you identify the archive later
Double click the .xcarchive to import it to Xcode. It should open Organizer.
Go back to the crash log (in Devices window in Xcode)
Drag your .crash file there (if not already present)
The entire crash log should now be symbolicated. If not, then right click and select 'Re-symbolicate crash log'
Xcode 11.2.1, December 2019
Apple gives you crash log in .txt format , which is unsymbolicated
**
With the device connected
**
Download ".txt" file , change extension to ".crash"
Open devices and simulators from window tab in Xcode
select device and select device logs
drag and drop .crash file to the device log window
We will be able to see symbolicated crash logs over there
Please see the link for more details on Symbolicating Crash logs
Follow these steps in Xcode 10 to symbolicate a crash log from an app build on the same machine:
Inside Organizer, locate the archive where the app is based on.
Click on the Download Debug Symbols button. Nothing will appear in your Downloads folder, but that's OK.
Connect the build machine to an iOS device.
Select the device in Devices and Simulators.
Click on the View Devices Logs button.
Drag-and-drop the crash file to the left panel. The file must end with a .crash extension, otherwise the drag fails.
Switch to the All Logs tab.
Select the added crash file.
The file should automatically symbolicate, otherwise use the right-click context menu item Re-Symbolicate Log.
You need access to the .dSYM package (folder) that contains a DWARF file, and you should open the .crash file with an editor.
Looking at the backtrace section, you should see something like this:
...
13 TheElements 0x0000000100f62ca0 0x100f5c000 + 27808
14 UIKitCore 0x00000001843e3044 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 356 (UIApplication.m:2328)
...
Binary Images:
0x100f5c000 - 0x101673fff TheElements arm64 ...
...
Note the long address in the stacktrace section, the 3rd column (0x0000000100f62ca0)
Note the short address in the 4th column (0x100f5c000)
Note the architecture in the Binary Images section (arm64)
Execute the following:
$ atos -arch <arch> -o TheElements.app.dSYM/Contents/Resources/DWARF/TheElements -l <short_address> <long_address>
You should get a result like this:
-[AtomicElementViewController myTransitionDidStop:finished:context:]
Authoritative source: https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS
Note: if for any reason you don't have access to the .dSYM file, you can recreate the .xcarchive using Xcode>Product>Archive, but make sure you are building the exact same code. Then you can extract the symbols from inside the .xcarchive package.
Make sure that your Xcode application name doesn't contain any spaces. This was the reason it didn't work for me. So /Applications/Xcode.app works, while /Applications/Xcode 6.1.1.app doesn't work.
From Apple's docs:
Symbolicating Crash Reports With Xcode
Xcode will automatically attempt to symbolicate all crash reports that it encounters. All you need to do for symbolication is to add the crash report to the Xcode Organizer.
Connect an iOS device to your Mac
Choose "Devices" from the "Window" menu
Under the "DEVICES" section in the left column, choose a device
Click the "View Device Logs" button under the "Device Information" section on the right hand panel
Drag your crash report onto the left column of the presented panel
Xcode will automatically symbolicate the crash report and display the results
To symbolicate a crash report, Xcode needs to be able to locate the following:
The crashing application's binary and dSYM file.
The binaries and dSYM files for all custom frameworks that the application links against. For frameworks that were built from source with the application, their dSYM files are copied into the archive alongside the application's dSYM file. For frameworks that were built by a third-party, you will need to ask the author for the dSYM file.
Symbols for the OS that the that application was running on when it crashed. These symbols contain debug information for the frameworks included in a specific OS release (e.g, iOS 9.3.3). OS symbols are architecture specific - a release of iOS for 64-bit devices won't include armv7 symbols. Xcode will automatically copy OS symbols from each device that you connect to your Mac.
If any of these are missing Xcode may not be able to symbolicate the crash report, or may only partially symbolicate the crash report.
The easiest process to symbolicate crash logs:
preserve the xcarchive file from the organizer during IPA building process for future use.
When the crash occurs, collect the crash logs from affected device. The extension should be .crash. If the crash log is in .ips format, just rename it to .crash.
Double click the xcarchive from the stored path to make it appear in organizer(if not present already).
open in xcode window->devices and simulators -> view device logs -> all logs -> drag and drop the .crash file.
Wait for 5secs. Bang! the application calls in stack trace will be symbolicated!
You may still see a lot of symbols though! those are internal library and framework calls.
This is the easiest one, tried and tested!
I was struggling to have the crash report symbolicated through atos but I was reluctant as the process seems cumbersome, But I found the crash report in the Xcode-> Window -> Organizer->Crashes(in left-side menu) Xcode will automatically download the crash logs and will symbolicate automatically, From there you can easily find the reason of the crash.
I've got an issue with how PhoneGap:Build is currently building iOS applications: splash screens are duplicated, greatly increasing the compiled file size of my applications.
Previously they had an issue wherein they were copying the wrong icon into the Android XHDPI icon folder for Android builds, and I was able to write a script that automated fixing this bug post-build since they seemed to show no interest in fixing the bug (almost a year now since the original bug report & while it seems it might be fixed presently, they haven't commented lately).
I know that I can rename an IPA to a ZIP, unzip it, and browse its contents. I could automate the following steps easily:
Rename
Unzip
Find & remove originals for splash screen images via config.xml file
Re-zip (& rename?)
...But I'm not sure where I'd have to go from there. I've found a few threads that discuss using Xcode to run different utilities, perform signing, etc; but they all seem to assume you've got an xcode project locally, which I don't. (I use PhoneGap & PhoneGap:Build specifically to avoid those headaches.)
I'll have access to all of the same key files that are uploaded to PhoneGap:Build for the original signing process, and I know all of the necessary passwords. I have Xcode installed (just not a local xcode project)...
Is it possible to re-assemble a "fixed" zip into a signed IPA for dev/release distribution using command line utilities & without creating a local Xcode project? If so, how?
Yes, this is possible.
You can export an IPA, unzip it, delete the duplicate file (assuming your code doesn't reference it), then re-sign the app and zip the IPA back up.
You'll find examples on how to use the commandline tool "codesign" to resign a .app directory on stackoverflow!