Not long ago, I released an app to the app store. I tested it using both the simulator and my iPhone 3GS (unfortunately I don't yet have an iPhone 4) - very few, if any crashes happened even after frequent use.
-
What's wrong:
Some of the reviews suggest that it is crashing on iPhone 4 (possibly on startup) - I have also noticed this with several of my other apps, which don't have very many downloads.
I have no way of debugging these crashes - but what possible reasons may there be for frequent crashing on specific devices (possibly just iPhone 4 - not definite though - although I would think it is tested with iPhone 4 when being reviewed)? My app uses no out of the ordinary frameworks or API methods, and very little memory when running. Is it possible that these crashes are occurring on Jailbroken devices? No iTunes connect crash reports as of yet.
-
TLDR: App crashes on specific devices, can't replicate it. No ideas where to start - Help?
-
Also: If anyone's feeling particularly generous and wanted to confirm whether or not it works on iPhone 4, then you could try my app (it's free) - app store link - I'd be very grateful! Otherwise any reason that specific devices may crash the app would be great, or anyone that's had a similar experience - I just don't even know where to start when I can't replicate the bug.
Ok, I tracked down your problem: :-)
It's the region settings that make it crash - use Germany and it will crash, use US and it will be fine. So looks like parsing problem.
This is the most stupid thing that ever happened to me. Yes, part of the issue is because of location of the device, but this is not the main cause.
If you are using NSDateFormatter some where in your app, that's where it crashes. For example in my case it was because 24hr and 12hr systems. In US format the default time format is in 12hr system with am & pm.
In my code I was trying to access the am and pm part of the string that I was getting from [formatter stringFromDate:date] and on device with 24hr system there was no such thing to access. so it would crash the app.
It was happening in non-US countries that the default format of the NSDate is other than 24hr system.
Make sure you define the format of the NSDateFormatter before trying to access any part of it.
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'm a bit of a newbie in iOS programming, and have recently tried out some stuff with AVAudioRecorder and AVAudioPlayer, and happend on some strange bugs.
Basicaly what happened was that my app bugged out so hard it broke my iPhones (iPhone 4) audio-recording capabilities. And I'm not just talking about my app not being able to record anymore, none of the apps I tried, such as "Vocie-memo" and recording a movie using the standard-camera-app, where not able to record audio (video for the camera worked fine) anymore.
The problem can only be resolved by restarting the iPhone.
Since I'm a newbie I don't know a lot about these things and if it happens frequently (One app bugging out causing problems for other apps) or if this is something I should report as a bug to Apple.
It was my understanding that the "sandbox" made sure that even though your app bugged out, this wouldn't affect others, but I may be wrong. So my question is: Does this happen often? should I report it?
((For those interested please ask for more info, but it basicaly has to do with sending prepareToPlay to the player but instead begin recording))
Thanks in advance!
Congratulations! You crashed the process that manages recording on iOS devices. You might want to file a radar in Apple's ancient bug report system detailing what happened, but Apple probably wouldn't let an app that does this onto the app store.
So, in conclusion: You don't really have to worry.
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
In my iPhone app, the application receives its data from a server in XML format and displays it in UILabel. The data coming from the server may contain £ sign. This sign is not encoded in any way - just passed as is in the XML string. The app takes this string and displays it in a UILabel.
This works just fine most of the times. It always works fine in a simulator, including iOS 5.1, however one of the users reported a bug indicating that instead of display the £, the UILabel actually shows £ - which is most bizzare.
The UILabel text is set with this simple line of code:
contentLabel.text = [node getValueForKey:keyName];
I have stepped through the code with debugger and can see that the correct string value is being passed and set. I can also see correct results on the simulator.
However (as can be seen from the image below) something going amiss on this user's phone. Is there something I am missing? What could be the problem here? And, more importantly, how can I solve this? The things are complicated by the fact that everything works fine on my phone and simulator and this user is across the country from me, so I can't get physical access to their phone.
Here's the screenshot from the simulator:
And here's the screenshot from the affected user's phone:
What library are you using to parse the XML?
Try sending the user a new build over email with copious NSLogging enabled (maybe even use testflight, its brilliant - lets you see all your logs over the air as they come in) to see where the problem crops up.
Are they on a different iOS version to the simulator you were testing with? Does the problem occur all the time with their iPhone. What about your own iOS device, does it never occur?
Sorry for all the random advice, I'm just chucking stuff out there in the case that one of them fixes it.
If they're running the same app version, same device (real iPhone not simulator) and same iOS version as you I have no idea what the problem is or could be.
If you're feeling lazy (and I reccomend NOT doing this, its quite hacky) you could always use:
finalString = [firstString stringByReplacingOccurancesOfString:#"£" withString:#"£"];
The problem seems to have solved itself on its own. I couldn't reproduce it on either iOS 4 or iOS 5, nor could several other users I spoke with. Upon checking with the user who initially reported the problem, she said that after upgrading iOS from 5.1 to 5.1.1, the problem went away. Oh well... :)
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.