I have a published app that has a need to keep the display on for an extended period of time. I use UIApplication.isIdleTimerDisabled to control it, setting it true when I need to keep the display on, and setting it false when it's no longer needed.
Since the app is distributed through the Apple App Store, I get reports when crashes occur. I sometimes get a report that points to a crash at a line where I call UIApplication.shared.isIdleTimerDisabled = false, i.e., where I'm restoring the normal state of affairs after the screen has been on for a while. Below is a screen shot of the stack trace.
I'm unable to reproduce the problem on my own. There are thousands of users who have downloaded and tried the program, and I only get one or two crash reports a week, so the problem must arise from some infrequently-occuring set of conditions. The crash reports come from a variety of iPhones and iPads running iOS 13 and 14.
Any ideas?
Related
I'm using App center to show the crash reports occurring in testing / production crashes. I was able to view the crash report graph before, but from the past 20 days I am not able to view the crash reports graph. Below is the image which I have always seen. I'm not understanding what happened. Has any one faced this issue?
From this https://github.com/microsoft/appcenter/issues/541 got some information, that need to change filter option to 28days but i don't find where should change this filter option.
I am facing a very weird issue: my iPhone is restarting.
This issue occurs in a particular scenario only.
Step 1: I have a sync process in which I'm loading data for the whole app. So I'm basically doing a heavy API call by uploading 4-5 camera captured images and syncing the app data;
Step 2: After syncing, I'm pressing the iPhone home button to make the app go in background;
Step 3: I'm locking the iPhone screen(by using side button);
After a few seconds I'm seeing the apple logo and the phone seems to restart. This is not replicating when the app is connected in debug mode. I checked the debug navigator app is using only 125 MB of memory, disk and network values is 0%. Energy Impact is showing high, I'm not sure this is due to high energy impact. I'm facing this issue only on iOS 12.4.
The fact that the phone (or possibly just springboard) restarts, and not just your application means this is Apple's bug. You're not supposed to be able to crash iOS even if you try.
Finding a likely cause will be hard since the system is not behaving the way it's supposed to. The device's logs may have more information from things other than your app. This may be a system API breaking due to any number of actions from your application.
Often with this kind of thing the next OS version will fix it, but if that's not the case or it's important to track down I would try removing ways you're interaction with the system (background APIs, notifications, etc.) and see if anything fixes the issue.
If you find the problem, you may even be doing things the "correct" way according to the documentation and have to find a workaround. If you have the time you can submit a bug to Apple so the underlying issue has a better chance of being fixed.
It seems when your app is in the background and phone locked, Automatic Reference Counting (ARC) closes some connection or deallocates a resource that makes the iPhone restart. Are you closing all connections and removing all references once the upload is complete?
Phones do not spontaneously restart just because of an app’s actions. You’re having an issue with your phone, not with a program. You need to repair or replace the phone.
Starting from iOS 12 the CLLocationManager doesn't run endless anymore in the background. The app get's terminated without a crashlog at random times. This was working fine before iOS 12.
To demonstrate this problem I've created an sample app here
The demo app just launches an CLLocationManager and keep this running in the background. While running on the background we keep track of it by logging it. The problem is that the app get terminated by iOS. The demo app is created to demonstrate this problem.
Steps to reproduce
Run the app on the device
Grand access to locationmanager
Put the app to the background
Wait for 1-48hours
Result:
The app is terminated
App is terminated without any reason after random time.
Expected result:
The app is still running.
How it should work
This is confirmed by an Apple engineer:
Once the CLLocationManager updates are started in the foreground and you did all the work to have it running in the background, the location updates should run endless in the background until:
app is force quit
device is rebooted
app stops location updates
app releases the CLLocationManager object
app crashes
iOS terminates the app due to memory shortage,
the locationManager object is released, overreleased, or overwritten. You should make sure that your view controller is not being instantiated, which then resets the locationController class. If that happens when the app is in the background, you will restart updates, which will cause the app to be eventually suspended. You should make sure the locationController is a singleton.
app is crashing. Check to see if there are crash logs on the device you are testing
iOS is terminating the app due to memory shortage. In this case, you will find JetsamEvent logs on the device that shows your app being terminated. You can check the timestamps and locate the one that is around the time your app stopped working.
Updated answer:
Apple fixed this bug in iOS 12.2 beta 2 (16E5191d)
Original analyse and bug detection:
Together with Apple Developer Technical Support we have analyzed this issue with Sysdiagnose files. Following these guidelines you can install profiles to have more logging on your device. I don't know exactly how these logs work and where to find this issue, but Apple did this for me and came with this first analyse:
On the suspension event you observed on 2018/10/22 01:01:12:587, this
is what I see (about a minute after your last activity logging)
[CllocationManag:2725] Terminating with description:
{
owner = ;
target = rw.sp.flitsmeister.frameworks.CllocationManagerBackgroundTest; }
This is basically saing that your app was terminated, because the
system needed drive space, and killed a bunch of apps so it can delete
their /tmp and /Library/Caches directories. I have seen this process
to be a little more aggressive in iOS 12, but seeing you are on a
256GB device, and have ~179 GB free after the cleanup, I am finding it
hard to believe this was justified.
After sending some more sysdiagnose and reproduction cases Apple did his best to analyse and ended with the following conclusion:
Unfortunately I don’t bring good news.
It turned out that, currently in iOS 12 there is a new mechanism that
will terminate long running background apps periodically as the system
needs to free resources. At this time, this process is a bit too
aggressive, and I am working with the relevant teams to get this to
behave better.
So, at this point, I would like you to file a bug report. Explain the
symptoms. And make sure you upload the sysdiagnose files along with
the bug report. (I already sent yours in, but it doesn’t hurt to have
the new ones as well). And let me know the bug number please.
So this means that currently in iOS 12 you app won't run endless on the background. I've filled in a bug report, the number is 45581276 and will try to keep this thread updated.
I tried clearing out the /tmp and /Library/Caches directories when the app goes in the background without any change in behavior. I also tried the same periodically when the app processing background locations without any change as well.
I've got an app that uses Core Data that sporadically stops launching so I have to reinstall it using XCode and then it launches again like normal for a while, with all the Core Data information still preserved.
I have seen that an app often stops launching when the target of an app is too low in comparison to the device software version, however this is not so for this app and device (iPhone 6s).
Have you had such an issue before? What do you think could be causing this problem?
There are many, many, many things that could cause an app to fail to launch. You need to narrow things down and collect some data so that you can find out what the problem is and do something about it. Right now you don't even know that it's related to Core Data, you're just guessing.
For a crash on launch, look at the device console and see what messages appear when you try to launch the app and it fails. You can get the device console messages by
Connecting your device to your Mac
Opening Xcode's "Devices" window (cmd-shift-2)
Looking in the bottom half of the window
A better way to watch the console is to use the free iOS Console app.
The problem was that, as mentioned by dan in the comments, the code was being signed for a short period of time (7 days) and so I had to keep re-installing it on the iOS device to keep it working. Thus to keep the app working indefinitely a paid developer account is needed.
Also mentioned in this reddit forum:
https://www.reddit.com/r/jailbreak/comments/4hotx3/news_free_developer_account_installs_reduced_to_7/
After noticing people in my company leaving our iPad app open all day on their desks to watch figures progress on a screen, and noticing we have some underutilized HDTVs on walls, I created a tvOS app and was able to put that information on the screen with minimal hassle, and we bought some fourth generation Apple TV units for the TVs. It's a huge hit.
However the one hitch is that the app doesn't stay alive indefinitely. I'm not sure why, but even though we've told tvOS to stay awake and not go to screen saver, every morning I come in and the app has exited and we're staring at the home screen. I have Crashlytics/Fabric installed on the app and I've had it crash a few times and send me emails about it but when I restart the app in the morning I don't get any emails, nor do I see any recurring crashes on their dashboard (it would likely be the same thing every day), so I don't think it's crashing.
So at this point it would make sense that perhaps there's some sort of time limit to how long an app can run that I'm running into.
I guess my first question is am I running into some sort of time limit at all, and the second question would be how could I prevent it from happening?
The intention is for this to only ever be an internal app and not go on the App Store so if there's some sort of way to do this that might get the app rejected by Apple that's not a problem since we're probably never going to release this to the public.
UPDATE:
So while Crashlytics/Fabric isn't telling me that the app crashed, the crash logs in the Devices window in Xcode is telling me that there are crashes.
Specifically it looks like at approximately 11:45PM every night, give or take a minute, it crashes with a EXC_BAD_ACCESS (SIGILL) KERN_PROTECTION_FAILURE message. So I'm left wondering if there's something happening fifteen minutes to midnight in tvOS, or in what my app is doing, or if it's just a grand coincidence that the memory leak or whatever that might be causing this is happening at that time.
I guess one way to test it would be to make an app that does nothing and see if the same thing happens. The lack of answers on this post makes me think this is either an issue in my code (i.e., tvOS isn't enforcing some curfew or something) or that not many people are trying to use tvOS in this way.