App interface snapshot flashes briefly after terminating app from suspended state
How do I achieve my expected behaviour?
Current behaviour
Terminating app from a suspended state causes a brief flash of the last app snapshot taken by the OS.
The order of things rendering, following launching after suspended state termination:
- Launch screen storyboard image
- App snapshot of last visible screen - same as one in the home button initiated multitask menu
- Root view controller with its initial view
Expected behaviour
An app NOT participating in state restoration, when it terminates, should launch with the default launch image. I would like that to happen.
The order of things rendering, following launching after suspended state termination:
- Launch screen storyboard image
- Root view controller with its initial view
Replicated by
- Running the app
- Pressing home button - moving app to background
- Double-pressing home button - opening the multitask menu
- Swiping the app up - to terminate it
- Opening it again
My settings
My UIViewController subclasses are implemented completely programmatically - no Xib or Storyboards.
The LaunchScreen is a Storyboard.
I have explicitly made sure that the app does not engage in state restoration, with the following in the App Delegate:
func application(_ application: UIApplication,
shouldSaveApplicationState coder: NSCoder) -> Bool { return false }
func application(_ application: UIApplication,
shouldRestoreApplicationState coder: NSCoder) -> Bool { return false }
My Info.plist, has the setting:
Application does not run in background = NO
Notes
I know aboutignoreSnapshotOnNextApplicationLaunch() in a UIViewController's encodeRestorableState(with coder: NSCoder) method, and generally setting-up a restorable state - except that I do not want to have a restorable state.
I want the app to:
- relaunch from scratch whenever it terminates, for whatever reason
- return from a non-terminated suspended state
- not flash the app snapshot when launching after termination when suspended
Creating and destroying a view in App Delegate's applicationWillResignActive(application:) and applicationDidBecomeActive(application:) methods is also not helpful.
What is the best way of doing this?
ios swift uikit
asked Nov 26 '18 at 14:13
Mark JareckiMark Jarecki
48110
add a comment |
How do I achieve my expected behaviour?
Current behaviour
Terminating app from a suspended state causes a brief flash of the last app snapshot taken by the OS.
The order of things rendering, following launching after suspended state termination:
- Launch screen storyboard image
- App snapshot of last visible screen - same as one in the home button initiated multitask menu
- Root view controller with its initial view
Expected behaviour
An app NOT participating in state restoration, when it terminates, should launch with the default launch image. I would like that to happen.
The order of things rendering, following launching after suspended state termination:
- Launch screen storyboard image
- Root view controller with its initial view
Replicated by
- Running the app
- Pressing home button - moving app to background
- Double-pressing home button - opening the multitask menu
- Swiping the app up - to terminate it
- Opening it again
My settings
My UIViewController subclasses are implemented completely programmatically - no Xib or Storyboards.
The LaunchScreen is a Storyboard.
I have explicitly made sure that the app does not engage in state restoration, with the following in the App Delegate:
func application(_ application: UIApplication,
shouldSaveApplicationState coder: NSCoder) -> Bool { return false }
func application(_ application: UIApplication,
shouldRestoreApplicationState coder: NSCoder) -> Bool { return false }
My Info.plist, has the setting:
Application does not run in background = NO
Notes
I know aboutignoreSnapshotOnNextApplicationLaunch() in a UIViewController's encodeRestorableState(with coder: NSCoder) method, and generally setting-up a restorable state - except that I do not want to have a restorable state.
I want the app to:
- relaunch from scratch whenever it terminates, for whatever reason
- return from a non-terminated suspended state
- not flash the app snapshot when launching after termination when suspended
Creating and destroying a view in App Delegate's applicationWillResignActive(application:) and applicationDidBecomeActive(application:) methods is also not helpful.
What is the best way of doing this?
ios swift uikit
asked Nov 26 '18 at 14:13
Mark JareckiMark Jarecki
48110
1
There might be no way to control this. I find the snapshot behavior pretty crazy these days but unfortunately it isn't up to us. I'd file a bug with Apple if I were you.
– matt
Nov 26 '18 at 20:30
As matt said its behaving very awkwardly in the recent os updates. I would recommend to put a blur view on the current viewController whenever your app goes to background(you have to remove it in resume) so that user will see this view or the launch screen instead of seeing the actual screen opened last time. At least this will give some kind of consistency.
– Kamran
Nov 27 '18 at 6:53
I’ll probably file a bug or request. As I think there should be more explicit control of this aspect of operation. A few methods in the app delegate for general expected behaviour should suffice. Implementing an entire state restoration set of behaviours, just so you can ignore them, seems absurd.
– Mark Jarecki
Nov 27 '18 at 6:59
Another idea I have is to keep the background suspended state active, by giving it a long-running menial background task. Thus triggering theapplicationWillTerminate(application:)when the OS terminates from the suspended state. But I fear Apple or the phone's battery may not like this.
– Mark Jarecki
Nov 27 '18 at 9:27
add a comment |
How do I achieve my expected behaviour?
Current behaviour
Terminating app from a suspended state causes a brief flash of the last app snapshot taken by the OS.
The order of things rendering, following launching after suspended state termination:
- Launch screen storyboard image
- App snapshot of last visible screen - same as one in the home button initiated multitask menu
- Root view controller with its initial view
Expected behaviour
An app NOT participating in state restoration, when it terminates, should launch with the default launch image. I would like that to happen.
The order of things rendering, following launching after suspended state termination:
- Launch screen storyboard image
- Root view controller with its initial view
Replicated by
- Running the app
- Pressing home button - moving app to background
- Double-pressing home button - opening the multitask menu
- Swiping the app up - to terminate it
- Opening it again
My settings
My UIViewController subclasses are implemented completely programmatically - no Xib or Storyboards.
The LaunchScreen is a Storyboard.
I have explicitly made sure that the app does not engage in state restoration, with the following in the App Delegate:
func application(_ application: UIApplication,
shouldSaveApplicationState coder: NSCoder) -> Bool { return false }
func application(_ application: UIApplication,
shouldRestoreApplicationState coder: NSCoder) -> Bool { return false }
My Info.plist, has the setting:
Application does not run in background = NO
Notes
I know aboutignoreSnapshotOnNextApplicationLaunch() in a UIViewController's encodeRestorableState(with coder: NSCoder) method, and generally setting-up a restorable state - except that I do not want to have a restorable state.
I want the app to:
- relaunch from scratch whenever it terminates, for whatever reason
- return from a non-terminated suspended state
- not flash the app snapshot when launching after termination when suspended
Creating and destroying a view in App Delegate's applicationWillResignActive(application:) and applicationDidBecomeActive(application:) methods is also not helpful.
What is the best way of doing this?
ios swift uikit
asked Nov 26 '18 at 14:13
Mark JareckiMark Jarecki
48110
How do I achieve my expected behaviour?
Current behaviour
Terminating app from a suspended state causes a brief flash of the last app snapshot taken by the OS.
The order of things rendering, following launching after suspended state termination:
- Launch screen storyboard image
- App snapshot of last visible screen - same as one in the home button initiated multitask menu
- Root view controller with its initial view
Expected behaviour
An app NOT participating in state restoration, when it terminates, should launch with the default launch image. I would like that to happen.
The order of things rendering, following launching after suspended state termination:
- Launch screen storyboard image
- Root view controller with its initial view
Replicated by
- Running the app
- Pressing home button - moving app to background
- Double-pressing home button - opening the multitask menu
- Swiping the app up - to terminate it
- Opening it again
My settings
My UIViewController subclasses are implemented completely programmatically - no Xib or Storyboards.
The LaunchScreen is a Storyboard.
I have explicitly made sure that the app does not engage in state restoration, with the following in the App Delegate:
func application(_ application: UIApplication,
shouldSaveApplicationState coder: NSCoder) -> Bool { return false }
func application(_ application: UIApplication,
shouldRestoreApplicationState coder: NSCoder) -> Bool { return false }
My Info.plist, has the setting:
Application does not run in background = NO
Notes
I know aboutignoreSnapshotOnNextApplicationLaunch() in a UIViewController's encodeRestorableState(with coder: NSCoder) method, and generally setting-up a restorable state - except that I do not want to have a restorable state.
I want the app to:
- relaunch from scratch whenever it terminates, for whatever reason
- return from a non-terminated suspended state
- not flash the app snapshot when launching after termination when suspended
Creating and destroying a view in App Delegate's applicationWillResignActive(application:) and applicationDidBecomeActive(application:) methods is also not helpful.
What is the best way of doing this?
ios swift uikit
ios swift uikit
asked Nov 26 '18 at 14:13
Mark JareckiMark Jarecki
48110
asked Nov 26 '18 at 14:13
Mark JareckiMark Jarecki
48110
edited Nov 26 '18 at 20:11
Mark Jarecki
asked Nov 26 '18 at 14:13
Mark JareckiMark Jarecki
48110
asked Nov 26 '18 at 14:13
Mark JareckiMark Jarecki
48110
asked Nov 26 '18 at 14:13
Mark JareckiMark Jarecki
48110
48110
1
There might be no way to control this. I find the snapshot behavior pretty crazy these days but unfortunately it isn't up to us. I'd file a bug with Apple if I were you.
– matt
Nov 26 '18 at 20:30
As matt said its behaving very awkwardly in the recent os updates. I would recommend to put a blur view on the current viewController whenever your app goes to background(you have to remove it in resume) so that user will see this view or the launch screen instead of seeing the actual screen opened last time. At least this will give some kind of consistency.
– Kamran
Nov 27 '18 at 6:53
I’ll probably file a bug or request. As I think there should be more explicit control of this aspect of operation. A few methods in the app delegate for general expected behaviour should suffice. Implementing an entire state restoration set of behaviours, just so you can ignore them, seems absurd.
– Mark Jarecki
Nov 27 '18 at 6:59
Another idea I have is to keep the background suspended state active, by giving it a long-running menial background task. Thus triggering theapplicationWillTerminate(application:)when the OS terminates from the suspended state. But I fear Apple or the phone's battery may not like this.
– Mark Jarecki
Nov 27 '18 at 9:27
add a comment |
1
There might be no way to control this. I find the snapshot behavior pretty crazy these days but unfortunately it isn't up to us. I'd file a bug with Apple if I were you.
– matt
Nov 26 '18 at 20:30
As matt said its behaving very awkwardly in the recent os updates. I would recommend to put a blur view on the current viewController whenever your app goes to background(you have to remove it in resume) so that user will see this view or the launch screen instead of seeing the actual screen opened last time. At least this will give some kind of consistency.
– Kamran
Nov 27 '18 at 6:53
I’ll probably file a bug or request. As I think there should be more explicit control of this aspect of operation. A few methods in the app delegate for general expected behaviour should suffice. Implementing an entire state restoration set of behaviours, just so you can ignore them, seems absurd.
– Mark Jarecki
Nov 27 '18 at 6:59
Another idea I have is to keep the background suspended state active, by giving it a long-running menial background task. Thus triggering theapplicationWillTerminate(application:)when the OS terminates from the suspended state. But I fear Apple or the phone's battery may not like this.
– Mark Jarecki
Nov 27 '18 at 9:27
1
1
There might be no way to control this. I find the snapshot behavior pretty crazy these days but unfortunately it isn't up to us. I'd file a bug with Apple if I were you.
– matt
Nov 26 '18 at 20:30
There might be no way to control this. I find the snapshot behavior pretty crazy these days but unfortunately it isn't up to us. I'd file a bug with Apple if I were you.
– matt
Nov 26 '18 at 20:30
As matt said its behaving very awkwardly in the recent os updates. I would recommend to put a blur view on the current viewController whenever your app goes to background(you have to remove it in resume) so that user will see this view or the launch screen instead of seeing the actual screen opened last time. At least this will give some kind of consistency.
– Kamran
Nov 27 '18 at 6:53
As matt said its behaving very awkwardly in the recent os updates. I would recommend to put a blur view on the current viewController whenever your app goes to background(you have to remove it in resume) so that user will see this view or the launch screen instead of seeing the actual screen opened last time. At least this will give some kind of consistency.
– Kamran
Nov 27 '18 at 6:53
I’ll probably file a bug or request. As I think there should be more explicit control of this aspect of operation. A few methods in the app delegate for general expected behaviour should suffice. Implementing an entire state restoration set of behaviours, just so you can ignore them, seems absurd.
– Mark Jarecki
Nov 27 '18 at 6:59
I’ll probably file a bug or request. As I think there should be more explicit control of this aspect of operation. A few methods in the app delegate for general expected behaviour should suffice. Implementing an entire state restoration set of behaviours, just so you can ignore them, seems absurd.
– Mark Jarecki
Nov 27 '18 at 6:59
Another idea I have is to keep the background suspended state active, by giving it a long-running menial background task. Thus triggering the
applicationWillTerminate(application:) when the OS terminates from the suspended state. But I fear Apple or the phone's battery may not like this.– Mark Jarecki
Nov 27 '18 at 9:27
Another idea I have is to keep the background suspended state active, by giving it a long-running menial background task. Thus triggering the
applicationWillTerminate(application:) when the OS terminates from the suspended state. But I fear Apple or the phone's battery may not like this.– Mark Jarecki
Nov 27 '18 at 9:27
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53482988%2fapp-interface-snapshot-flashes-briefly-after-terminating-app-from-suspended-stat%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53482988%2fapp-interface-snapshot-flashes-briefly-after-terminating-app-from-suspended-stat%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
There might be no way to control this. I find the snapshot behavior pretty crazy these days but unfortunately it isn't up to us. I'd file a bug with Apple if I were you.
– matt
Nov 26 '18 at 20:30
As matt said its behaving very awkwardly in the recent os updates. I would recommend to put a blur view on the current viewController whenever your app goes to background(you have to remove it in resume) so that user will see this view or the launch screen instead of seeing the actual screen opened last time. At least this will give some kind of consistency.
– Kamran
Nov 27 '18 at 6:53
I’ll probably file a bug or request. As I think there should be more explicit control of this aspect of operation. A few methods in the app delegate for general expected behaviour should suffice. Implementing an entire state restoration set of behaviours, just so you can ignore them, seems absurd.
– Mark Jarecki
Nov 27 '18 at 6:59
Another idea I have is to keep the background suspended state active, by giving it a long-running menial background task. Thus triggering the
applicationWillTerminate(application:)when the OS terminates from the suspended state. But I fear Apple or the phone's battery may not like this.– Mark Jarecki
Nov 27 '18 at 9:27