Kernel

The kernel of iOS is the XNU kernel.

Pre-2.0, it was vulnerable to the Ramdisk Hack and may still be, but iBoot doesn't allow boot-args to be passed anymore. It is mapped to memory at 0x80000000, forcing a 2/2GB address separation, similar to Windows 32-bit model. On older iOS versions the separation was 3/1 (mapping the kernel at 0xC0000000), closer to the Linux model.

Note, that this is NOT like 32-bit versions of macOS, wherein the kernel resides in its own address space, but more like 64-bit versions, wherein CR3 is shared (albeit an address space larger by several orders of magnitude). See the appropriate section.

On production and development devices, the kernel is always stored as a statically linked cache stored at /System/Library/Caches/com.apple.kernelcaches/kernelcache that is decompressed and run on startup.

Stack
The kernel maintains thread specific stacks by calling kernel_memory_allocate, this allocates stacks in the specified kalloc zone. The bootstrap thread has its own specific static kernel stack, which is specified by _intstack. IRQ and FIQ handlers will also have their own execution stack which is specified by _irqstack.

ASLR
As of iOS 6, the kernel is subject to ASLR, much akin to Mountain Lion (OS X 10.8). This makes exploitation harder as the location of kernel code cannot be known.

Boot-Args
Like its macOS counterpart, iOS's XNU accepts command line arguments (though the actual passing of arguments is done by iBoot, which as of late refuses to do so). Arguments may be directed at the kernel proper, or any one of the many KExts (discussed below). The arguments of the kernel are largely the same as those of macOS.

Kexts use boot-args as well, as can be seen when disassembly by calls to PE_parse_boot_argn (usually exported, _PE_parse_boot_argn 8027A8EC on the iOS 6.1.3 kernel, discovered by Haifisch). Finding references (using IDA) reveals hundreds places in the code wherein arguments are parsed in modules, pertaining to Flash, HDMI, and AMFI.

The list of boot-args can be extracted from any kernel dump once the address of _PE_parse_boot_argn is determined (which is usually automatically). A list from iOS 8.4 is shown below:

-b -disable_atm -factory_debug -l -multiq-deep-drain -no-zp -no64exec -novfscache -oldmezname -panic_on_exception_triage -progress -qos-policy-allow -s -vm16k -vnode_cache_defeat -x -zc -zinfop -zp aks_default_class assert bg_preempt boot-uuid colors cpumon_ustackshots_trigger_pct darkwake dart dcc debug diag disable_exc_resource fill hwm_user_cores ifa_debug ifnet_debug imp_interactive_receiver inaddr_nhash initmcl interrupt_accounting io io_throttle_period_tier1 io_throttle_period_tier2 io_throttle_period_tier3 io_throttle_window_tier1 io_throttle_window_tier2 io_throttle_window_tier3 iosched iotrace jcon jtag keepsyms kernel_stack_pages kextlog kmapoff lcks lo_txstart longterm max_cpumon_interval max_cpumon_percentage max_task_pmem maxmem maxoffset mbuf_debug mbuf_pool mcache_flags mleak_sample_factor mseg msgbuf mtxspin multiq_drain_band_limit multiq_drain_depth_limit multiq_drain_urgent_first nbuf ncl net.inet.ip.scopedroute net.inet6.ip6.scopedroute net_affinity net_rtref net_rxpoll network-type panic_on_cs_killed preempt qos_override_mode rd rootdev rte_debug sched sched_decay_penalty sched_decay_usage_age_factor sched_pri_decay_limit sched_use_combined_fgbg_decay serial serverperfmode slto_us socket_debug task_policy_suppression_disable task_wakeups_monitor_interval task_wakeups_monitor_rate task_wakeups_monitor_ustackshots_trigger_pct tbi trace trace_panic trace_typefilter trace_wake unrestrict_coalition_syscalls vm_compression_limit vm_compressor vm_compressor_immediate vm_compressor_threads wfi wqsize zalloc_debug zlog zp-factor zp-scale zrecs zsize
 * 1) perform a full disassembly, isolate decompiled lines (^;) with PE_parse.. and isolate string between quotes, sorted uniquely:
 * 2) morpheus@Zephyr (~)$ jtool -d __TEXT.__text kernel.8.4.dump | grep PE_parse |grep '^; '| cut -d\" -f2 | cut -d\" -f1 | sort -u

Versions
In the beginning iOS had consistently maintained a fairly higher kernel version than the corresponding version of macOS. Over time, iOS and macOS have "moved nearer" together; OS X El Capitan's XNU was 3247.1.106~1 and iOS 9.0 was 3248.1.2~3. This is not surprising, considering that iOS introduced novel features (such as Kernel ASLR, the default freezer, and various security hardening features) which are first incorporated in it, and later made it to macOS. It seems that Apple is gradually uniting the iOS and macOS kernels over time, and with iOS 9 and OS X El Capitan the version numbers are nearer to each other then ever before. The compilation date for each version will vary slightly between processors. This is due to the fact that compilations are sequential. The following demonstrates the OS versions at present (via terminal uname -a command):

