A jailbroken device allows apps to do things that a non-jailbroken device does not.

I maintain my company's in-house mobile app crash reporting system and I had to remove jailbreak checks from our iOS SDK. It turned out that some of the checks were causing crashes themselves due to buggy anti-jailbreak-detection code some jailbroken devices had in place. e.g. checking whether a file could be accessed that normally iOS disallows would end up causing a crash instead of just a permission error.

Instead, I just do some basic server-side detection. Basically, looking for libraries loaded into the app (e.g. cydia) that are only present on jailbroken devices. Some jailbreaks don't even try to hide their presence.

I don't know what iVerify does. I hadn't heard of it before. I'm curious how it avoids crashes though... perhaps it avoids invoking any dynamic system calls.

The proper way of doing things should be that an app controls access to jailbreak features. By default nothing gets them and you can whitelist the ones which need it. I'm not sure if anything like this exists for ios but it should.

Depending on how much access you have, it's always possible for jailbreaks to hide their presence from applications (which are running at a lower privilege level). There are a couple of "jailbreak hider" implementations out there.

They also get tripped up by Apple internal devices, which as an Apple employee is quite annoying when I get locked out of a financial app.

I feel like Apple employees shouldn't be using special iPhones for personal use (out of good engineering practice; nothing special.

Who else would be the best to test new phones, software and features, and understand how they may create bugs with 3rd party apps?

In fact it’s critical to do so.

If that's your goal, shouldn't you be using a customer install?

Out of interest, why do you care if your users run your application on a jailbroken device? It’s been a question I’ve had for a while..

We don’t care but when a crash occurs we collect diagnostic data that we think will help us narrow down the source of the crash. Sometimes a crash happens only on jailbroken devices in which case we usually don’t spend time on it.

Same reason as why rooted Android devices get blocked by certain applications. Security for the user's sake. Usually it's financial applications (banking etc.) and stuff with sensitive user information.

As an Android user, this is super annoying: I rooted the device because I want to control it. Now some stupid app comes along and claims that, for my own protection (supposedly), they're going to break for me. It's insulting, really.

Jailbroken devices can attack application logic to cheat in multiplayer games, somewhat attack DRM systems for video content (though Fairplay isn't especially vulnerable here), gain access to chargeable features without paying for them (decompiled Spotify APKs that do not feature advertising without having to pay exist on Android and are a non-trivial revenue risk) etc etc.

In more open systems you are usually more able to run detection software for the above without sandboxing.

Piracy for Android doesn't require a jailbroken/rooted device.

It only requires one jailbroken device on iOS. Or, if you're using the right tools, none.

Companies (particularly financial institutions) that have enterprise apps deployed only to their employees care because a jailbroken phone imposes the risk of attackers MITMing traffic.

We discovered/developed a suite of side channels that let us indirectly read iOS system state from inside the sandbox. There are many different checks across unknown deviations, known jailbreak files and utilities, and runtime behaviors that help us narrow down whether your phone has been modified. It's not perfect, but it's the best you can do from within the Apple App sandbox.

I assume you make a new mach-o file that hasn't been signed by apple and try to exec into it. If it runs, definitely jailbroken. Obviously a jailbroken phone could load a kernel module that detects this and stops it from running in this specific case, leading to a cat and mouse game between jailbreak developers and these apps. iBooks tried this once.

Couldn’t tell you, I know as much as that article says. But I’m guessing that’s part of their secret sauce

I'm sure it's some combination of checking for files that shouldn't be accessible or exist, searching your own address space for things that shouldn't be there, and verifying that kernel calls produce the results that they should.