Post

Replies

Boosts

Views

Activity

Reply to Simulator fails to import data - Xcode 11.2.1 on Catalina 10.15.1
I have the same problem too.It seems that on Catalina it is no longer possible to transfer files from the Finder to the simulator.For me it's a big problem because I often have to send documents to the simulator to test the open procedure of some of my apps.Before Catalina when you dragged a file on the simulator the respective app was opened, the file was copied to the Inbox folder and the UIApplicationDelegate method application(_:open:options:) was called.Unfortunately on Catalina the file is no longer copied to the Inbox folder and therefore the url parameter of the application(_:open:options:) method is pointing to a non existing file.It must be a bug because also Apple apps react badly (for example Photos as reported by sincerus).I hope the problem will be fixed soon.In the meantime, does anyone know another way to send files from the Finder to the simulator?
Dec ’19
Reply to UIAlertController disappearing since iOS 13
I tested on iOS 13.4.1 (on device and simulator) and it still work correctly for me.By the way, keep in mind that what Macho Man ***** Savage said is correct. The right way to do it is to subclass UIAlertController because we shouldn't override inside extensions.You can try this code:class GlobalAlertController: UIAlertController { var globalPresentationWindow: UIWindow? func presentGlobally(animated: Bool, completion: (() -> Void)?) { globalPresentationWindow = UIWindow(frame: UIScreen.main.bounds) globalPresentationWindow?.rootViewController = LightStatusBarController() globalPresentationWindow?.windowLevel = UIWindow.Level.alert + 1 globalPresentationWindow?.backgroundColor = .clear globalPresentationWindow?.makeKeyAndVisible() globalPresentationWindow?.rootViewController?.present(self, animated: animated, completion: completion) } override func viewDidDisappear(_ animated: Bool) { super.viewDidDisappear(animated) globalPresentationWindow?.isHidden = true globalPresentationWindow = nil } }
Apr ’20
Reply to Using classic style of UISplitViewController in Xcode 12
Yes, that's a big problem! My app use some split view controllers and they worked properly on Xcode 12 beta 2. Now on Xcode 12 beta 3 the split view controllers has stopped calling some of its delegate methods. For example on Xcode beta 2 the delegate method collapseSecondaryOntoPrimaryViewController was correctly called when needed.  On Xcode beta 3 this method is not called and this message is printed on the output: [UISplitViewController] Skipping delegate calllback, splitViewController:collapseSecondaryViewController:ontoPrimaryViewController:. Unsupported for UISplitViewController style DoubleColumn The problem seems to be that now Interface Builder is forcing my split view controllers to have a style of "Two Columns" but if we need to support older version of iOS we need to be able to set the style to "unspecified". Unfortunately I cannot create the split view controllers programmatically because they are part of a big and complicated storyboard. I tried to override the style property of UISplitViewController in this way: @available(iOS 14.0, *) override var style: UISplitViewController.Style { return .unspecified } but without success. Someone has figured out a way to set the split view controllers style to "unspecified" in the storyboards? Thank you
Aug ’20
Reply to UISplitViewController embedded in UITabBarController behaves strange in iOS 14
I also have big problems with split view controllers inside tab bar controllers in Xcode 12 beta 3. Everything was perfect in Xcode 12 beta 2. Now Interface Builder itself crash constantly when opening a storyboard that contain a split view controller that is inside a tab bar controller. This is the error displayed by Xcode: An internal error occurred. Editing functionality may be limited. If I generated the log of this error I get this: Exception name: NSInvalidArgumentException Exception reason: UITabBarController is unsupported as viewController for -[UISplitViewController setViewController:forColumn:] in Primary column I'm think that it has to do with the fact that from Xcode beta 3 the split view controllers inside storyboards are automatically instantiated with the new column system introduced in iOS 14 instead of the classic system. We really need a way to indicate in the storyboard that we want to use the classic system and not the new one.
Aug ’20
Reply to UISplitViewController: Skipping delegate calllback
It seems the problem is that when you add a UISplitViewController inside a storyboard in Xcode 12 beta 3 the controller is instantiated with the new "Two Columns" style instead of the classic old style. Unfortunately at the moment there seems to be no way to set the style to classic directly from the storyboard. A temporary fix is to manually instantiate the UISplitViewController without using the new init(style:) initialiser. If you use the old init() initialiser the style of the controller will be "unspecified" and it will behave in the classic way. If your split view controller is the root controller of your storyboard you can set it to classic mode in this way: func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { 		... 		 		if #available(iOS 14.0, *) { 				if let oldSVC = self.window?.rootViewController as? UISplitViewController { 						/* If you instantiate an UISplitViewController in this way the style will be undefined (classic). */ 						let newSVC = UISplitViewController() 						newSVC.viewControllers = oldSVC.viewControllers 						/* Here you can align other properties if needed. */ 						 						self.window?.rootViewController = newSVC 				} 		} 		... } Hope this helps. Let's hope that in one of the next Xcode 12 betas it will be possible to set the split view controllers style to "unspecified" (classic mode) directly from the storyboard.
Aug ’20
Reply to Using classic style of UISplitViewController in Xcode 12
My temporary fix is, as Mr. Brightside suggested, to manually instantiate the split view controller and replace the storyboard controller with the new one. If you use the old init() initialiser the style of the controller will be "unspecified" and it will behave in the classic way. If your split view controller is the root controller of your storyboard you can set it to classic mode in this way: func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { 		... 		 		if #available(iOS 14.0, *) { 				if let oldSVC = self.window?.rootViewController as? UISplitViewController { 						/* Instantiate an UISplitViewController with the unspecified style (classic mode). */ 						let newSVC = UISplitViewController() 						newSVC.viewControllers = oldSVC.viewControllers 						/* Here you can align other properties if needed. */ 						 						self.window?.rootViewController = newSVC 				} 		} 		... } Hope this helps. Let's hope that in one of the next Xcode 12 betas it will be possible to set the split view controllers style to "unspecified" (classic mode) directly from the storyboard.
Aug ’20
Reply to UITabBarController is unsupported as viewController
Hi, For the moment I edit my storyboards with Xcode 11. On runtime I have no problems because I programmatically changed the style of my split view controllers to classic (the behaviour before iOS 14). In this way you can still embed split view controllers inside tab bar controllers as you always did. Ideally we should be able to set the classic behaviour directly from storyboard. Fortunately I see in the release notes of Xcode 12 beta 4 that apple has reported this point as "Known Issues" and therefore I expect that it will be solved in one of the next beta. From Xcode 12 beta 4 release notes: "Interface Builder doesn’t allow creating a classic style UISplitViewController. (65966010) (FB8107534)"
Aug ’20