What's the logic behind it? Ive been told by multiple apps to do this.
I've also noticed that if I reinstall/build the app too many times from xcode, it will become unstable and more likely to crash. A restart does fix the problems.
What's the logic behind it? Ive been
told by multiple apps to do this.
What apps? I haven't seen this yet myself, but I would guess that, if true, it might have something to do with the multitasking in iOS 4.0 and apps maybe not being quit if already running before an update. But it's strange.
I've also noticed that if I
reinstall/build the app too many times
from xcode, it will become unstable
and more likely to crash. A restart
does fix the problems.
Really, this sounds like a bit of folk science. Occasionally, a device can go a bit whacko, but that used to happen to me in (say) the days of 2.2.1. So if you can honestly reproduce this issue, I strongly encourage you to file a bug with Apple and get it fixed. Note they will probably ask you for a reproducible sample project in order to prove out this theory.
Related
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.
I am going to launch my app on the AppStore and I would like to keep track of crashes and fix them as soon as possible. If possible, it would be nice to collect also some additional information about user activity and other useful stuff.
In order to do so, I have looked for some crash reporting tools and the most interesting ones I have found are: TestFlight Live, QuincyKit and Crashlytics.
Among those three, QuincyKit should be the lightest one but the other two seem to be quite interesting since they provide more sophisticated reports and other interesting stuff.
My goal is to have as many information as I can on any issue the user can experience, but at the same time I don't want to make the app slower or consume more resources.
In your opinion and from your personal experience, which of these tools is the best one (taking into account my goal and my needs)?
By using TestFlight Live or Crashlytics I would make my app too slow?
Is there a risk to overload the device?
Reports provided by QuincyKit are precise enough? How many information can I retrieve from them?
Thanks!
Here is what I decided:
I am using Crashlytics for crash reporting (yes, it seems to be really great) and TestFlight for tracking user activity (checkpoints are really useful to find out what users generally do and figure out what the tendency is).
I followed the instructions written here
I honestly think Crashlytics is a better solution than Testflight for crash reporting.
Here's what you get with Crashlytics that you don't get with the others.
Duplicate culling (TF does this too, but its not too great at it, Crashlytics is damned near perfect)
You can actually mark crashes as closed/resolved, and get them out of your list for a given version.
Crashlytics does everything TF's Crash reporting does, but better and then some (logging, stack traces, etc.)
Percentage of affected users, and the numbers that go with that. (ie: should i fix the bug that happened to one guy, or the one that's happening to 10k?) Testflight doesn't tell you this.
Prioritization based on occurrence. This is probably the most important gain in my opinion.
These are just a few, but I figure they're probably the most important ones for you.
We used Testflight's crash reporting for close to 2 years on an extremely popular app (several million D/Ls). Its definitely better than nothing, and very convenient if you're using TF for distribution as well, however you get many more benefits from Crashlytics. We switched to Crashlytics this summer and now we're actually able to manage crashes and make smart decisions about what to fix and when, instead of just sifting through a giant never ending list.
I see you already accepted an answer, but I'd seriously give it another look even if you opt to continue with Testflight. I've found its hard to really grasp what you're missing until your app has shipped, at which point is even harder to change.
Crashlytics is second to none for crash reporting.
We were in the same boat as you trying to find the best crash reporting solution. After some thorough investigation and test runs of TestFlight, HockeyApp, and Crashlytics, we originally chose HockeyApp because they allowed us beta distribution along with crash reporting on both iOS and Android (we wanted both in one solution for both platforms). However, HockeyApp's exception backtracing was just not giving us any additional crash details. This is where Crashlytics shines. Their exception backtracing is amazing. Period.
So here's my summary of all 3 SDKs:
Crashlytics
#1 crash reporting
#1 exception backtracing, bar none (provides very useful extra crash details)
Extremely fast and lightweight
Custom key logging for additional crash context
Best duplicate crash recognition and culling
Automatic SDK updates (Their Mac app automatically updates the Crashlytics iOS SDK in your project)
No beta distribution (I'd love a one stop solution for crash reporting and beta distribution)
Automatic build server support
TestFlight
Somewhat heavy, and adds bloat to your app package
Great beta distribution
No Android support (at least when we tested back 6+ months ago)
HockeyApp (HockeyKit - Beta distribution, QuincyKit - Crash reporting)
Lightweight
Crash reporting UI a bit confusing
Exception backtracing severely limited (at least when we tested in March of 2011)
Very good beta distribution
All that said, we chose Crashlytics for crash reporting, and HockeyApp for beta distribution. But you must chose what works best for your needs.
Definitely recommend Crashlytics as well.
TestFlight Live has given me issues in the past. It seems every time I go to use TestFlight, it is down anyway.
Crashlytics is awesome. Here's why:
Adding it to your project couldn't be easier. There is a Mac app that does most of the hard work for you.
Automatically updates itself
Prioritizes crashes for you
Provides handy stats like OS and device percentages as well as average memory available, etc
I use Crashlytics in all of my applications. I added it to Hipstamatic when I was there and the data we got was shocking. It really helped improve our product. I also tried TestFlight Live and quickly removed it after the first beta since it was causing crashes.
Crashlytics is awesome. You should use it.
If we're only talking about crash reporting, Crashlytics is far better than TestFlight. (Never tried QuincyKit, so I can't compare the 3 options)
We've been using Crashlytics for over a year on Weddar and it has been great. Having tried other solutions before I have to say that before installing it I was kind of suspicious of the great features they were stating, but the installation was indeed done in about 5 minutes and it only added around 40-45Kb to the app.
The crash reports are incredibly detailed making it really fast to pinpoint solutions for the bugs and the updates to the sdk are pretty steady and stable. The team is incredibly supportive too. I remember that we had a problem with the new ARM7s when iPhone5 came out and they solved it in about 30 minutes.
I use TestFlight for user beta testing management so I've tried TestFlight Live SDK in the summer just to see if it was a solution to have all integrated in one service, but we had a really bad experience with it. I had 2 updates rejected in the App Store Approval for the first time (Weddar was launched in April 2011) and we lost about a month trying to catch the bug. When LIVE beta testing, no user would complain about any problem, we "solved" it by removing the TF SDK. Never quite understood what was the problem. We contacted TestFlight team and never had contact back. (Another big big detail is that TF SDK added about 800Kb to our app.)
So, even if I still use TestFLight for beta testing, if you're looking for a great and lightweight crash reporting SDK, I definitely say that you should use Crashlytics.
Hope this helps.
I'd say go with TestFlight (Live)
In my experience the TestFlight SDK won't crash/slow-down your device and has very versatile crash reporting - allowing you to debug reported errors fairly accurately.
TestFlight also doubles-up as a feedback package for when you're testing in-development.
It's also a pretty light SDK.
To be more specific (in answering your list of questions):
TestFlight allows you to scalp for user 'checkpoints' and has its own version of NSLog that allows you to dynamically log events at runtime.
Your app wouldn't slow down as network requests are handled off the main thread.
I don't understand why a device would get overloaded by using either of the SDKs you've mentioned.
QuincyKit reports seem reasonably precise, however you need to make up your own mind about the precision you need - you can find QuincyKit docs here.
I have noticed that when performing native debugging on Xcode 4 if I have my app installed, then delete the app, then attempt to debug again from Xcode 4, the time it takes to perform the step "Transferring package" is pathologically slow. Has anyone else experienced this? I dread deleting the app as it will take 20-30 minutes to load the app.
Our app has lots of user files that get deleted when app is deleted. Perhaps some sort of sync-like process is running at same time. Killing Xcode 4 does not fix the issue.
I think now you must use Xcode 6.3 and it will allow you to do everything in easiest way. Here this version of Xcode is most stable version I have worked with for last few years.
I would like to offer some general guidance on this as the symptom you see can have many causes. In fact most versions of Xcode have had these symptoms for differing reasons in my experience.
I've seen the slow transfer problem before (Xcode 4 I think), when I switched my app to be an app that could run in the background. To get around that, I would either force kill the app from the phone itself, or I would change the bundle id of the app when deploying it (as a hack).
68cherries commented on seeing the problem after profiling. Doing profiling of a device generates a lot of data on your Mac, and perhaps also on the device but I don't know. So its worth switching phones with another phone, ideally one that has a lot of free space; does the problem follow the phone?
Sometimes deploying has a problem when resources are missing; resources are rebuilt upon clean. Try pressing the option button and then doing a clean - it cleans intermediate files. (option-shift-command-k). This can happen in particular when you delete a resource but still reference it from a story board. Going through the story board looking for exclamation mark warnings is helpful (particularly with Apple Watch apps).
Periodically it is worth doing a resource file audit. Quite often we deploy files not actually needed by the target device. For example, bash script files, old icons, etc. The fewer resources, the fewer things that can be incorrect, and can often trigger an idea about what has changed with your resources that might explain the problem. It also makes the deployment smaller for your customers.
Note with this problem its worth debugging it from both sides. For example, look at your Mac console logs to see any errors, or your activity monitor for unexpected behaviours and tasks. On the device side, its worth installing iOS console from lemonjar.com to see if anything got to the device end and if there were errors there.
I have an iPhone app that's been in development for about 2 weeks. We recently tried the "release" version of the build on a device, and to our great unhappiness, it crashes in one of the views with an "EXC_BAD_ACCESS".
This crash only occurs on devices, and only in the "release" build. Not only that, but it only happens the first time the app is launched! It is also 100% reproducible.
We have removed the small block of code that deals with data persistence, and have tried re-openning Xcode, cleaning the project, deleting and reinstalling the app, etc., as some other questions suggest.
Do you have any advice for a) what might be causing this problem, and b) how to go about debugging if it only happens in "release"?
Thanks
It turns out there was no problem in the code at all.
The reason it was crashing was that Xcode was trying to attach the debugger to the release build for some reason! We are still trying to figure out why, because we have checked the most obvious places, but I'm sure it won't be too hard to track down.
The build works fine if you install from iTunes or the Xcode organizer instead of building and running from Xcode directly, so it won't affect your end-users at all, as long as you are careful to check for other first-run issues.
We can only guess what the cause might but if it's 100% reproducible, then it should be a good candidate for some fprintf-style debugging.
Figure out the most probable place for the error to occur, and start putting "Got past xxx view initialization" style statements in to start narrowing the problem. It's tedious, but eventually, you'll get there.
In theory fprintf statements could affect the problem. However, it's rare that it does so, so it's a good place to start.
Something really weird is going on with Xcode and an iPhone project I'm working on, when I'm building for the simulator, the project has 2 active executables (MyApp - iPhone Simulator (2.0) and MyApp - iPhone Simulator (2.1)) Almost all of the time, I want to use the the 2.1 active executable, but Xcode will occasionally silently change to the 2.0 one.
There doesn't seem to be any pattern to this or any trigger that I can notice. Googling has found a couple of people out there who are having the same problem, but no solutions.
Help me stackoverflow-kenobi! You're my only hope!
Ok, it was a bug. The good news: it's fixed in the fresh new 2.2 SDK.
That is weird -- I've been doing iPhone/XCode development for a while, now, and never seen anything like that.
Are you absolutely certain that you're not poking around some place that's causing the change?
Might you have a corrupt XCode or .xcodeproj? If it persists, I'd try re-creating my project and, if that didn't help, reinstalling XCode.
Very strange, indeed...!
I have the same problem. I need to set the active Executable to 2.1 for openAL to work. The pattern I observed is that it switches back everytime I switch to export to the device. Isn't that what happens with you?
I've seen the issue commented a couple of times on the official iphone dev forum, but no solutions. Looks like a bug.
So.. why are you actually doing that? It is probably better, given the nature of the iPhone (with multiple frameworks for multiple architectures), to set up different Targets for your various projects. The executable produced will be the result of the build phases for your targets.