I wanted to post this here in the hope that this will draw attention to what I think is a serious change in behavior that could negatively affect Catalyst apps in macOS 14.4.
Prior to macOS 14.4, when the completion handler was invoked from calling dismiss() to dismiss a presented view controller in a Catalyst app, the dismissed controller no longer appeared in the chain. That is to say that if the root view controller presents View Controller A, when View Controller A is dismissed, the root view controller's presentedViewController property is nil when the completion handler for dismiss() is called.
With macOS 14.4, this is no longer the case. If the root view controller presents View Controller A and then View Controller A is dismissed, the presentedViewController property of the root view controller still refers to Controller A when dismiss()'s completion handler is called.
The side effect of this change in behavior means that if you try to present another view controller from the completion handler of the one being dismissed, it will fail to show because the top most view controller in the chain is the controller being dismissed and presenting from it will result in nothing showing up because it is removed from the chain immediately after the completion handler is invoked. Before macOS 14.4, it the top of the chain would have been the controller that presented the controller that was dismissed, which is what you actually want.
This problem does not exist in the betas for iOS 17.4 or iPadOS 17.4. It appears to affect only Catalyst apps running under macOS 1.4.4.
I think this change in behavior has the potential to affect a number existing Catalyst apps and it may not be obvious to the user something is going wrong. It really should be fixed before macOS 14.4 is released to the public.
I've created a feedback with a sample Xcode project that demonstrates the problem (feedback number FB13622757).
I have been struggling with a crash bug that begin popping up in iPadOS 17 when we moved our app over to building under Xcode 15. It is important to note that the prior release, built under Xcode 14 works fine. Also, the crash does not occur in versions of iPadOS prior to iPadOS 17, even when built under Xcode 15.
The main view controller is a UISplitView that has primary, secondary, and supplemental views. Each, hosted in a UINavigationController. The primary view has the navigation bar hidden (this is important).
If the supplemental view has an additional view controller pushed onto the navigation stack, hence a back button is being shown in the middle navigation controller, and the app is transitioned to a compact size class (secondary controller shown at the top of the stack) and then transitions back to a regular size class, we get a crash with the following:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Layout requested for visible navigation bar, <UINavigationBar: 0x1038e3a40; frame = (0 -102; 834 102); opaque = NO; autoresize = W; gestureRecognizers = <NSArray: 0x600000d586f0>; layer = <CALayer: 0x6000003690e0>> delegate=0x105809800 standardAppearance=0x600002662940 scrollEdgeAppearance=0x600002661620, when the top item belongs to a different navigation bar. topItem = <UINavigationItem: 0x103b2bb10> titleView=0x1039b1a70 style=navigator rightBarButtonItems=0x6000000427e0 largeTitleDisplayMode=never searchController=0x1068c1a00 preferredSearchBarPlacement=stacked, navigation bar = <UINavigationBar: 0x103b452c0; frame = (0 24; 834 102); opaque = NO; autoresize = W; gestureRecognizers = <NSArray: 0x600000cd7d20>; layer = <CALayer: 0x600000316700>> delegate=0x104898400 standardAppearance=0x60000265ea00 scrollEdgeAppearance=0x60000265fd80, possibly from a client attempt to nest wrapped navigation controllers.'
*** First throw call stack:
(
0 CoreFoundation 0x0000000180491128 __exceptionPreprocess + 172
1 libobjc.A.dylib 0x000000018008412c objc_exception_throw + 56
2 Foundation 0x0000000180d1163c _userInfoForFileAndLine + 0
3 UIKitCore 0x00000001848d2510 -[UINavigationBar layoutSubviews] + 472
4 UIKitCore 0x0000000185806d78 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1492
5 UIKitCore 0x00000001848d21d8 -[UINavigationBar layoutSublayersOfLayer:] + 188
6 QuartzCore 0x0000000189ffa5b0 _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 440
7 UIKitCore 0x00000001857f6260 -[UIView(Hierarchy) layoutBelowIfNeeded] + 292
8 UIKitCore 0x0000000184b147f8 -[UINavigationController _positionNavigationBarHidden:edge:initialOffset:] + 584
9 UIKitCore 0x0000000184b149b0 -[UINavigationController _positionNavigationBarHidden:edge:] + 264
10 UIKitCore 0x0000000184b163dc __64-[UINavigationController _setNavigationBarHidden:edge:duration:]_block_invoke + 404
11 UIKitCore 0x0000000184b1603c -[UINavigationController _setNavigationBarHidden:edge:duration:] + 488
12 UIKitCore 0x0000000184b14518 -[UINavigationController setNavigationBarHidden:animated:] + 92
However, if we do not hide the navigation bar in the primary view: no crash. Likewise, if there isn't a second controller pushed onto the navigation stack (meaning no back button is shown), there is no crash, even if the navigation bar is hidden in the primary view.
This structure has been fine for over three years and the problem only began with iPadOS 17 building under Xcode 15.
I have found similar mentions on other forums, but no real solution.
I realize I should probably file a feedback. Unfortunately, past experience has shown that it is a good way to waste countless hours gathering information, creating sample projects that distill the bugs down to their core, only to be met with complete and utter silence. I've lost all confidence in that system and I'm hoping someone else who has run into this may have a workaround or at least some suggestions for things to try.
Post not yet marked as solved
Is anyone else running into an issue with navigation bar titles in Catalyst app being shown higher up than normal when presented as a modal sheet under Sonoma (see screenshot)?
I tried adjusting the titlePositionAdjustment for the appearance, but this only affects the title and not any buttons that may be in the navigation bar, making them uneven.
Any suggestions would be helpful as I'm at my wits end on this one.
Post not yet marked as solved
Prior to macOS 14, a Catalyst app could present a UIAlertController as a popover, just as you can on the iPad. While this still works on the iPad, the presentation on macOS now uses the same style as the iPhone.
The UIAlertController's popoverPresentationController property is always nil, no matter how it is configured.
Doe anyone know of a way to restore the prior behavior under Sonoma?
Post not yet marked as solved
I've run into a problem that has been giving me fits for a while and have yet to be able to find a solution. We have a Catalyst app that uses a three-pane UISplitView. The middle and third panes show the navigation bar of the UINavigationController hosted in each pane.
However, when building under Xcode 15, the navigation bar is not shown in the middle pane when running under macOS 14. It is shown, as expected, when the app is run under prior versions of macOS. It also appears as it should under macOS 14 if the app is built with Xcode 14.
If you push another view controller onto the navigation controller's stack with the animate flag set to true, the navigation bar will appear. When you go back to the root controller, the navigation bar is present as it should be. However, if you push the controller with the animate flag set to false, the navigation bar does not appear.
I've been able to reproduce this in an isolated test app with just the relevant components. The first screenshot at the end is from a test app that illustrates the problem. The second screenshot shows what it should look like (and does look like under macOS 13).
It should be noted that UINavigationBar.appearance().preferredBehavioralStyle = .pad is set.
If any Apple folk would kindly like to look into this, I created a feedback for it: FB13260893. The feedback entry has a sample app, screenshots, and even a screen recording demonstrating the problem.
Has anyone else run into this or does anyone have any suggestions for a fix/workaround?
Thanks,
Kevin
I need to implement ZIP file and directory compression without using any third party libraries and Apple Archive looks like it would do the trick. Unfortunately, whenever I try to make use of it (yes, I did import it), I get out of scope errors.
The Swift import headers are all essentially empty in the Xcode 12.2 beta. The Objective C headers exist, though.
Before I put any more time into this, does anyone know if/when Apple Archive will be implemented as documented? Has it been pulled from the SDK but the documentation not updated? I'm a little worried about trying to use the Objective C variant because I cannot find anything on the status of the framework in general.
Thanks,
Kevin
While I understand that the amount of storage available to private CloudKit databases is whatever the user pays for, I am confused as to whether the data transfer and requests per second limits that affect public databases are also in place for private databases.We are in the process of adding CloudKit support to one of our apps where the average size of the local data store is around 300 MB and can easily cross into the multi-gigabyte range. If a similar data transfer limit with an average 50 MB per user per month is in effect, then we could easily run into to trouble with CloudKit. Does anyone know if there is a data transfer limit for private databases with CloudKit? If so, is it the same as the public database limitation or is it something else?Regards
Post not yet marked as solved
I'm running into a bit of an issue with a menu attached to a UIButton in a Catalyst app. Clicking on the button works as expected: the menu appears (showsMenuAsPrimaryAction is set to true).
However, because the button is in a form as a way for the user to select from a list of available options, I also need the ability to show the dropdown menu when I tab to the button from another field. I was hoping this would happen automatically if the button could become the first responder, but that does not appear to be the case. If there a way to make this happen?
I've been trying to upload a preview video for a Mac app to App Store Connect for two days now and am running into a problem when I try to save the app listing.The video uploads fine, from either the app's version page and when going through the Media Manager. I can play the video back and even set the poster frame. However, if I try to save the listing in the Media Manager, the video simply disappears. No error. No nothing. If I upload the video from the app version page, again everything seems fine, but when I try to save the listing, App Store Connect returns an error saying the video is in the incorrect format. However, it does not tell me what it doesn't like (encoding, audio format, length, what?).The video was created in Final Cut Pro X and exported at 30fps, 1920 x 1080 (progressive). The MOV file is encoded in H.264 with 44.1k AAC stereo audio. The preview video is exactly 30 seconds long. I've tried shortening it, using 48k audio, and just about everything else I can think of, but no luck. I was unable to try Apple Pro Res 422 HQ because the size is above Apple's 500 MB limit.I've uploaded a number of preview videos in the past and I seem to recall that format errors were flagged on upload and not save. I certainly don't remember being able to play the vdeo back in App Store Connect and set the poster frame if there were any format issues. Could be wrong, though.Any ideas as to how to fix this are most welcome.
Enderlyn.