MacOS 13.1 released and the bug is still present. Surely of 160 members that have read this post someone must have some feedback on this? I really would appreciate it. Thanks

An update I have now even put a check on the code below to try to get around the issue Xcode 14.1(14B7) and I am still getting a crash on Catalina MacCatalyst 13 with the error Termination Reason:    DYLD, [0x4] Symbol missing Application Specific Information: dyld: launch, loading dependent libraries Dyld Error Message: Symbol not found: OBJC_CLASS$_UIMarkupTextPrintFormatter    @available(iOS 14, macCatalyst 14, *)         func printNote() {             let printInfo = UIPrintInfo(dictionary: nil)             printInfo.jobName = noteTitle             printInfo.outputType = .general             printInfo.orientation = .portrait             let formatter = UIMarkupTextPrintFormatter(markupText: htmlForSharing) .... Has anyone else seen this behaviour

Same for me here. Does this mean if I archive the app and release to Apple it won't run on a device with iPAdOS 15.7 - the latest Version?

Hi Did you ever get to the bottom of this? I am just about to release an upgrade to a catalyst+iOS app and I am running with the idea that the the CFBundleVersion is the value to use for both Catalyst and iOS. Can you confirm?

I am having the exact same issue with a macCatalyst app. ITMS-90338: Non-public API usage - The app contains or inherits from non-public classes in UIPrintInfo, UIPrintInteractionController, UIPrintPageRenderer. I have not changed the code in 6 months.

Claude Here is the code fragment that defines the menu; ` if #available (macCatalyst 14 , iOS 14,  *) {                     let items = UIMenu(title: "", options: .displayInline, children: [                 UIAction(title: helpString, image: UIImage(systemName: "questionmark.circle"), handler: { _ in                     guard let url = URL(string: "https://springnotes.app/help/") else {                         return                     }                     if UIApplication.shared.canOpenURL(url) {                         UIApplication.shared.open(url, options: [:], completionHandler: nil)                     }                 }),                 UIAction(title: outlineString, image: UIImage(systemName: "circle.grid.2x2"), handler: {[unowned self]  _ in self.navigatePopUp(sender: moreButton) }),                 UIAction(title: settingsString, image: UIImage(systemName: "slider.horizontal.3"), handler: {[unowned self]  _ in self.settingsPopUp(sender: moreButton) })             ]) `

Claude I forgot to mention that the mouse and trackpad settings are normal and that my device behave as expected in other apps while scrolling including an earlier version of my own app. to debug this I added another target to the scrolls views default panGestureRecognizer  self.panGestureRecognizer.addTarget(self, action: #selector(handleScrollGesture(_:))) and print out all received dated to the console like this ; @objc func handleScrollGesture(_ recognizer: UIGestureRecognizer) {                  guard recognizer.view != nil else { return }         switch recognizer.state {         case .possible : print("Scroll possible")         case .began : print("Scroll began")                 case .recognized : print("Scroll recognized")         case .changed : print("Scroll changed")         case .cancelled: print("Scroll Cancelled")         case .failed : print("Scroll failed")         default : print("unknown state")         }     }      and when the second flick to reverse the scroll is successful it fires as per normal but when it does not nothing is printed to the console.

Thanks for your reply Claude. I have not overridden any touches methods and am using on an iPad Pro with magic keyboard attached. My issue is that the scroll view ignores a second swipe while decelerating as there are no controls on the view my only intention is to scroll. If you browse using safari on iPad and scroll content up and while decelerating quickly flick back down the direction is reversed - that is what my app used to do and now does not. My only clue is that perhaps I am doing something on the main thread - perhaps in my custom layout manager that interferes with the timer - but to test this I disabled all this drawing code and the problem is still present.

I have good news - It seems that this bug has been fixed in OSX 11 Now working as expected