What's a reliable way to make an iOS app crash?

I want to test my app's crash reporting out in the field by deliberately having it crash when the user performs a particular action that a real user is unlikely to do accidentally.

But what's a good reliable way of making the app crash that doesn't create a warning at compile time?

Edit: Note that many seemingly obvious answers to this question result in exceptions that get caught by Cocoa and thus don't result in the app crashing.

in Objective-C use C directly to cause a bad access

strcpy(0, "bla");

Note: while this works on any system I know -- in a future version of the C runtime OR the compiler this might not lead to a crash anymore. see https://stackoverflow.com/questions/13651642/is-null-pointer-dereference-defined-behavior-in-objective-c)

(in swift you would have to bridge to objC to do this)

My current favourite:

assert(! "crashing on purpose to test <insert your reason here>");

A classic:

kill( getpid(), SIGABRT );

And some pr0n:

*(long*)0 = 0xB16B00B5;

All of them generate crashes captured by my crash reporting tool.

Since we all use Clang for iOS, this is fairly reliable:

__builtin_trap();

This has the benefit that it's designed for exactly this purpose, so it shouldn't generate any compiler warnings or errors.

How about a good old stack overflow :)

- (void)stackOverflow
{
    [self stackOverflow];
}

abort(); causes abnormal termination… That is a crash.

Most popular one - unrecognised selector crash:

NSObject *object = [[NSObject alloc] init];
[object performSelector:@selector(asfd)];

Make sure you don't have -asdf method implemented in that class haha

Or index beyond bound exception:

NSArray * array = [NSArray array];
[array objectAtIndex:5];

And of course kill( getpid(), SIGABRT );

I think in Swift you could easily throw a fatal error:

func foo() {
    fatalError("crash!")
}

It is actually even intended to use this feature in case something goes wrong in order to make the app crash.

To avoid an if statement in a special case, you could use precondition, too. It's similar to assert, makes thus the intention (if wanted) pretty clear and is not removed in the final release as assert. It is used like precondition(myBoolean, "This is a helpful error message for debugging.").

Send a message to a deallocated object

exit(0);

(must... type... 30 characters)

You can also raise an exception:

[NSException raise:NSInternalInconsistencyException
            format:@"I want to test app crashes!."];

Add a gesture recognizer to a view that recognizes a 10 finger tap (5 fingers for iPhone as 10 can get a bit crowded). The GR has a method attached to it that executes anyone of the previously mentioned surefire ways to get your app to crash. Most users are not going to lay 10 fingers down on your app, so you're safe from the general user accidentally causing the crash.

However you should be able to use something like Testflight or just deploying it to personal devices and test in the wild before ever submitting it to Apple. Having a forced crash could get your app rejected by Apple.

could try something like

NSArray* crashingArray = [NSArray arrayWithCapacity:1];
[crashingArray release];

should crash on an EXC_BAD_ACCESS (might need to release it a second time but normaly it should crash like this already)

I will go with:int raise(int sig);

To get more info >man raise

I would just kill the process normally:

kill(getpid(), SIGKILL);

So if you install a handler with signal you can also handle the crash, finishing to write opened files and these things.

I use

[self doesNotRecognizeSelector:_cmd]; 

When working with RubyMotion I use this:

    n=Pointer.new ('c', 1)
    n[1000] ='h'

Try this:

- (IBAction)Button:(id)sender
{
    NSArray *array = [NSArray new];
    NSLog(@"%@",[array objectAtIndex:8]);
}

a wrong NSLog statement will do it

NSLog(@"%@",1);