I've gotten a few reports of my latest update crashing on launch from some users.
The previous versions of my app had a Settings.bundle where I had a few settings that could be changed. In the latest version I removed it and the code that retrieved values from it. I did notice that I forgot to remove a call to [NSUserDefaults resetStandardUserDefaults] in my app delegates applicationWillEnterForeground method.
Would calling this cause the app to crash in some cases? I've not been able to reproduce it and haven't received any crash logs from the users who reported the issues yet so I can't see where it's crashing or what it's crashing from. Other users who have upgraded haven't had a problem so I'm not sure why it would affect some people and not others.
Related
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
I have an app that is crashing on the device (works well in the simulator) which leads me to assume that maybe it's a memory issue...
When it crashes, there is no message whatsoever reported in the console.
It does not crash each time a certain action is taken, it crashes at different points of time always after the app has been running and in use for some time.
I know I'm supposed to ask a more specific question - but if anybody is able to tell me where to start trying to track down a crash that does not report in the console, I would really appreciate it!
I am now using the latest version of XCode (4.2)
Thanks in advance...
It very-well could be a memory issue. If that is where you want to start your diagnostics, you can use the built-in Xcode profiler. In Xcode Product->Profile will get you started.
Maybe setting the NSZombiesEnabled value to YES in Project -> Edit Active Executable -> Arguments -> Variables is also helping; this will show you memory access errors based on accessing released objects. But in that case you should at least get a SIG_ABRT or BAD_ACCESS error ...
You can also log when the app receives a memory warning in the didReceiveMemoryWarning functions of your view controllers - this is called before the system is throwing out stuff when memory gets low. That of course could lead to a crash with nothing showing.
First, relax.
Then read this Technical Note.
Now, follow these steps:
From /Users/<username>/Library/Developer/Xcode/DerivedData remove all folders.
From /Users/<username>/Library/Application Support/iPhone Simulator remove all folders.
Clean your trash.
Remove app from device.
Build and run application on device.
Follow the steps that leads toward a crash.
Now, go to XCode->Window->Organizer and select "Device Logs" your device from the DEVICES pane. Select the most recent of these which has your application's name. Wait for XCode to symbolicate the crashlog. There are two possibilities now:
Its a low memory crash.
Its a memory management related crash.
If its option one, profile your application in Instruments.
If its option two, you should see the stack frame where you application is crashing (or your module's stack). This SO question will be very helpful
If you cannot understand the output (or you think the crashlog is not symbolicating - or that its not your code that's crashing), please post the crash log's crashing thread's stack here and I'll look into it.
PS: in the first section we do the first two steps to make sure there are no left-over .app/.dSYM files which might hinder symbolication later in the process because XCode symbolicator is not that intelligent.
My app has been (correctly) rejected by Apple as it crashes when you try to use the offline maps. The crash is in the route-me code libraries so the crash log isn't that helpful. In test it is fine, and does not crash, so I can't recreate the test condition successfully.
I am running on the same version of iOS (4.3.3) as Apple. I've tried forcing the location code to return a location on California.
Has anyone else experienced the same problem?
When I had problems with getting an app accepted to the App Store on Apple's end but not my own it ended up being some of the build dependencies for an external library I was using. I had set them in my Debug build but not my Release builds. Since I didn't test on Release builds, I never noticed the crashing. Apple did however, since that's what I sent them.
It may be an issue on their end.
This happened to me ( iPhone Crash with "No Backtrace" ). I resubmitted with no changes and my app was approved. Months later I have never reproduced or heard complaints of a single crash.
I'd recommend resubmitting an identical binary. While you wait for approval, try re-running a clean build, deleting and reinstalling the app from your device, and ad-hoc testing on "clean" devices that you haven't deployed to before to try and reproduce the crash.
I had the same problem with Apple. When I was running my app with offline maps on the iPhone simulator, iPhones or iPad, I had no problem. But with Instrument, the app was crashing when I set the delegate of the MapView to the ViewController.
The way to fix is really simple :
Had the code [RMMapView class]; just before the [mapView setDelegate:self];.
If I remember correctly, the compiler was not able to find a .xib file. Sorry don't remember exactly why I made this, but it works.
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.
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.