This question already has answers here:
Opt out of UISceneDelegate/SwiftUI on iOS
(6 answers)
Closed 3 months ago.
The question says it all.
There's the following line in apple documentation,
Scenes are opt in, but you must support them if you want to display
multiple copies of your app’s UI simultaneously.
It's not mentioned whether the SceneDelegate is mandatory or optional or a recommendation (I'm aware that the SceneDelgate is used to handle the lifecycle of the scene).
In a iOS 13+ device, can I create an app without SceneDelegate?
I defined the UIWindow variable in the AppDelgate and set the ViewController in application(didFinishLaunchingWithOptions), like before iOS 13. But that doesn't work and displays a blank screen.
And thus, this question. Is Scenedelgate mandatory even if we don't opt for multiple scenes?
Here's my observation:
Multiple scenes are optional. But you still have to support at least
one scene... and for that, SceneDelegate is mandatory.
If I'm wrong and SceneDelegate is optional (like described in this stackoverflow post), please help with the flows.
In a iOS 13+ device, can I create an app without SceneDelegate?
Yes. All apps do have scenes, but if you go with the app-delegate-only architecture, a single UIWindowScene will be created behind the scenes (pun intended). The app will run perfectly well on both iPhone and iPad, with all the usual lifetime events arriving as usual into the app delegate (though I do not know what will happen on Apple Silicon).
I defined the UIWindow variable in the AppDelgate and set the ViewController in application(didFinishLaunchingWithOptions), like before iOS 13. But that doesn't work and displays a blank screen.
This is because you did not correctly convert from the scene delegate architecture, which is provided by the app template you started with, to an app delegate architecture. Basically, you've left pieces of the scene delegate architecture lying around. Perhaps you did not delete all references to the scene delegate; perhaps you forgot to delete the UIApplicationSceneManifest entry from the Info.plist. Whatever the reason, the result is that the runtime thinks this app still uses scene delegate architecture, and it then fails to find certain pieces that it's looking for and shows the blank screen.
So, just to sum up what to do when you've started with the built-in app template:
Delete the SceneDelegate.swift file.
In the App Delegate, delete the two UISceneSession methods.
In the App Delegate, add a window reference as an instance property: var window: UIWindow?
In the Info.plist, completely delete the entire UIApplicationSceneManifest entry (and save).
Profit.
Related
I have my project which supports minimum ios version 12.4 and I'm using swift 5.2 in my project. To suuport Zoom SDK I need to remove sceneDelegate.swift file and SceneManifest from info.plist. Is it safe to remove sceneDelegate from existing project?
In my thought AppDelegate will be responsible for the application lifecycle and setup. The SceneDelegate will be responsible for what is shown on the screen (Windows or Scenes) handle and manage the way your app is shown.So will there be any issues in UI Flow of my APP if I remove Scene Delegate?
If I remove sceneDelegate how will handle app Foreground and Background Events?
Yes it 100% safe to remove SceneDelegate from your iOS app.
Please refer below steps to remove it from your app
Remove SceneDelegate.swift file
Remove Application Scene Manifest from Info.plist file
Add var window: UIWindow? to AppDelegate.swift
Replace #main with #UIApplicationMain
Remove UISceneSession Lifecycle ( functions ) in AppDelegate
After deleting scene delegate you would not able to do following
In iOS 13 and later, users can create multiple copies of your app’s UI
and toggle between them in the app switcher. On iPad, users can also
display one copy of your app’s UI side by side with another copy. For
each copy of your app’s UI, you use a scene object to manage the
window, views, and view controllers that present the UI onscreen
https://developer.apple.com/documentation/uikit/app_and_environment/scenes/specifying_the_scenes_your_app_supports
To answer you question to regarding view life cycle please refer this - https://www.appypie.com/scene-delegate-app-delegate-xcode-11-ios-13#:~:text=On%20iOS%2013,at%20a%20time.
I can't find a clear definition of what UIScenes are
Are they just for handling the background calls? Are they like a ViewController? Do we use them often or nah?
The biggest thing is that scenes set up multiple window support. It is also useful for SwiftUI.
The SceneDelegate controls what is displayed on the screen "to manage life-cycle events in one instance of your app's user interface.", while the AppDelegate controls your entire app life-cycle.
Read the App and Environment Article and scenes from Apple instead of UIScene documentation.
Scene:
Scene, Manage multiple instances of your app’s UI simultaneously, and
direct resources to the appropriate instance of your UI.
We had only one scene back then before iOS 13, So the only thing we need to run ViewControllers simultaneously was multiple Windows on top of each other. But now, each application can have multiple instances running at the same time! Each scene has its own state and it might be in the foreground while others are in the background or are suspended, while Window was completely dependent on the application itself.
Imagine we have 2 view controllers (consider there are no scenes) running on the left and right side of the device and then we need to show a banner. Using the old window method will show the banner on both of them! And if you need to pick one, you may end up finding the correct controller and presenting the banner on it.
So apple introduced Scene, a container for each separate instance of the app. So you can manage each one separately and each of them acts as a separate app. It has its own windows and controllers. But all of them are managed by a single object, UIApplication.shared and it has a delegate to handle general events (usually from outside of the app) and entire application life cycle.
Should my app be updated to Scene Delegate from App Delegate. My app supports ios 13.0 and up
first you have to understand what is difference
You could think of them as the global and private versions. One is shared and the other is limited to the individual owner. In a way, they are exactly what you would expect by the names.
Multi-window support is happening
Next time you create a new Xcode project you’ll see your AppDelegate has split in two: AppDelegate.swift and SceneDelegate.swift. This is a result of the new multi-window support that landed with iPadOS, and effectively splits the work of the app delegate in two.
From iOS 13 onwards, your app delegate should:
Set up any data that you need for the duration of the app.
Respond to any events that focus on the app, such as a file being shared with you.
Register for external services, such as push notifications.
Configure your initial scenes.
In contrast, scene delegates are there to handle one instance of your app’s user interface. So, if the user has created two windows showing your app, you have two scenes, both backed by the same app delegate.
Keep in mind that these scenes are designed to work independently from each other. So, your application no longer moves to the background, but instead individual scenes do – the user might move one to the background while keeping another open.
at last I will say that you can go with Scene Delegate
Courtesy of https://www.hackingwithswift.com/articles/193/whats-new-in-ios-13
The apple developer docs mentions that multiple instances of a scene are available on iOS 13 (ie both iPhone and iPad)
From their developer docs:
In iOS 13 and later, the user can create and manage multiple instances of your app's user interface simultaneously, and switch between them using the app switcher. On iPad, the user can also display multiple instances of your app side by side. Each instance of your UI displays different content, or displays the same content in a different way. For example, the user can display one instance of the Calendar app showing a specific day, and another showing an entire month.
I have tried it on iPadOS and I am able to create multiple scene instances using the gesture and UI actions mentioned in their WWDC videos but I have not found any reference around how to achieve that on iPhone, it would be really helpful to know how to achieve this or whether it is possible or not.
The documentation you quote is misleading due to the use of the term "iOS".
The ability to create multiple scenes for an app in iOS 13 is actually limited to iPads and iPadOS. You can't create more than the one app scene on an iPhone in iOS.
Use UIApplication.sharedApplication.supportsMultipleScenes (Objective-C) / UIApplication.shared.supportsMultipleScenes (Swift) to check if the current device supports multiple scenes. You will find that this return NO/false on iPhones and YES/true on iPads.
That check is useful to enable/disable the ability to use drag and drop that creates an NSUserActivity or UI components that lead to uses of UIApplication requestSceneSessionActivation.
I just wanted to implement the iOS State-Restoration APIs in one of my Apps.
After finally getting it to work, I discovered that a ViewController that I present modally gets restored using an animation, which is not what I want. I would expect my app to just be in the state I left it, but not having the user to see hot he got there.
So I went ahead and downloaded Apple Sample Code on that: https://developer.apple.com/library/ios/samplecode/StateRestore/Introduction/Intro.html and wanted to see if it happens there as well. And it turns out that it does.
Further there is a warning in the Logs:
Unbalanced calls to begin/end appearance transitions for <UINavigationController: 0x7b0512b0>.
Can you tell me if I and obviously Apples Sample Code are doing something wrong, or if it's a bug in iOS?
Btw. I was testing on iOS8
Thanks for any help,
Georg
The following solution comes directly from Apple.
In your app delegate, you should be implementing application:willFinishLaunchingWithOptions: (instead of or in addition to didFinishLaunching). In your implementation, probably as the last line just before returning true (or YES if this is Objective-C), insert this line:
self.window?.makeKeyAndVisible()
Or, if this is Objective-C:
[self.window makeKeyAndVisible];
It turns out that this was always needed, but the documentation has never been clear about it.
From documentation:
Preserving Your App’s Visual Appearance Across Launches
See the 3rd item from the checklist below.
Checklist for Implementing State Preservation and Restoration
Supporting state preservation and restoration requires modifying your app delegate and view controller objects to encode and decode the state information. If your app has any custom views that also have preservable state information, you need to modify those objects too.
When adding state preservation and restoration to your code, use the following list to remind you of the code you need to write.
(Required) Implement the application:shouldSaveApplicationState: and
application:shouldRestoreApplicationState: methods in your app
delegate; see Enabling State Preservation and Restoration in Your
App.
(Required) Assign restoration identifiers to each view controller you
want to preserve by assigning a non empty string to their
restorationIdentifier property; see Marking Your View Controllers for
Preservation.
If you want to save the state of specific views too, assign non empty
strings to their restorationIdentifier properties; see Preserving the
State of Your Views.
(Required) Show your app’s window from the
application:willFinishLaunchingWithOptions: method of your app
delegate. The state restoration machinery needs the window so that it
can restore scroll positions and other relevant bits of your app’s
interface.
Assign restoration classes to the appropriate view controllers. (If
you do not do this, your app delegate is asked to provide the
corresponding view controller at restore time.) See Restoring Your
View Controllers at Launch Time.
(Recommended) Encode and decode the state of your views and view
controllers using the encodeRestorableStateWithCoder: and
decodeRestorableStateWithCoder: methods of those objects; see
Encoding and Decoding Your View Controller’s State.
Encode and decode any version information or additional state
information for your app using the
application:willEncodeRestorableStateWithCoder: and
application:didDecodeRestorableStateWithCoder: methods of your app
delegate; see Preserving Your App’s High-Level State.
Objects that act as data sources for table views and collection views
should implement the UIDataSourceModelAssociation protocol. Although
not required, this protocol helps preserve the selected and visible
items in those types of views. See Implementing Preservation-Friendly
Data Sources.
Apple sample code seems to work fine on Xcode 8.
So I suppose no additional code changes would be required