If your app is terminated by the iOS system does it generate a crash report? -

while running on device (ios 8) think system may terminating app while suspended either memory or running background task long. suspect because when resume app has returned root view controller, shouldn't possible unless app started fresh.

i never see crash report when viewing device logs however.

if system terminates app generate crash report?

if app killed low memory generates low memory report:

when low-memory condition detected, virtual memory system in ios relies on cooperation of applications release memory. low-memory notifications sent running applications , processes request free memory, hoping reduce amount of memory in use. if memory pressure still exists, system may terminate background processes ease memory pressure. if enough memory can freed up, application continue run , no crash report generated. if not, application terminated ios because there isn't enough memory satisfy application's demands, , low memory report generated , stored on device.

the format of low memory report differs other crash reports in there no stack traces application threads. memory usage of each process reported in terms of number of memory pages, of writing 4kb each. see "(jettisoned)" next name of process terminated ios free memory. if see next application's name, confirms application terminated using memory.

this report can seen in crash logs, but, experience, log not guaranteed.

an example of memory report:

incident identifier: 30e46451-53fd-4965-896a-457fc11ad05f crashreporter key:   5a56599d836c4f867f6eec76afee451bf9ae5f31 os version:          iphone os 3.1.3 (7e18) date/time:           2012-10-17 21:39:06.967 -0400  free pages:        96 wired pages:       10558 purgeable pages:   0 largest process:   rage masters  processes      name                 uuid                    count resident pages rage masters <cc527ca9b51937c5adbe035fe27a7b12>    9320 (jettisoned) (active) mediaserverd <3d3800d6acfff050e4d0ed91cbe2467e>     255  dataaccessd <13d80b2e707acc91f9aa3ec4c715b9cc>     505      syslogd <8eddddc00294d5615afded36ee3f1b62>      71         apsd <32070d91b216d806973c8f1b1d8077a4>     171    securityd <b9e51062610d27f727c5119b8f80dcdf>     243      notifyd <591dd4dd804b4b8741f52335ea1fa4ab>    2027   commcenter <b4b87526ae086bb62c982f1078f43f81>     189  springboard <324939a437d1cca1fa4af72d9f5d0eba>    2158 (active)   accessoryd <8f21c8b376d16e2ccb95ed6d21d8317a>      91      configd <85efd41aceac34ccc0019df76623c7a9>     371    fairplayd <a2eaf736b3e07c7c9a2c82e9eb893555>      93 mdnsresponder <df1cd275e4ad434e0575990e8e1da4cb>     292    lockdownd <80d2bd44c0bcca273d48ce52010f7e65>    1204      launchd <a5988245aade809bf77576f1d9de42c5>      72 

actually, 1 of problems crashlytics's team trying solve:

these tricky, these events separate events crashes. low-memory events complex capture there no known way capture low-memory exit public api.

however, working on system produce record of these events. stay tuned!

regarding background crashing crash log this message:

application specific information: mymapapp[1234] has active assertions beyond permitted time:  {(     <sbprocessassertion: 0x63a07a0> identifier: corelocationregistration process: mymapapp[1234] permittedbackgroundduration: 600.000000 reason: finishtask owner pid:1234 preventsuspend  preventidlesleep , <sbprocessassertion: 0xa095050> identifier: corelocationbackgroundclient process: mymapapp[1234] permittedbackgroundduration: 600.000000 reason: finishtask owner pid:1234 preventsuspend  preventidlesleep  )}