A bricked device is a device that does not work. The direct metaphorical meaning is that the device is permanently damaged (making it as useless as a brick), but people use the term "bricked" for non-working conditions which range from easy to fix (such as a failed update) to impossible to fix (such as damaged baseband memory). A phone may be called "bricked" if it will not boot, will not respond to input, will not make calls, etc.
Difficulty of bricking an iOS device
Using a jailbreaking tool cannot put a device into an unusable state on its own - if something goes wrong while jailbreaking, putting the device into DFU Mode will allow you to restore it via iTunes. Installing software via Cydia also cannot cause an unrecoverable state (unless very specifically designed to do so by a malicious person, which has not been seen "in the wild"). Other than that specific exception, if something goes wrong, DFU mode will still work.
Types of "bricking" that can be easily fixed (not really "bricking")
Installing stock iOS on a device with a preserved baseband
Early unlock solutions could result in unusable (but recoverable) phones after installing an iOS update if you didn't take special steps. For people who used redsn0w to install the iPad baseband (06.15.00) on a compatible iPhone 3G or iPhone 3GS so that they could use ultrasn0w to carrier unlock it, upgrading or restoring iOS using "stock" (normal) IPSWs would make the phone unusable - until you made and restored a "custom" IPSW without a baseband update (instructions [Archived 2013-10-31 at the Wayback Machine]), and then reinstalled the iPad baseband using redsn0w. Avoiding doing a stock upgrade/restore (upgrading or restoring iOS using a "custom" IPSW) avoided this problem.
Intentionally modifying key parts of iOS: changing NVRAM variables to invalid values
In February 2015, researchers released information about how to change an nvram variable called
DClr_override. If this is changed to an invalid value for the device (valid values are not the same on all devices), and the device is rebooted, the device will not be able to boot. iOS 8.3 beta 4 (released in March 2015) removes the DClr_override variable, and later iOS versions will probably omit it as well. This means that restoring a device to iOS 8.3 beta 4 (or later) will fix the device, rendering it bootable once again.
Wiping the iBoot Partition
If you wipe the iBoot Partition, It will render the device unbootable. An easy way to do this is flash an Internal UI Build and go to Settings/Internal Settings/CoreOS and press "Brick Device". This will wipe the iBoot Partition, along with the firmware. This is recoverable by restoring the device, as the device will be in DFU mode.
Types of bricking that may be hard to fix
Signed System Volume restore bug
Signed System Volume, enforced starting from iOS 15.0, albeit introduced earlier, protects a modified system volume from being booted. Prior releases of iOS protected against system volume modification by simply mounting it as read-only. This was easily counteracted by jailbreaks by remounting it as read-write. With the introduction of SSV, remounting read-write and then proceeding to modify the volume will cause the system to no longer be bootable, because it will no longer match the expected hash. This is the intended behavior. However, this behavior also takes effect within the restore ramdisk on A12 and later devices, rendering it impossible to unbrick the device. This doesn't seem to make sense - by definition, SSV is only protecting the device from booting into a modified volume, but a restore is supposed to format the device's storage and restore it to a known, secure state.
An A12 or later device bricked in this way cannot be recovered until Apple releases a signed firmware with the bug resolved. It is unclear whether this is intended behavior or a bug, and it remains unresolved as of at least iOS 16.3.1. SSV is only implemented on iOS/iPadOS and macOS, and does not affect other variants of *OS. This does not appear to be a problem on A11 and earlier devices.
Changing MAC address to invalid address
If you change your device's MAC address to something invalid (for example if you're attempting to change your UDID), your internet won't work again until you fix the MAC address (using MobileTerminal or similar). This persists even if you restore -- so you can make this really really hard to fix if you restore and there's no jailbreak available, if the available jailbreaks don't include afc2 and other workarounds aren't working, etc. Here's a JailbreakQA thread about this [Archived 2014-08-07 at the Wayback Machine] and another one [Archived 2014-09-01 at the Wayback Machine].
Intentionally modifying key parts of iOS: other ways
- Erase SysCfg/replace it with 0xFFs.
- Destroy the 'SrNm' tag in the SysCfg, it won't activate then.
- Set all clock gates enabled and set PLL frequencies to mad numbers, THIS WILL DAMAGE THE HARDWARE.
- Run constant NAND stress tests to wear out NAND pages.
- Set the 'display-timing' nvram variable to some other garbage. iPod touch (2nd generation)/(3rd generation) does weird things with that.
If you know how the hardware works, this can be done from an iBoot/kernel level.
Making the wrong modifications to the baseband
One way to irreversibly brick a device in software is to flash an invalid baseband bootloader, provided it has a baseband. Most other bad flash scenarios are recoverable some way or another.
Another way to brick the baseband is by installing baseband 06.15.00 on an incompatible device. redsn0w has an option to install this baseband on the iPhone 3G or iPhone 3GS in order to get a baseband version that is unlockable with ultrasn0w. This is a nice way to get an unlock, because the iPad, the iPhone 3G and the iPhone 3GS all share the same Baseband Device, but the iPad has a newer version number in its baseband. That way people can actually downgrade by installing a higher version (there are no APTicket checks in these devices). This has known side effects, like losing GPS functionality (this baseband comes from an iPad, which has a different GPS module).
It was possible to brick an iPhone 3GS with this method. In fall 2011, Apple replaced the NOR flash, which rendered the aforementioned 06.15.00 trick useless. The previous type of NOR was marked 36MY1EE, and they switched to 36MY1EG and 36MY1EH. These new NOR flash chips seem to work with the newer baseband versions in the iPhone 3GS, but are not supported with the old 06.15.00 baseband. Therefore installing this version will brick your device if you have a newer NOR flash, as you (currently) cannot go back and install anything else. To check before installation, you can try checking the serial number, which reveals the production year/week in the first 3-5 digits. 2011 week 34 appears safe, while weeks 35 and 36 seem iffy, and week 37 is not safe. Ultimately, the most sure-fire way would be to open the device and check the chip type.
Changing the system time to the Unix epoch
Setting the system time to the Unix epoch (1 January 1970) and attempting to reboot the device almost irreversibly bricks it. Normally, without a jailbreak, setting the time like this isn't possible with the Settings app, although it used to be possible before iOS 9.3.1. However, as the root user or with the com.apple.timed key set to "YES" in an executable's entitlements, using the settimeofday() system call in unsandboxed software allows the system time to be changed to the Unix epoch by setting tv_sec and tv_usec in a timeval struct (which is passed as the first argument) to 0. When the device attempts to boot with the time set, it will fail to boot. This cannot be fixed normally with Recovery Mode or DFU Mode. Disconnecting and then reconnecting the battery resets the time which fixes this. Another way to fix this, is by waiting for the battery to fully deplete, which also resets the time.