We have an app which is monitoring one location. Lately we have noticed that sometimes, ios app doesn't send notification for enter. Things are working fine with android app.
I was reading up on the documentation and the only litmition i found is that an app can only track 20 locations. Which isn't the case in our app. We are tracking only 1 location.
I also looked into if the app has proper implementation and it does, thats why we get notifications sometimes and sometimes we don't.
The other thing that i could think of is if the cell phone was in Low Power Mode. That's one pointer for me so far.
Is there anything else that i could look into to figure out the issue?
Related
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.
There are previous topics about waking up an application from the background with BLE advertisement (e.g. How to wake up iOS app with bluetooth signal (BLE), Android / iOS - BLE - wake up a terminated application when a BLE device connects).
However my question is not about that since we had this feature working fine up to iOS 9.2 included.
Coming iOS 9.3 the feature doesn't work as it used to work before, it seems that the terminated by user swiping off the application is not woken up. Nothing changed on the BLE advertisement originator.
After a recheck of various parameters and reading of Apple documentation, nothing springs to our minds. Neither Apple documentation mention any change, unless we missed something.
Have other people notice this issue? Are you aware of a solution?
We wrote to Apple and we are pending on an answer but maybe somebody here has the correct tip.
Many thanks in advance for the attention.
UPDATE: After more testing, it seems that only when the user swipes the application out the wake up doesn't work like it used to in iOS 9.2
Initial testing were more manual and gave us the impression that there was an underlying issue. However not sure why this change took place without any notification from Apple. - Above text was amended based on the update -
UPDATE 2: This issue is not present anymore in iOS 10.
It turns out after a reply from Apple that this is a (new) intended behaviour.
didEnterRegion/didExitRegion events stopped working from the background after update to 9.3
I have an app that has been working almost perfectly for the last 6 months, and after the update these events are no longer getting called. I started this app over last year when I heard about iOS9 coming out, and when I couldn't get the old one working, I started a new one using Swift instead.
After some time and a LOT of driving in and out of my Region, I got the app to work more reliably than it ever had before. I have several devices using the app, and when all of them updated to iOS9.3/9.3.1, the app stopped calling didEnterRegion/didExitRegion events completely.
I have a ticket open with Apple, but I am getting a lot of push back about the service, and that 9.3 didn't change background location at all.
My devices use AT&T of Verizon, we have tried wi-fi assist on and off, I even wiped a system, formatted the HD, installed El Capitan, and XCode 7.3, and it's hasn't helped.
I also found an issue with the Devices Tool, and when you download the Container, and open package, the Documents folder is empty. I'm not getting a warm fuzzy feeling for Apple right now, and I am sure someone is feeling my MEGA MIND WEDGIE at this moment.
Help....
I'm trying to log users individual app usage on iOS9.
I'd rather prefer that it wouldn't use jailbreak limited solutions, self explanatory. Doing the variation of this app on a jailbroken phone shouldn't be hard.
This will certainly not be released on the App Store as Apple wouldn't allow it.
I'm looking for any private API that can do this, any hidden iOS API's that can be used to do this. ANYTHING.
What I've already looked through:
how to determine which apps are background and which app is foreground on iOS by application id
How to know about app launched and details jailbreak iOS 7
Is there a private API to be able to detect what is current foreground app on iOS?
How to monitoring App running in the foreground in iOS8？use the PrivateFrameworks SpringBoardServices
which proved to be relatively helpful - we now can assume that there is some sort of additional access requirement, probably an entitlement, but we don't really know how it should look like
Can you find individual app usage duration using SpringBoard services framework or other private framework?
Find out active application or if on Springboard
Programmatically detect which iOS application is visible to user
However all of these proved to be unhelpful because Apple fixed this security flaw with iOS8 and the method to copy/access the currently front most app bundle identifier no longer works.
Question is: Is there someone who knows a workaround using different tools/exploits that do not require jailbreak?
Ideas:
inspecting the processes running on the device and devising an algorithm that would be able to recognize spikes that mean an app has been launched, which potentially could work, but it probably would be a major pain in the ass. Questions mentioning this solution:
Detect which app is currently running on iOS using sysctl,
Return a list of running background apps/processes in iOS
How to get Names of Background Running Apps
Find Background running apps in iphone
inspecting the phones traffic somehow?
not sure if there is some kernel stuff that I could do
Here is my Reddit version of this question if anyone wants to check it out. Also if it's of any value, here are the runtime headers for iOS9 and list of Apple's private API's.
Unfortunately, I was looking for a similar solution and have come to the conclusion that, at least at this point in time, there are no known methods that will allow you to determine app usage on iOS. Even the MDM providers such as Good, Airwatch, MobileIron, etc. don't seem to be able to do this. If anyone is able to come up with a solution, I'd love to see it.
For now, however, I think we would have seen a solution if someone had one that worked on the latest iOS.
sysctl is still open but they block certain combinations of selectors. I did this on iOS 7 and gave Apple Product Security the code. They won't patch iOS 7 but rely on App Review. iPhone 4 is wide open.
My app has a bug, which I am unable to replicate when it is run when plugged into the computer.
I see it three times a day and it is quite annoying.
Is there any way to capture the state of the app (when not connected to the computer) and see what's going on? Kind of like what XCode does when you use a breakpoint, but somehow send the data to it (or some order tool that I am unaware of) wirelessly.
UPDATE:
The app does not crash. It's just that certain UITableViewCells don't work as they should at certain times.
Try using Crashlytics its awesome for crashes. You should also use TestFlight which will give you live sessions/logs of your app. These both combined will tell you many things.
My app is an emergency app. It will be used by people in emergency and disasters.
It's possible that they got stuck in situations where they just don't have the time to enter or draw their password on the lock screen, launch the app and push a button. Is it possible that my app can ask the OS to launch the app if user throw their iPhone up in the air or shake it vigorously or something else.
What I wish to achieve by this ?
I want that OS launches my app in background if the user say shake his/her iPhone vigorously. Once launched my app will make a network request and keep running in background for short time.
PS:I think it's possible with the accelerometer.
Accelerometer will not work because Apple doesn't allow background processes opening apps. In your case, user must be opening the app by himself/herself manually. (PS. As far as I know, it's possible in Android)
iOS background tasking problems aside:
Apple don't allow apps that encourage the user to do things that might damage their iOS device. So your 'throw in the air' idea is out.
As for shaking the device -- this just isn't practical. What if the device gets shaken by accident? You've then got false alarms to deal with.
The crux of the issue is that something that triggers an emergency response should be a deliberate action which is hard to do trigger by accident.
This cannot work - and here's why.
Your app would need to run in background to handle motion events. Apps running in background can get killed at any time, i.e. if memory gets low. There might be some restrictions about running and and resource usage as well.
An app in the background cannot bring itself to the front.
Launching from a locked screen would bring great security risks.
Throwing into the air seems like a gesture that can easily be triggered by accident.
I must admit that I'm pretty happy that those apps are not allowed on the AppStore - as it would open many doors that I'd like to see kept close.