Notification when Xcode deploy will terminate the app? - ios

When an app is attached to the Xcode debugger, none of the usual lifecycle methods (applicationWillResignActive:, applicationWillTerminate:, etc.) or notifications (UIApplicationWillTerminateNotification, etc) are triggered.
Is there any way for the app to know it's about to be stopped or re-deployed? Perhaps by trapping a signal?

Nope. For all intents and purposes, the STOP button in Xcode immediately terminates the application. There isn't a way to catch this.

applicationWillResignActive and applicationDidEnterBackground and their counterparts do get triggered when you press the home button on the device or simulator (or when you come back). I don't think you can catch the ones related to termination.

Related

Is there any delegate which fires while app is killed from background only?

Is there any delegate which fires while app is killed from background in iPhone X?
No. Your app is suspended. It can't get any events because it isn't running. If the app is running in the background, you might get applicationWillTerminate: if the user terminates the app, but I wouldn't count on it. Basically you should assume when the app goes into the background that it might be terminated.
Yes there is please refer to Pushkit framework, I have done that same task using this library, Here]1 is the link all you need to set up, if you want to try in kill mode, you need to do this on Xcode => go to edit scheme in your Xcode.
After setting all this you will be able to do all you need

How to debug a crash which happened when come back from background

There is a crash happen when coming back from background through app icon.
However I cannot see any detail info in console log. There is a signal to terminate, but we cannot find signal number.
<FBApplicationProcess: 0x117bcb930; Maixxxx; pid: 1762> exited abnormally via signal.
Process exited: <FBApplicationProcess: 0x117bcb930; Maixxx; pid: -1> -> <FBApplicationProcessExitContext: 0x17103f820; exitReason: signal; terminationReason: (none)>
The procedures to reproduce my crash is as follow:
Start app through click on app icon.
Use the app as normal user.
Press home to put it in background.
Wait for some minutes.
Click the app icon on springboard screen in order to use it again.
The app crash&exit.
Since the crash only happen when coming back from background, and required to enter background for some minutes, I cannot run in debug mode with lldb attached.
I didn't use any of background features.
Also, I didn't see any crash report in Fabric's Crashlytics. So I think signal handler could not be called neither?
How to investigate this kind of problem?
These things can be tough, I know that from similar experiences. Without knowing more about your app I can only offer hints and no definitive answer, but perhaps this helps you.
The fallback and tedious approach to use direct logging with print and so on notwithstanding there are a two ways to try to "catch" a process.
However, first let me stress that "background" is not always the same and people unfortunately use the term often loosely. Depending on what state transition causes your crash you might run out of luck and have to simply experiment using manual logging. Apps can be in background, i.e. not in the foreground, but still running. This is usually the case when the debugger is attached, otherwise it couldn't do its job. Alternatively they can be suspended (or even terminated) by the OS. The debugger prevents this, which you probably already figured out.
The two things that might help you are:
If you're using background fetch, i.e. "coming back from background mode" as you describe it happens automatically you can activate the "Launch due to a background fetch event" option in your build scheme's "Run" configuration section.
Run your app from the Home screen, put it into background with the Home button and wait a bit (you've probably done so in the past already to get a feeling for when the crash would happen). Your app should eventually go into the suspended state (but you have no way to actually see that anywhere AFAIK). Instead of getting it to the foreground again via the multitasking UI, simply attach the debugger again via the "Debug - Attach to process" menu. This should get your app from the suspended state back into the background state, where the crash probably really happens (if it were to happen when coming from background to foreground you probably would have been able to debug it as usual). Hopefully the debugger has finished attaching to it in time, otherwise I'm out of ideas. :(
I haven't run into this specific problem myself personally, but I know background stuff can be tricky. Maybe this discussion also helps you (I took part of my info from there as well).
Run the app in debug mode on a real device. Press the Home button to send the app to background and continue the debugging. Then you can bring the app to foreground and keep debugging, or put a breakpoint at applicationWillEnterForeground.
You can't debug this on the real device. When the debugger is attached, your apps will never go to background mode in the real device.
You can try to debug this on a simulator.
Anyway please check your class attributes and set attributes to strong to make sure this is not happened by missing attributes.
I have read several StackOverflow questions that have FBApplicationProcess. Usually, this one happened by missing array or something when the app started.
Best regards.
I have gone through all the above answers and all have given proper answers. Though, I would like to share my point of view.
If the app is running on any iOS real device with debug mode and wire plug-in or even on Simulator, App will never go in the background.
If the app is running without wire plug-in or run without Xcode(directly launch the app in iPhone) and then put the app in the background, the app will be running in the background of next 3 mins. After 3 mins, the App will automatically be suspended and removed from the main thread. Now, when we open the app again, It will be considered a fresh launch.
If your app having any Background Capabilities ON, then your app will be alive even in the background, but you can't do any UI changes during that time.
To keep app alive in the background, Background Capabilities must be handled properly. ie. If Location is used in your app with 'While-App is in Foreground' condition, app will not run more than 3 mins in background. So, If you want to run your app continuously in background, you must have to represent proper reason in Info.plist file with Battery drain word, or else, Apple will reject it.
Ping me for more detail on your question.
Thanks.
Crash logs still available on your test device.
To get the crash log try the following steps:
Connect your test device to the Mac through USB.
Launch Xcode. Go to Windows > Devices and Simulators.
Choose your device from the devices section on the left side of the screen.
Select View Device Logs button.
Identify and select the Crash Log to see the contents.

Is there a way to stop an app from closing if it stalls on splash screen?

I've been testing an app for iOS in Xamarin Studio, however whenever I reach a breakpoint or an exception is thrown and I stay there for a few seconds without pushing the continue execution button, the debugging session will close as the app will close on my device. This is due to the process mentioned here, as it is occurring during the splash screen, and if the app pauses too long there, it will close the app because it failed to scene-create. I was wondering if it is possible to disable this when debugging with breakpoints, because I would like to look at the data flow through variables and such.
As matt guessed, it is a Xamarin issue. The response to my inquiry to Xamarin was this,
Xamarin does not currently use a native debugger, thus watchdog is not
disabled. They are looking into alternatives, but for now a potential
workaround is to not do anything until you've returned from the
FinishedLaunching method (i.e. start your launch code in a timer event
for instance), and debug that instead.
Update: the status on this bug is "fixed for the next major release." as of 12/29/15

app delegate's applicationWillTerminate not called when user kills app or shuts down device

I need to know when my app is being terminated (I am not talking about going to background).
Unfortunately the applicationWillTerminate method is never called.
I found some posts on SO about applications going to background, but I really need it when they are terminated. (Pressing home-button twice and then swiping up)
Any ideas how to get notified, when the app is terminated?
When the app is killed you will not get any notification to handle it in your app. The app just gets a signal 9, and the kernel cleans up the process including all threads.
I'm developing iOS-apps for almost two years, and I often have put a breakpoint into the -applicationWillTerminate: method, and the debugger never happened to break there. I think the method is only relevant to apps that are not multitasking-enabled - not multitasking-enabled apps are pretty rare since iOS 5. You'd have to explicitly disable multitasking in your Info.plist file, and there is usually no good reason to do this!

IOS push notification break point

I use phone-gap plugin for APN and xcode 5.
https://github.com/phonegap-build/PushPlugin
I put a breakpoint at each function in the plugin.
For some reason when i send a push notification not even single break point are hit.
But the notification received on my device.
Any explanation for this.
Thanks in advance.
There are some things you could check:
Did you set them in in xcode or in the safari debugger? Actually I am not sure if the first option would ever work at all. Have any breakpoints worked in your application?
Is the app running in the foreground when the notification is received? As far as I know, no code is executed on receiving the message if the app is running in the background, so this might also be a reason for not hitting any breakpoints.

Resources