Note: The RELEASE_ARM_xxxxxxxx file obviously differs on device / CPU and the time varies by a few minutes per device.

macOS/OS X
Missing versions are not listed due to no kernel versions being known. If you have any information on them, please add them to the list below.

Source Code
As XNU is based off of the BSD kernel, it is open source. The source is under a 3-clause BSD License for the original BSD portions with the portions added by Apple under the Apple Public Source License. The versions contained in iOS are not available, instead only versions used in macOS are available. This appears to violate APSL as per &#x00A7;2.3 in the APSL: 2.3    Distribution of Executable Versions. In addition, if You Externally Deploy Covered Code (Original Code and/or Modifications) in object code, executable form only, You must include a prominent notice, in the code itself as well as in related documentation, stating that Source Code of the Covered Code is available under the terms of this License with information on how and where to obtain such Source Code. with Source Code defined in &#x00A7;1.8: 1.8    "Source Code" means the human readable form of a program or other work that is suitable for making modifications to it, including all modules it contains, plus any associated interface definition files, scripts used to control compilation and installation of an executable (object code).

It is worth noting that Apple does not list XNU as being an open source component of iOS. This can be seen by viewing opensource.apple.com and selecting any iOS version. As far as can be told, none of the versions of XNU are available in source version.

There are many other open souce components that iOS uses that are not listed, such as: It does not appear that Apple assumes what you see in the macOS pages are also on iOS as JavaScriptCore, WebCore, among others are listed on both macOS 10.8 and iOS 6.0, albeit different versions.
 * CF (CoreFoundation - Cocoa)
 * SQLite (SQLite - database utility)
 * TimeZoneData (tz database - /usr/share/zoneinfo)
 * curl(?) (libcurl - various HTTP operations)
 * hfs (hfs - HFS driver)
 * launchd (launchd - launch daemon)
 * libxml2(?) (libxml2 - parser for XML plists)
 * xnu (XNU - Kernel)
 * zip (Info-ZIP - extraction of various files)

It is also worth noting that gdb (GCC debugger) and ld64 are listed as components in iOS 6.0. Why there are present is a mystery as they are not present on unaltered devices, but only through Cydia or Xcode's.

Kernel Extensions
iOS, sadly, does not have kexts floating around the file system, but they are indeed present. The kernelcache can be unpacked to show the kernel proper, along with the kexts (all packed in the __PRELINK_TEXT section) and their plists (in the __PRELINK_INFO section).

The kernelcache can also be directly unpacked (if decrypted) using the Jonathan Levin's joker tool from https://newosxbook.com/tools/joker.html. With the advent of iOS 10 betas and out-of-box plaintext kernelcaches, this tool can be used after unpacking and applying lzssdec to decompress the kernelcache to its full size.

The Cydia supplied kextstat does not work on iOS. Sadly, the reason is that kextstat relies on, which is a deprecated (and recently removed) API in iOS 4.x and Mac OS X 10.6. With that said, the kexts do exist. As an alternative, consider using kextstat from the iOS BinUtils package (https://newosxbook.com/tool/iOSBinaries.html) or the open source modified version "JKextstat" (https://newosxbook.com/src.jl?tree=listings&file=18-1-JKextstat.c ), which can also dump the raw XML data.

For a specific extension, e.g. SandBox, the full information (including the handy load address) is also accessible:

com.apple.security.sandbox CFBundleVersion 154.7         OSBundleCPUSubtype 9         OSBundleCPUType 12         OSBundleDependencies 6                 7                  5                  3                  28                  1                  4                  16                  2          OSBundleExecutablePath /System/Library/Extensions/Sandbox.kext/Sandbox OSBundleIsInterface OSBundleLoadAddress 2153734144         OSBundleLoadSize 36864         OSBundleLoadTag 29         OSBundleMachOHeaders OSBundlePath /System/Library/Extensions/Sandbox.kext OSBundlePrelinked OSBundleRetainCount 0         OSBundleStarted OSBundleUUID OSBundleWiredSize 36864         OSKernelResource

It's also worth mentioning that, in the above listing, the OSBundleMachOHeaders (base-64 encoded binary headers) leak kernel addresses in iOS 6.0, defeating Kernel ASLR. This has been quickly fixed in iOS 6.0.1, effectively locking down iOS for the foreseeable future, thanks to security researcher mdowd.

Winocm's custom kernel
Winocm uses a custom kernel which the version can be found below. Darwin Kernel Version 13.0.0: Fri Nov 22 18:19:54 CST 2013; root:xnu-2050.48.13~7/DEVELOPMENT_ARM_S5L8930X