I have enterprise version installed on few of the devices.
On one of the device app is crashing immediate after the launch button click every time.
It is working on other device without crash. Can any one help me on the issue that why it is crashing ?
**edit:
We seems it certificate expiration issue. But if certificate is expired then it also should not work when I install it in new device.
Here are few steps will help you to find / detect / resolve your issue :
If its live version which you are testing than check out crash logs.
To check crash logs open Xcode -> window -> Organiser -> Select your app -> Crashes -> Select current version. You will find the crash
open it in Xcode it will help you to find the line which generating
crash
If its not live app than try to debug app on same device using debug ad hoc provisioning
Another way is you can also use crashlytics tool into your app. It will give you detailed information of the crash along with the
possible code which encouraging the crash
Possible reasons for crash :
Architecture support. Might be crash issue generated only on base 64 devices than check out your app is base 64 supported or not
Use of Depreciated methods can also cause the crash
iOS Compatibility issue can also be a reason of crash
Most important reason is if your app trying to access privacy information without permission alert than also it will get crashed at
very beginning of app launch
Hope it will help you.
We figured out this but posting bit late.
Few data systems and validation not matched in case of the Date Time system used. Date Time formats are different according to user and devices. Few systems have date formate as a month in the first 3 characters longer than the year(e.g. 1 Aug 2020). (from the same region devices, the date time format could be different). so this validation is very critical and needs to consider and all test cases. This was the issue we were facing as in the start we were opening the calendar and fetching the events accordingly.
Also displaying data on threads and managing threads are also more important in this kind of case. Memory leaks and appropriate GCD usage may also lead to this situation.
Thanks
Related
In the project organizer, one project I'm working on hasn't shown any crashes since I updated to Xcode 9. All of the previously shown crashes disappeared too. I have Fabric in the app, but I'm testing mostly on Apple Watch and Fabric doesn't support watch crashes. I submitted the bug to Apple's Bug Reporter several weeks ago but haven't received a response. Is there anywhere or any way else I can get crash reports, specifically for WatchKit?
Thank you!
You could try on your phone going to Settings -> Privacy -> Analytics -> Analytics Data. Scroll through the Data and look for crashes related to your application.
So, I recently uploaded about 9 apps that were mutations of an original one, just with different content and the same framework...
So, today all 9 of the apps went into review at the exact same time although they were each uploaded a day apart, which I thought was really odd. 5 hours later I get 9 rejection emails and the same rejection as follows:
2.2
We found that your app failed to launch on iPhone 5 running iOS 6, on both Wi-Fi and cellular networks.
We encountered the issue when selecting the application on the Home screen - the app displayed a launch image then quit unexpectedly.
This may be because iOS 6 uses a watchdog timer for applications; if
an application takes too long to complete its initial startup, the
operating system terminates the application.
For information about the watchdog timer, please see Technical Q&A: Application does not crash when launched from debugger but
crashes when launched by user..
Another possibility could be a missing entitlement. For more information, please see the Technical Note: Resolving "0x800003A",
applications not launching and "missing entitlement". For discrete
code-level questions, you may wish to consult with Apple Developer
Technical Support. Please be sure to:
include the complete details of your rejection issues
prepare any symbolicated crash logs, screenshots, and steps to reproduce the issues for when the DTS engineer follows up.
For information on how to symbolicate and read a crash log, please see Tech Note TN2151 Understanding and Analyzing iPhone OS
Application Crash Reports.
If you have difficulty reproducing this issue, please try testing the workflow as described in
https://developer.apple.com/library/ios/qa/qa1764/Testing Workflow
with Xcode's Archive feature".
I've uploaded a number of apps before and have never received this sort of issue.. So, I followed their suggestions and it's not the dogwatch timer, as the app runs absolutely flawless when ran from xcode on my iPhone 4s with iOS6, and also runs without any issues when I distribute it as ad-hoc enterprise, and sync the app through a .ipa file onto my iphone...
Although, before testing any of this I went through and revoked my development and distribution certificates, went through my keychain and deleted all instances of any certificates related to apps, and keys. Then refreshed everything. All my code signing / provisioning profiles are valid, I re-added my device to the provisioning portal as well.
Does anyone else have any ideas? I'd like to be positive I fixed the problem before uploading my apps again, waiting a week just to be rejected once again and have to start all over. Any help or leads would be greatly appreciated!
I have also double checked all of my info.plist bundle identifiers and they all match the dist and development profiles associated with each app.
I finally got around to finding a friend with an iPhone 5. The crashing WAS due to armv7s architecture being used. So I stripped out all architectures and used only armv7. Worked like a charm and the app ran as smoothly on my 4s as it did on my friend's iphone 5.
Did you try compiling in armv7 only? (forget the armv7s support). By the way, yeah, it's impossible to test it without any iphone5 hardware, and the simulator actually don't simulate anything. With only armv7 feature it should (i really say "should") behave like in iPhone 3G/4/4s on ios6.
Or did you have some runtime behavior depending on the device? What are you actually set on startup?
Look at this post:
http://wanderingcoder.net/original-armv7s-psa/
Even if it talk about linker error, here is the philosophy: Don't publish something you haven't, can't test. Use armv7s only when you will get rich an have an iPhone 5
I have an app that I occasionally receive support emails for that say the app crashed on them and won't open up anymore. It shows 'Default.png' then exits. Even when the app is deleted and reinstalled.
-I get no crash reports or memory issues (as reported by itunes connect using reports from a significant sample size >20k downloads)
-I've confirmed it's not limited to a specific model and not caused by jailbroken devices.
-The app doesn't have external dependencies, so why would reinstalling it not fix the problem?
What kind of problems could cause the crashing to go unreported and be persistent?
If you have an uncaught exception handler, depending on what you have in there, you will not get reports written out the same way, or at all, as if you did not have a handler. This will make iTunes think there is not any crash reports at all. Uncaught exception handlers are commonly added as part of analytics frameworks, or third party notification tools.
While this could answer your question, a more reasonable explanation is that the crashing devices just need a device restart.
I think every app developer with a sizable install base has struggled with an issue like this in the past.
Are you using any sort of analytics package, such as Flurry, that helps you report crashes? We used Flurry with much greater success over Apple - Apple won't start reporting crashes to you until you have many -- and "just a few" is never enough.
Additionally, if it shows the default.png and crashes, take a hard look at your start-up code. Are you setting something in NSUserDefaults, that if, corrupted, could cause the app to crash on startup?
Admittedly it is strange that a delete-and-reinstall doesn't do the trick.
The users aren't reporting the error reports to Apple. The crashes could come from any number of sources.
You could walk a user through the process of digging crash reports directly out of iTunes during the next Sync and email them directly to you.
You could try asking a user to delete the app from the device, reboot their device, then have them install the app again after a fresh reboot.
Some say it doesnt start on their HTC Hero, another says it doesnt open in their Cliq, etc. I built the entire app using my Droid X to debug. Now that the app is released, and the code is interacting with so many different types of hardware, how do I figure out what may be going wrong for these users?
In my Crash errors log I have one record of a crash, and I believe I've already fixed this. It was certainly not responsible for the crashes that users are complaining about.
Maybe you have to check manually or maybe it's a problem of multiresolution because different mobile have different resolutions. Otherwise if it is possible then you have to include crash log report in your application which send crash logs to your email id.
Or you can ask them to install crash log reporter and set your emailid to target for crash report. Try this link, first one for manually adding code to your application.
https://github.com/tomquist/Android-Error-Reporter
http://www.androidzoom.com/android_applications/tools/log-collector_tlt.html
Do you have any Logcat outputs in release mode? May be they help you out..
Alternatively, you can test it out on 3rd party mobile testing vendors.. Where in you can buy some hours and do some quick testing...
After submitting our application several times, we continue to receive the following response:
Thank you for submitting My App to the
App Store. We've reviewed your
application and determined that we
cannot post this version of your iPad
application to the App Store because
My App is crashing on iPad running
iPhone OS 3.2 and Mac OS X 10.6.2. My
App crashes upon launch.
Unfortunately, crash logs have not
been generated.
However, resigning the same build with the AdHoc entitlements and loading the build onto the device yields no such crash. After a number of attempts, the application simply does not crash as reported by the reviewer. Furthermore, the reviewer does not provide any useful logging that may have been generated by SpringBoard such as an exit status or event if it had worked properly for any other device. There are no calls to explicitly exit or quit the application in the code line and yet the application terminates on startup.
What might cause an application to terminate in such a manner?
Under what conditions is an application tested that might not be found under a development environment?
Could it be a result of a signing issue that the submission validation system is simply unable to catch?
Thanks in advance.
After fighting with this for weeks, the application has finally been approved. The key: signing corruption. Hence why the application would start (or at least appear to start by showing the splash screen) and then suddenly vanish without a crash log. It failed Springboard's preflight sighing check.
A good tool to keep in mind to check for signing issues. It tells if the application has a valid signing:
codesign -vvvv MyApp.app
When I built the application, I would cp it to a network storage device where our product manager would pull it down and submit it to Apple. If decompressed on the NAS, the code signing was valid. But if you coped the compressed application back off the NAS and validate it, it would fail.
The lesson: make use of the new XCode utility to submit applications.
A few suggestions:
Try to use the leaks tool of the static analyzer to see if there are any memory leaks or problems your not seeing.
Does your app use a web service? This happened to me one time because the day Apple was reviewing the app the web service went down. That cause a crash. If thats the case you would want to add something to catch that.
Finally, In the logs Apple sent you did they send you the dsym file? If they did you can run atos from the command line and it will convert the address to symbols. That will show you what thread and symbol it's crashing on.
Be sure you test with a variety of settings: with Wifi disabled/enabled, with 3G disabled, Airplane mode on/off, location services disabled, etc.
As a last resort, assume there is a problem in your code that executes at startup. Remove half your startup code, set your release date in the far future (just in case it gets approved), then resubmit and see if they have the same problem. If not the problem is in the half you removed... it's a binary search.
I think you have two options: try harder to reproduce the defect using the tools other people are mentioning or to catch those crashes in the field.
PLCrashReporter will trap on an uncaught exception and store all relevant information. Next time your app is run, it can send the crash report that you can then symbolificate and view a stack trace of.
Ouch! That's a tough one. I've had this kind of thing happen before, but it seemed it was reproduce-able when I switched to a different device (iPhone 3G vs 3Gs, etc.). In your case though, it sounds like you're iPad only, so that might not help. There's a difference between 3G and Wifi, I suppose, but I would be really surprised if that was causing a crash on one and not the other.
One thing you could try if you think Apple's not doing their part is to change the binary name and re-submit it under another app name/record. See if you get the same response. If you get the same reviewer, you might, but I think there's a good chance you would get a different reviewer with a new app. Just set your app release date to some time in the distant future and it will never actually show up in the app store if they approve it. If the new app comes back rejected for the same reason, you've got work to do, but if they do in fact approve it, then I would get on the phone with them and point out the discrepancy.
My approach would be to make sure that the compilation is absolutely clean both in the static analyzer (this is NOT optional, it will save you time!) and for the build itself. Then set everything as described on CocoaDev' NSZombie page. Then make sure you have an iPod running 3.2 (actual hardware, not simulator) and test, test, test. Do it with network available and not available, with the device nearly full and freshly restored, every other variation you can think of. Run it with the debugger active and as a release build disconnected. Use Leaks, Instruments and all the other tools to peek in there and get a better feel for what is happening. If you exhaust every possibility you are going to have to beg for more detail from Apple but I bet you find a problem - one of the most important things in debugging an issue like this is to try to forget everything you think you know for sure and start at the beginning.