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

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

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 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

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?

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.

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.

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'm running into a change in behavior with the title bar when building our Catalyst app under Xcode 16 versus what we are seeing with the same code built under Xcode 15. The title bar is hidden, as it should be in the Xcode 15 build. However, when building the same project under Xcode 16, the title bar is shown with the center contents of the navigation bar in the right pane being duplicated in the title bar (see screenshot at the end), which is undesirable. The screenshots for both builds were taken in macOS Sequoia Beta Seed 1. The Catalyst Interface setting is configured to "Optimize for Mac" in the project file. The scene's titlebar.titleVisibility property is set to .hidden, titlebar.toolbar is set to nil. UINavigationBar's appearance is configured with a preferredBehaviorStyle of .pad when running under Catalyst 16 or later. Is this a bug or am I missing a flag or something that was introduced to Catalyst/UIKit that I've overlooked? I've also filed a feedback for this issue: FB14000006. Thank you for your time.

I am running into an issue with UITabBarController in a Catalyst app when building under Xcode 16 and running on macOS 15. If a UITabBarController is used, the tabs are presented in an unwanted title/toolbar at the top of the window. If you have an app where your views run to the top of the window, this can obscure the content and controls that are near the top. I created a sample application that is attached to the Feedback record (FB14293963). When building under Xcode 15, this is what the app looks like: Under Xcode 16, it looks like this: Beyond this simple example, using UITabBarController in a presented view controller can result in the tabs not showing at all. Also, If you switch the view in the main window to something that isn't a UITabBarController, the tabs still remain at the top. This seems to stem from the tab bar/sidebar changes for iPadOS 18. While this approach can work for simpler apps, it may not work well at all for more complex apps and there really needs to be a way to opt out of this behavior so apps where it is not suited for can still take advantage of features in iPadOS/Catalyst 18. Has anyone discovered a workaround or way to disable the new tab bar behavior with having to write their own version of UITabBarController?

I am struggling getting universal links/applinks working for an App Store Event. I have been through the docs and various troubleshooting methods a number of times and cannot figure out why the universal link is not opening the app. Here's the apple-app-site-association file we have hosted on our website in .well-known (full url https://binaryformations.com/.well-known/apple-app-site-association): { "applinks": { "details": [{ "appIDs": ["com.BinaryFormations.UnderMyRoof"], "components": [{ "/": "/umrappevent/*", "comment": "Matches any URL whose path starts with /umrappevent/" }] }] } } Here's the configuration in the Associated Domains section in Xcode: I've also implemented scene(_ scene: UIScene, continue userActivity: NSUserActivity) in the window scene delegate. Just to see if it might solve the problem, I also implemented application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([any UIUserActivityRestoring]?) -> Void) -> Bool in the application delegate. I've been testing with this URL, among others, and the app is not being opened: https://binaryformations.com/umrappevent/9999 I've tried every troubleshooting technique I could find, including the once mentioned in TN3155 on debugging universal links (https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links) and everything seems to be as it should. Here's a summary of what I've tried so far: Checked that the CDN was returning the correct apple-app-site-association file: https://app-site-association.cdn-apple.com/a/v1/binaryformations.com Ran the following test with curl to verify there are no redirects (it returned with the response code of 200): curl -v https://binaryformations.com/.well-known/apple-app-site-association Using the above mentioned apple-app-site-association file as test.json, I randomly this test using swcutil and the URL seems to match fine: sudo swcutil verify -d binaryformations.com -j test.json -u https://binaryformations.com/umrappevent/9999 { s = applinks, a = com.BinaryFormations.UnderMyRoof, d = binaryformations.com }: Pattern "https://binaryformations.com/umrappevent/9999" matched. Associated Domains Development Diagnostics on the phone seem to indicate everything is okay with the URL: Last one: after installing a build from TestFlight on an iPhone (iOS 18), I see this in the swcutil_show.txt file from a sysdiagnose after trying the following link: https://binaryformations.com/umrappevent/9999 Service: applinks App ID: G52SXV33MH.com.BinaryFormations.UnderMyRoof App Version: 20240910.0 App PI: <LSPersistentIdentifier 0x4f8026100> { v = 0, t = 0x8, u = 0x474, db = 52D70E5E-2E19-4D2C-ADA7-1E6154CA1AFA, {length = 8, bytes = 0x7404000000000000} } Domain: binaryformations.com User Approval: unspecified Site/Fmwk Approval: denied Flags: Last Checked: 2024-09-11 15:36:17 +0000 Next Check: 2024-09-16 15:17:08 +0000 I'm sure I'm doing something silly that I just keep overlooking, but cannot seem to figure it out. Is there anything that's jumping out from all of this that I'm missing? Is there any way to get more information from the diagnostics as to why the rule was denied or anything else I should try? Thank you in advance.