I've a very strange situation here - call of the method UINAvigationController -> setViewControllers:animated: causes a crash of the app. It's happining only on iOS 10.3.2 and when I'm building the app in release mode.
I've collected more details. Hope they can help to understand what happens.
The issue appears on iOS 10.3.2 and in release mode only. I’ve checked this on iPhone with 10.3.2 and release build fails but debug works OK. Additionally, I’ve checked previous version of the app from AppStore on iOS 10.3.2 and it’s OK too. Debug and release builds work fine on all of the previous versions of iOS.
The previous version in AppStore was built with older version of Xcode, and now I'm using latest Xcode 8.3.2. I suppose it's system issue, which is related to iOS and Xcode versions.
Regarding sources, it looks like:
AppDelegate.swift
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
...
window = UIWindow(frame: UIScreen.main.bounds)
....
let navigationController = UINavigationController(rootViewController: viewController)
window.rootViewController = navigationController
window.makeKeyAndVisible()
}
ViewController.swift
override func viewDidLoad() {
super.viewDidLoad()
...
continueButton.addTarget(self, action: #selector(navigateForward), for: .touchUpInside)
...
}
func navigateForward(sender: UIButton!) {
let nextController = FinalBuilder.viewController()
navigationController?.setViewControllers([nextController], animated: true)
}
I said before, it works fine in all cases except one :). UINAvigationController -> setViewControllers:animated: is standard iOS method, available from iOS 3.0+ and not deprecated now. There are no hacks or something else what can corrupt the program flow. And it’s usual way to use it.
P.S. There is no debug log or any other message which I can provide you because the app just disappears from the screen with no notification at all.
if its not work , so you can try easy way like
simple creat view controller object and pass in navigation
let nextVC = storyboard?.instantiateViewController(withIdentifier:"ScrollViewController") as! ScrollViewController
self.navigationController?.pushViewController(nextVC, animated: true)
I've found that this behavior appeared after update of RxCocoa from 3.3.1 to 3.4.0. It happens because of the following change in DelegateProxyType.swift : extension ObservableType : func subscribeProxyDataSource:
return Disposables.create { [weak object] in
subscription.dispose()
- unregisterDelegate.dispose()
object?.layoutIfNeeded()
+ unregisterDelegate.dispose()
}
I've posted report to ReactiveX/RxSwift repository. You can check final state there, if you are interested.
Related
In iOS12 and below I used to use something similar to this to show a window on top of everything to cover my app contents. This use to work but in iOS13 betas this does not work anymore.
class AppDelegate: UIResponder, UIApplicationDelegate {
var window: UIWindow?
var coverWindow: UIWindow?
func applicationDidEnterBackground(_ application: UIApplication) {
if self.coverWindow != nil {
// Skip since cover window is already showing
return
}
let vc = UIViewController()
let label = UILabel(frame: window!.bounds)
label.text = "CoverWindow. Tap to app see contents"
vc.view = label
vc.view.backgroundColor = UIColor.lightGray
let coverWindow = UIWindow(frame: window!.bounds)
coverWindow.rootViewController = vc
coverWindow.windowLevel = .alert
coverWindow.makeKeyAndVisible()
self.coverWindow = coverWindow
}
}
Apparently window changes are not reflected in screen until app enters foreground again.
Question
Does anyone know how fix or workaround this? or maybe this approach is incorrect?
Any help would be highly appreciated
Notes
I don't use a simple view because my app might be showing other windows too and my requirement is to cover everything.
I don't use applicationWillResignActive because we want to only show coverWindow when it enters background. (TouchID authentication and other stuff might trigger applicationWillResignActive and coverWindow would incorrectly show)
Example code
Download Full working example code in Github (Run in iOS simulator 12 and 13 to see the difference)
You have to implement application life cycle, you just delete it , add those app life cycle functions and implement your codes , it ll be run without error
Answer to myself.
I reported this to Apple and it was fixed in iOS 13.1 or so. Latest version of iOS13 does NOT have this bug :)
My app has the following flow if the user is logged in
Loading Screen -----> Main Screen -----> Rest of App
and the following flow if he's not :
Loading Screen -----> Login Screen -----> Main Screen -----> Rest of App
Now I am implementing the Logout feature. I have added the following code into main Screen :
func handleLogout() {
if self.presentingViewController != nil {
var vc = self.presentingViewController
while ((vc!.presentingViewController) != nil) {
vc = vc!.presentingViewController
}
vc?.dismissViewControllerAnimated(true, completion: {
})
}
}
This works fine if the 1st path is followed (the user was logged in when the app was launched) as the app returns to the Loading Screen and then loads up the Login Screen as expected. However, if the 2nd path was followed (the user was not logged in when the app was launched, and Login Screen has been used) this code leads to the Login Screen being opened directly and the whole logout process failing. Is there a way I can ensure that the Loading Screen is the one which is always loaded by this code regardless of which of the two paths have been followed.
Use unwind segues!
You basically add an unwind segue connecting your "main screen" and "login screen". Give it an identifier and you can initiate the segue whenever you want. In handleLogout:
func handleLogout() {
self.performSegueWithIdentifier("your identifier", sender: self)
}
For details of how to create an unwind segue: https://www.andrewcbancroft.com/2015/12/18/working-with-unwind-segues-programmatically-in-swift/
This is just a suggestion here goes:
In AppDelegate file you can do something similar to this:
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
//Implement this method
let userLoggedIn = isUserLoggedIn();
if !userLoggedIn {
let storyboard = UIStoryboard(name: "Main", bundle: NSBundle.mainBundle())
//Instantiate the login view controller
window?.rootViewController = storyboard.instantiateViewControllerWithIdentifier("login")
window?.makeKeyAndVisible()
}
return true
}
Now when the app starts it'll first check the user's login state and display the appropriate view.
Note: this is assuming you use storyboards and the root view controller is set to the Main Screen
If you are using Storyboards, I would suggest creating storyboard that is used purely for your login view/s. Then in the AppDelegate DidFinishLoading method, you can show the login storyboard if they need to login or show the main storyboard if they are already logged in. You can swap out storyboards at anytime and its easy to do. That will help simplify the flow a bit. This is what I usually do in my apps. If you need sample code just let me know.
Since Xcode 7 we have a nice API for UI testing.
Mostly I'm satisfied with it. The only concern is related to the speed.
In the beginning an ordinary UI test case (about 15 actions) ran approximately 25 seconds. Then I mocked networking completely. Now it takes 20 seconds. Considering the fact that the time is taken only by animations and a launch time (1 second or even less), I assume, there must be a way to speed it up.
Try setting this property when your UI tests run:
UIApplication.shared.keyWindow?.layer.speed = 100
Here's how I set it:
func application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
if ProcessInfo.processInfo.arguments.contains("UITests") {
UIApplication.shared.keyWindow?.layer.speed = 100
}
}
And in my UI tests:
class MyAppUITests: XCTestCase {
// MARK: - SetUp / TearDown
override func setUp() {
super.setUp()
let app = XCUIApplication()
app.launchArguments = ["UITests"]
app.launch()
}
}
There's a few more handy tips in this blog post.
Another possibility is to disable animations at all:
[UIView setAnimationsEnabled:NO];
Swift 3:
UIView.setAnimationsEnabled(false)
Following #Mark answer, the Swift 3 version:
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
if ProcessInfo.processInfo.arguments.contains("UITests") {
UIApplication.shared.keyWindow?.layer.speed = 200
}
}
On you ui test file:
override func setUp() {
super.setUp()
// Put setup code here. This method is called before the invocation of each test method in the class.
let app = XCUIApplication()
app.launchArguments = ["UITests"]
app.launch()
Add it in didFinishLaunch
[UIApplication sharedApplication].keyWindow.layer.speed = 2;
The default value is 1, make it 2 to double its speed.
Run them in parallel.
EDIT: This may be outdated since my original answer in 2019, since Xcode allows now testing on multiple simulators within one machine:
If you have only 1 build machine, you can use Bluepill: https://github.com/linkedin/bluepill
EDIT: However, I don't use either of these (bluepill / Xcode), so I'll keep mention of the bluepill in this answer, maybe it has some uses.
If you have multiple machines, you can use Emcee: https://github.com/avito-tech/Emcee (it also works for a single machine setup)
We have 50 hours of UI tests, and Emcee allows us to run them in 1 hour. There are several tricks to make UI tests faster, but it is pointless if you are not running them in parallel. E.g. you can't make your 25 seconds tests run in 0.5 second.
Tricks:
Run XCUIApplication without reinstalling it:
XCUIApplication(
privateWithPath: nil,
bundleID: "your.bundle.id"
)
Note: you should launch app with XCUIApplication().launch() at least once per launching XCUI test runner to install the app. This requires usage of private API.
You can move something to background thread. E.g.
let someDataFromApi = getSomeData() // start request asynchronously and immediately return
launchApp() // this can be few seconds
useInTest(someDataFromApi) // access to data will wait request to finish
You can make the code look like there is no asynchronous things, it would be easier for QA. We want to implement this, but we didn't, so it is just an idea.
Switch to EarlGrey and make tests that lasts few seconds (but they will not be black box).
Open screens via deep links if you have deep links.
Use a lot of private API and other hacks. E.g.: instead of going via UI to Settings app and then reset privacy settings you can call some private API.
Never use long sleeps. Use polling.
Speed up animations. Do not disable them! (we use layer.speed = 100 on every view and we got severe problems with the value of 10000, full code: https://pastebin.com/AnsZmzuQ)
Pass some flags from UI tests to app to skip initial alerts/tutorials/popups. Can save a lot of time. Be sure to have at least 1 test that checks that those alerts work.
Advertisement: most of these is implemented in https://github.com/avito-tech/Mixbox. Disclaimer: I'm the main contributor in this test framework. Its tedious to set up, but at least you can reuse some code if you don't want to reuse whole framework.
I wanted to disable ALL animations during Snapshot testing. I was able to able to achieve this by disabling both Core Animation and UIView animations as below.
Note because my app used storyboards UIApplication.shared.keyWindow was nil at launch so I access the UIWindow by referring to the window property directly.
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
if ProcessInfo.processInfo.arguments.contains("SnapshotTests") {
// Disable Core Animations
window?.layer.speed = 0
// Disable UIView animations
UIView.setAnimationsEnabled(false)
}
return true
}
I decrease my UITests time in 30%, follow all steps:
When you run your app, add the argument:
let app = XCUIApplication()
override func setUp() {
super.setUp()
continueAfterFailure = false
app.launchArguments += ["--Reset"]
app.launch()
}
Now, in your AppDelegate add:
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
setStateForUITesting()
}
static var isUITestingEnabled: Bool {
get {
return ProcessInfo.processInfo.arguments.contains("--Reset")
}
}
private func setStateForUITesting() {
if AppDelegate.isUITestingEnabled {
// If you need reset your app to clear state
UserDefaults.standard.removePersistentDomain(forName: Bundle.main.bundleIdentifier!)
// To speed up your tests
UIApplication.shared.keyWindow?.layer.speed = 2
UIView.setAnimationsEnabled(false)
}
}
In your code, to verify if is in test mode, you can use:
if AppDelegate.isUITestingEnabled {
print("Test Mode")
}
Additionally, to can wait while the element load I created this extension:
import XCTest
extension XCUIElement {
func tap(wait: Int, test: XCTestCase) {
if !isHittable {
test.expectation(for: NSPredicate(format: "hittable == true"), evaluatedWith: self, handler: nil);
test.waitForExpectations(timeout: TimeInterval(wait), handler: nil)
}
tap()
}
}
Use like this:
app.buttons["start"].tap(wait: 20, test: self)
Note that keyWindow is deprecated as of iOS 13. Specifically,
UIApplication.sharedApplication.keyWindow and self.window.keyWindow within the AppDelegate both return nil. This answer says to loop through UIApplication.shared.windows and find the one with isKeyWindow true, but in my test using ios14, even that return false for my only window. In the end, setting self.window.layer.speed worked for me.
When launch an app, the LaunchScreen.xib is removed as soon as all the assets are initialized.
I want to make the launch screen stay for at least 1 sec.
Is there a way to achieve this?
Thank you!
You can create a view controller that uses the LaunchScreen storyboard, present it (not animated) on applicationDidFinishLaunching or applicationWillFinishLaunching, and dismiss it whenever you want.
Keep in mind this is discouraged by Apple because it gives the impression that your app takes a lot longer to launch, which is bad user experience and might cause some of your users to delete your app.
Swift 4 Update
Just write one line of code
Thread.sleep(forTimeInterval: 3.0)
in the method of didfinishLauching.... in appdelegate class.
Example
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
Thread.sleep(forTimeInterval: 3.0)
// Override point for customization after application launch.
return true
}
Never sleep on the main thread. Doing this could actually cause iOS to kill your app for taking too long to start up
Thought I chip in my thoughts on this, I wanted to write in comments but it won't allow many lines. I believe many apps developer want to do this (delay the launch screen) is because they want to build a brand presence of the apps/games for their company.
Having said that, launch screen is NOT designed for that, as Rick Maddy explained in the comment section in one of the other answers. Launch screen's purpose is to make users feel the app is instantly running by showing the empty UI while the actual data is loading at the back (willAppear and so on).
So to achieve what many developers want, while being in-line with Apple's HIG, what you can do is:
Display UI template in the launchscreen as intended by Apple HIG.
Upon main screen load, load up another VC that shows "intro" of your brand. Make sure this runs only ONCE (a simple flag in
NSUserDefaults should do the trick).
Users should be allowed to skip this if it is a long "intro".
The same "intro" VC should be available to user by tapping on a "View Intro" button somewhere (maybe in about page).
If you want to go with simple, you can use NSThread:
[NSThread sleepForTimeInterval:(NSTimeInterval)];
You can put this code into the first line of applicationDidFinishLaunching method.
For example, display default.png for 1.0 seconds.
- (void) applicationDidFinishLaunching:(UIApplication*)application
{
[NSThread sleepForTimeInterval:1.0];
}
It will stop splash screen for 1.0 seconds.
Alhamdulellah Solution is find
Only copy and paste this code in AppDelegate Class
Call this SplashScreenTiming() in didFinishLaunchingWithOptions()
private func SplashScreenTiming(){
let LunchScreenVC = UIStoryboard.init(name: "LaunchScreen", bundle: nil)
let rootVc = LunchScreenVC.instantiateViewController(withIdentifier: "splashController")
self.window?.rootViewController = rootVc
self.window?.makeKeyAndVisible()
Timer.scheduledTimer(timeInterval: 5, target: self, selector: #selector(DismissSpalshController), userInfo: nil, repeats: false)
}
#objc func DismissSpalshController(){
let mainVC = UIStoryboard.init(name: "Main", bundle: nil)
let rootvc = mainVC.instantiateViewController(withIdentifier: "SignInVC")
self.window?.rootViewController = rootvc
self.window?.makeKeyAndVisible()
}
I am trying to make a collapsible slide out menu bar from scratch. I decided to try a UISplitViewController(). When I use an iPad simulator, I get a collapsible menu on the right side like desired. However, when I try it on my iPhone 6, the master view and detail view are shown on totally different screens instead of partially overlapping each other until a decision is made. Is it possible to get a split screen overlap when viewed on both the smaller devices (iPhone 5/6) and bigger devices?
The posted UISplitViewController is below:
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
// Override point for customization after application launch.
window = UIWindow(frame: UIScreen.mainScreen().bounds)
let splitVC = UISplitViewController()
window?.rootViewController = splitVC
print(splitVC.collapsed)
var nav1 = UINavigationController(rootViewController: MasterViewControllerTableViewController())
var nav2 = UINavigationController(rootViewController: ViewController())
splitVC.viewControllers = [nav1, nav2]
splitVC.preferredDisplayMode = .PrimaryOverlay // this does not help?
window?.makeKeyAndVisible()
return true
}
I have built one from scratch but I would advise just using one of the pre-existing libraries. https://www.cocoacontrols.com/ is a good place to check. In the filter above select Sort: rating, Platform: iOS. You can even run the code online to test it. Most of the code for this controls is hosted on github.
If you do decide to build one there are plenty of tutorials if you google for “swift build slide out menu”. The code you have does a small subset of what you’ll need so there’s no simple “add this” or “change that” to get it to work.