I've implemented notifications extension and now try to debug my code, but without any success.
I tried several approaches how to handle it, for example stackoverflow question
When I "attach to process ...", I just see "waiting to attach" message on desired process. If I send push notification to invoke my extension, it just crashes
Message from debugger: Terminated due to signal 9
Is it possible that OS just close my extension, because it uses to much memory or it has too big size (~.appex = 20mb), but I can't find guidelines about extension size/number of files, etc.
Any suggestions, help?
Thx in advance
It seems like that there is a memory limit for Notification Service Extension. Someone said it may be 5mb. And someone said that the limit is 5mb in ObjC, or 15mb in Swift.
Due to the limit, I remove all 3rd party libraries in Notification Service Extension.
I disabled the address sanitizer and undefined behavior sanitizer in the main app's scheme and the service extension loads ok now.
I have checked Notification Service Extension, Here you can see what is memory limit as per latest iOS update.
As per Xcode debugging 24 MB is notification extension memory limit.
Related
It is not really a question but I wanted to write it down here so other people facing the problem could find the solution.
Since the release of iOS 13, some of our users were contacting us telling that our app was resetting each time they go into background for a medium amount of time (approximatively 30sec).
Of course, absolutely no clue of the behavior, nothing on Crashlytics etc. We were able to reproduce on a QA device but unable to reproduce on a debugger attached device.
So obviously we used the Console to monitor what's going on and we noticed that a weird message was being sent after approx. 25sec after our app was put into background:
default 10:14:01.658579+0100 XXX RunningBoardServices Received process assertions expiration warning!
default 10:14:01.659214+0100 XXX RunningBoardServices Notifying client of imminent expiration of assertion
default 10:14:01.659568+0100 XXX RunningBoardServices Expiration notification complete
If you were fast enough to relaunch the app, everything just worked fine, but if you left the app inactive for another 5sec (approx.) and then relaunched it, then the app was resetting (appDidFinishLaunching...).
...
...
We dug deeper and deeper without finding anything... until we decided to update some of our external libraries through Cocoapods, and guess what? we found our guilty guy: GoogleDataTransport from the Firebase suite!
We were using the 1.1.3 version and updating to the 3.0.1 fixed the issue. I guess they were doing some "bad" stuff in the background...
That's it guys. I hope it will help some others!
Cheers.
EDIT:
From this page (Firebase release notes) https://firebase.google.com/support/release-notes/ios#6.11.0, you can read:
Fixed race condition that prevented upload from completing while app was in the background.
Version 6.10.0 - October 8, 2019
From what I understand, maybe Firebase was not notifying iOS that the upload they were doing in the background was completed. It could explain why iOS 13 kills an app in this case.
🤷♂️
EDIT 2:
Apple apparently released an iOS update (13.2.2) which is supposed to solve these background issues: https://twitter.com/engadget/status/1192512171252551682?s=12.
Fixes an issue that could cause apps to quit unexpectedly when running in the background
We tested it using an old app which does not include our previous fix and unfortunately the problem is still present...
The crash was due to a background task leak. In my application, some SDKs don't use the background task correctly. Because it was killed by the watchdog, debugging will not appear, you can print beginBackgroundTask and endBackgroundTask during debugging. If there is a mismatch, a leak occurs.
I wrote a category to hook background task related methods to avoid leaking being killed by watchdog：https://github.com/ruanjx/MPIBackgroundTaskProtection
More information about background task：https://medium.com/swlh/handling-background-tasks-in-ios-13-67f717d94b3d
I have an app which uses a lot of the sandbox cache temporarily. I would like to prevent the OS from triggering the "storage almost full" warning by not filling up the disk beyond the trigger point.
I cannot find documentation on how this level is set.
Is it configurable for the user ? Is it unique to the device or IOS version ?
Update:
There is a solution available for this in Apple Developer Forum.
log out of itunes store in settings, wait 10 minutes, then log back
in. your storage should go back to what it should have been all
along. there is an itunes media caching bug / storage leak in ios 8
(all versions so far)
Original answer:
As far as I know there is no warning like that in iOS.
You can use as much as space available in the device, there is no limitation for that. Also those cache files are temporary, it'll be automatically cleaned.
From the ios developer doc, I found that an iOS app could support maximum of 64 local notifications.
( somewhere in stackoverflow I found it's maximum limit is 128 ).
So, I made an app scheduling 300 UILocalNotifications.
Xcode 5.1 compiled my code scheduling all 300 notifications.
I used NSLog() to verify this.
NSLog(#"\nLocal notifications count is::%d",[[UIApplication sharedApplication] scheduledLocalNotifications].count);
And then I began testing.
I observed notifications over 150.
So, how's this possible?
But I had an issue. When I clicked on my app, it displayed an alert : "NotificationTestingApp" is No Longer Available
Can somebody explain this?
Thanks.
With a custom crash reporting system (like the ones specialized at Ask the user to send crash log after crash on iPhone) to send the log, the app needs to restart. Why? Isn't there a possibility to send it during the custom exception handling? Or is there a crash reporting system that doesn't need to restart the app?
When a crash occurs the app is in a highly unstable state. So a crash reporting library can not do anything since even allocating memory at crash time may cause way more damage. So crash reporting SDKs can only use so-call async-safe C methods to collect all crash data. Any Objective-C code can not be processed either and also the iOS networking stack can not be used.
Please also note that exceptions are just one example of app crashes in Objective-C, there are also crashes triggered by low-level BSD signals. Both types mean that the app is in a highly unsafe and unstable state and as little code as possible should be invoked at crash time.
So this would require a rewrite of most of the networking frameworks to be able to send data out at crash time, and this may even not be possible to do in a safe way. That is why all proper crash reporting SDKs don't do anything like that.
In addition, on iOS it is not possible to create another process which could send the data in the background, so the only safe and possible solution is to send data the next time the app starts.
Now this has another conclusion that crashes that happen early on app startup might never be sent since the app is crashing before or while it sends. Some SDKs provide mechanisms to handle that scenario which most likely requires changes in your app startup code.
Since you app crashed there is no process running any more that you app controls, thus you can not start a new process to send the report.
Any code in the crash handler only has limited time to save what ever made you app crash before iOS kill whole app and removes it from memory.
When you restart you app the crash reporter formats the crash report and sends it. This can only be down when the when you app is active.
I have an app that runs in the background. This application is called to be able to update and then goes to sleep.
For some reason, it stops working after a few hours.
I have some theories but I can not find documentation about them.
iOS closes applications when there's a lack of memory.
Does anyone know the order used in this process?
Does it choose applications that have been running longer, which occupy more memory, or does it simply randomly close apps to get the needed memory?
Is there a maximum time limit that an application may be running in background?
Is there a maximum number of repeats for an NSTimer?
Does iOS close applications in the background if battery levels are reduced in order to conserve power?
If anyone can answer these questions, or provide some information about them, that would be great.
The theories are founded on the basis of report of clients.
To answer point by point (in a simplicistic way):
An app running in background which is going into out of memory condition should get killed by the operating system, but its application delegate should receive an applicationWillTerminate message.
No time limit is officially stated for background running apps.
NSTimer can only be of one kind out of two: repeating or non-repeating. You can refer to the NSTimer class reference documentation for the evidence of such aspect.
The app can't do that, by Apple policy if I can remember correctly. If the device is running low on battery, it must not intervene on open apps to extend battery duration.
For a complete description of apps background running modes you should refer to Apple Developer Documentation at this link.
It is a good starting point to understand multitasking and the correct policy to adopt if your app has to responsibly run in the background.
In the Apple Docs you can find a very analytical description of the allowed background execution modes, under which circumstances you can use each one and also some best practices to follow. If your app follows nothing of the above, then things are getting fairly arbitrary. AFAIK there is no way to know when the operating system will kill your app or do anything to prevent it.
Start by looking into the crash report with XCode Organizer. The crash report will have an exception code that shows why the application went away.
If you have a problem with the background operation, as hinted in the question and the answer from spassas, you will see the exception code 0xbad22222 in the crash report.
See the Apple doc on exception codes for more details.