Posts

Post not yet marked as solved
2 Replies
I have filed FB7346540 suggesting that the CMS APIs and certain additional security APIs that are all already available on macOS be made available to macOS Catalyst apps. Because the Mac App Store distribution mechanism does not provide a full copy protection mechanim, iOS apps that had no need for these APIs on iOS will have to implement their own solution for copy protection on macOS Catalyst. This problem is much easier to solve on macOS because the APIs are already there - just not available. The macOS security APIs can be reached through a separate plugin bundle compiled for macOS, but a plugin implementation is considerably less secure. It would be much better to make the security APIs directly available to the macOS Catalyst app so that receipt validation could be implemented as part of the code in the main bundle.Barry
Post not yet marked as solved
5 Replies
In Catalyst builds with Xcode GM seed running on Catalina beta 8, dynamic system colors .label, .systemBackground and .secondarySystemBackground that are set in Storyboard do not adapt to dark mode. They should, but they don't. They do adapt properly to dark mode on iOS, but not on Catalina beta 8 through Catalyst. A workaround is to have an outlet for every label, text field and background view, and to explicitly set the text color and background color in code. Though this is tedious, it works and has no negative impact on the iOS build other than code bloat.Be aware that in the Catalyst build, an iOS dynamic color is mapped into an "Equivalent macOS color" as described in the Human Interface Guidelines section on iOS Apps for Mac. But equivalent does not mean the same, and the description of how that mapping is done is not entirely clear or complete. The combination of apparently broken behaviors (dynamic colors not set propertly from Storyboard) and apparently intentional changes in color through this mapping from iOS colors to macOS colors, makes it hard to get proper dark mode behavior on macOS through Catalyst.
Post not yet marked as solved
12 Replies
It now appears to be fixed - working correctly when tested with Xcode 11 beta 5 and macOS Catalina beta 5.
Post not yet marked as solved
12 Replies
I see exactly the same behavior. On Xcode 11 beta 4 and Catalina beta 4, an iOS WKWebView that renders correctly running on the iOS 13 simulator renders blank when running on macOS Catalina built via Catlyst. This happens both when the original HTML content is in a file that is part of the app bundle or when the HTML is passed directly to the WKWebView as a string. On macOS when the content is in a file I have verified that the file is accessible and the contents can be loaded as a string. I also tried it with the simplest possible single view example and the behavior is the same.I think that this is a problem with the macOS/Catalyst implementation of the iOS WKWebView. I filed Feedback on it.