We've just released an app using the Crittercism framework. After some time, we've had about 125K app loads, and 95 crashes - a rate of less than 0.08%.
One crash happened 19 times, another 10, but the other 41 all occurred 3 or less. If there were any major problems with the app, I would expect to see significantly more failures in particular areas, so I'm happy with the level of figures I'm seeing.
A quick look shows many of them to be low level failures, not obviously caused but programmer error.
Examples
The largest group are all to do with CFNetworking on a background thread while static HTML is being being rendered in a web view on the main thread.
There are some KVO failures in free_list_checksum_botch
But my question is, in a sufficiently complex OS (iOS in this case), with a sufficiently complex app (which I think it is), should I, as a developer, expect to see this level of "background noise"?
Should I expect to see one app crash per 1-2000 loads, just because the OS isn't perfect? Has anyone else had a similar experience?
(I'm not looking for solutions to the errors themselves.. thanks!)
Crittercism conducted an analysis on app crashes. Their report was based on Android vs iOS crashes.
They concluded that the most popular apps on iOS crash 0.51% of app launches. So #Ashley Mills, if you're getting 0.08%... you're doing well. (i think I have my figures correct, anyway).
Not sure where the original report is, but I read it here:
Forbes app crash rates, conducted by Crittercism
Actually another shot in the dark non-technical answer could be. What added value will it bring you (the developer) to keep digging into that particular issue, when you could be spending more time and effort either developing more capability within your tool, or another tool completely.
If your app is simply for fun and learning, then I could see digging into this issue as a fun adventure. From a business perspective, what is your time worth and is figuring out this 0.08% problem going to sell enough (more) copies to make your efforts worth it.
An analogous would be, what requirements are essential, and what requirements are desirements?
Just food for thought. I know many of the companies I have worked for don't see the value in stressing about that low of a yielding bug.
I am an iOS developer, employed professionally. I take it personally when my apps crash, because that is not the user experience I was aiming for. A crash is a bad user experience. One crash, per user, is too many. A crash is a bug.
That being said, I have definitely seen crash logs that appear to be unsolvable because they seem to be indicating a problem way down deep in the SDK. What I have learned, however, is that more than likely there is something about my own code that is ultimately the cause.
There are any number of bizarre crashes that can be caused by timing issues between threads or blocks or just because I did something wrong. Just recently I discovered I was doing something entirely wrong with respect to a complex table I was updating. The crash logs for this problem provided almost no clues except for the general area of code I might look at. As I dug into the code and started experimenting, I realized my mistake, which ultimately was a timing issue caused by what I thought was a clever separation of main-thread vs. non-main-thread activity. I was too clever for my own good, in this case. :-)
So, to sum up:
One crash is too many crashes and ultimately a bad user experience.
Often, bizarre low-level crashes are the result of your own code's complexity and possibly timing issues there in.
Finally, I offer this question to consider:
Are you willing to piss off or dismiss some of your users simply because they fall into the 0.08% of users experiencing crashes?
Food for thought. :-)
I'm a professional iPhone developer, and what I've seen is the crash frequency isn't what upsets users, it's the funnel for how the crashes happen.
If they are intermittent you are usually okay, the problem starts to occur when one user experiences a specific crash multiple times. This is unacceptable.
Striving to remove every crash is always a good thing, but in many cases it's simply not realistic, you have to decide where your time is best spent. If you have the opportunity to rework a portion of the UX flow or fix an intermittent crash, you need to decide which one benefits more users.
The important thing to remember is, if you choose not to fix a crash that happens 0.08% of the time, you aren't writing off the users experiencing it unless they are experiencing it multiple times.
Although not a technical answer, on my iPhone I'd personally expect to have an app I use a lot crash at least once or twice over a year. I'd say that level is perfectly acceptable, and since generally I find they crash a lot more on the first time you start it I believe it's something to be expected.
Related
There are many application in app store that they force users to vote 5 stars to unlock the content. That's forbidden by Apple but they don't care about it. I have at least 4-5 competitors which build very poor app but have more than thousand forced reviews.
Suprising thing is that even people complain about they are being forced in their reviews, Apple is not doing anything about that and those apps are in top 10 in their categories for more than a year. That's dissapointing and not fair!
Should we wear the black hat and do similar tricks to compete?
I don't suggest you using the same bad practice than your competitors, obviously it cause you to be down the research when user look for your product. To avoid that kind of situation, Apple offer this website
I've never use it before so I can't tell how effective it is.
After some more research, this website seems to be what you are looking for
It's an absolutely unfair competition you're facing but as long as user won't complain or report to Apple those kind of situation, they won't do anything I guess.
Or maybe now users are OK with this kind of situation so it would mean that the rating system of the AppStore might be re-think in a better way.
Anyway you have only few options in your situation but reporting those app.
Since I've never seen similar situation in an app, may I ask what kind of app it is ?
I am currently using Crashlytics in my app and it's working well. However, we are thinking of using NewRelic on the backend to better be able to pinpoint issues in our platform. The NewRelic mobile library has a crash reporter built into it as well (that can be opted out of).
I am assuming you don't want to use two crash reporters considering one will trump the other, however, I haven't seen any information on this anywhere and would just like to confirm.
Additionally if you could explain why along with the answer that would be very helpful.
You can only have one signal handler installed. The last one that registers "wins".
I've integrated a libPd patch in iOS.
When entering a text field, and presenting the keyboard there's some crackling sounds.
How would I go about debugging this?
NB I've tagged this question with Objective-C and iOS, however this question may require knowledge in all four tags - libPd and Pure Data well:
What is Pure Data
Pure Data is a powerful programming language for the manipulating of audio from core mathematical concepts. It's widely used games as well as DJ and other music focused applications. Some example apps that are built with Pure Data and libPd are: The Rj Voyager app from RjDj and the Inception App from Warner Brothers.
libPD is a method of embedding Pure Data patches (developed using the visual interface) within an iOS app. Controlling the Pd interface is done via a publish/subscribe message interface similar to OSC or MIDI. .
The GitHub page for libPd is here: https://github.com/libpd
What help am I looking for?
I'm not sure where to start debugging this. Someone who has integrated and used libPd on iOS could surely share experience. It could be related to the following:
How threading works, and how it interacts with the main queue
What sample rates work best given the target devices
What debugging tools are available.
Other advice earned through deep experience.
I don't know anything about PD, but it seems likely that the presentation of the keyboard is causing you to be CPU-starved for some reason. You might try:
verifying this still happens when in release and not attached to a debugger (log messages cause long delays when attached to the debugger, which alone can cause hiccups like this)
profiling your code using Instruments to see if you're inadvertently using a whole lot of CPU at once or
increasing buffer sizes so PD doesn't need CPU as often.
I was experiencing the same symptoms in an app I'm working on. I did manage to ascertain a couple of things early on. My recent changes involved sending alot of messages to pd during app init. I noticed when debugging that when I reduced the amount of messages sent, the sound improved. Also, I didn't see this in the simulator, only on the device.
The libpd example PolyPatch was pretty useful in this case, if you increase the amount of patches that can be generated. I found that the sound was breaking up with many patches open, in exactly the same way as in my app. This is quite simply where the overhead of using libpd takes its toll on performance. What's also clear is that simplifying a patch (so it contains less objects) impacts performance. But by far the biggest hit is creating a new, separate patch. So you won't want to be creating huge numbers of patches. Debugging does of course take a toll too.
44.1khz works pretty much everywhere as far as sample rates go (it's the pd standard too). And there's nothing to stop you debugging the libpd code right there in xcode, i've done that a few times. Other than that, there is the issue of debugging patches. You can either set up your patch with test versions of your objects directly in pd, or you should be able to set up libpd to view the same output as you would normally see in pd's main window in the console (you just need to make sure that you have something like this
[PdBase setDelegate:_dispatcher];
in your code - it's all in the dox of course). Then you just pepper your patch with print messages as required...
Hope it helps, and is still relevant after 3 mths...!
I got an EXC_BAD_ACCESS in my iOS program, and I suspect that the cause is in one of my anonymous blocks, but there are quite a few of those, and I need to narrow down the candidate list a bit.
The stack trace shows the current frame as __lldb_unnamed_function4866$$ProjectName. There are no line numbers or source file names that I can see. No local variables visible either. The debugger shows machine code instructions. This was running on a background event queue, so there is none of my code anywhere else on the stack.
How do I go about finding out what function this is?
I came across a similar situation, and while I can't help (yet) with your problem, I think I know a man who can.
Check out http://www.realmacsoftware.com/blog/block-debugging, for an exposition of how to find out a lot more about the evil block in question.
It doesn't help me much, because I'm working from a crash log, but if you're still interested, this is going to give you just about as much as you can get about the unnamed block.
Warning, the above link exposes you to a lot of arcane knowledge, and may make you feel a little inadequate :)
[Editted to add]
Not good enough yet?
After searching through disassembly and doing some manual symbolication, I came to the conclusion that the ___lldb_unnamed_function is a red herring.
I followed How to manually symbolicate a crash log with atos, and it pointed the finger at a completely different function, which came from a 3rd party library, and was a very good candidate for the crash reason (killed by angry watchdog with badf00d.)
In the course of this enquiry, I also came across hopper, a great disassembler; I used the demo version to confirm what the suspicious code was doing, so I'm giving them a namecheck.
Try to set an exception breakpoint by clicking on the plus symbol within the breakpoint navigator cmd + 6.
For getting an overview of debugging best practices if found it useful to consider a Stanford Lecture on iTunes U
Is it possible to make app not launchable if it has been cracked and installed from installous? I don't want to see my app in installous
It's not that easy and it not answerable within some words or code snippets.
But you might check this:
http://www.shmoopi.net/ios-anti-piracy/iphone-piracy-protection-code-tutorial-2/
http://www.cocos2d-iphone.org/forum/topic/7667
http://thwart-ipa-cracks.blogspot.com/2008/11/detection.html
The read also here:
http://www.learn-cocos2d.com/2010/05/ignore-everything-youve-heard-about-app-store-piracy/
There are ways to detect whether your app is running on a jailbreaked device or whether your app has been modified (aka cracked). Take a look here and here for example.
From my point of view all you are getting by using these methods is a waste of time. Maybe you can make it harder for potential crackers and keep away the script kiddies. But you won't get that far that no talented cracker on earth would be unable to crack your app. Even one single cracker on earth who's able and motivated to crack your app is enough to upload it to hundred's of sites.
If really big companies fail at protecting their apps I really doubt that you will achieve it... so: wasted time which should be better spend on improving your app.
Probably not, because the part of cracking your application is to remove all restrictions (registration, detection of jailbreak, ...).