Hi, thanks for your feedback. About public.plain-text, I tried that already, no luck, so I put public.data just to try bit out. As a matter of fact I meant to use "com.abcnotation" as an identifier in the (eventual) release version, I put my name-surname just as a placeholder for testing purposes. I could not find a public UTI for ABC defined anywhere, I believe .abc has no public UTI. abc files are plain text files, but have usually an .abc extension, so I guess what I am aiming to is having the file selector let you choose both .txt and .abc files; I started with .abc because this seems the most critical part to tackle. Anyway, my document class is called Document indeed. One question: if UTI and document types are correctly defined, am I supposed to see .abc files as selectable in the open dialog? Should I look somewhere else ( don't know, maybe a delegate method or something similar...) ? Cheers, Davide

Ok, maybe I am getting somewhere. I used a terminal command to get the actual UTI of my tunebook.abc file. I got this output: kMDItemContentType     = "public.alembic" kMDItemContentTypeTree = (     "public.alembic",     "public.3d-content",     "public.content",     "public.data",     "public.item" ) kMDItemKind            = "Scena 3D Alembic" So it looks like there is a public UTI for the .abc extension, but it is completely unrelated. That is, the .abc extension is used both for abc music scores and for Alembic 3d scene. Now, what is the most correct way to solve this ambiguity? That is, to tell Mac OS that abc files may be open ALSO with my app?

I am using Version 12.4 (12D4e) I guess it is a regression from Apple...

I have found an effective workaround. It's hackish, but hopefully it's just temporary. The tab bar children VC send a notification that triggers a manual cleanup of the tab bar, calling this function on the root VC.  @objc func cleanupBuggyTabBar() {         let numberOfTabs = 4         if tabBar.subviews.count (numberOfTabs + 1) {             for index in (numberOfTabs + 1)..tabBar.subviews.count {                let view = tabBar.subviews[index]                view.removeFromSuperview()             }         }     } I don't like having to traverse the views hierarchy, but at least the UX is smooth. In some instances I have to trigger this function with a minimal delay (0.01 seconds), which I apply to the notification post. Again, not very clean but effective.

To expand on this, I have another bug, linked again to core data and swift ui. The bug appears only in the M1 simulator. I have an edit screen where I can add or remove "IngredientLine" items to a "Recipe" item. I have implemented swipe to delete. When you delete an item, the table gets messed up, cells are somehow drawn (I see the correct number of cells) but they are empty. If I close this view and open it again, I see that the delete operation was successful. Similarly, if I add an IngredientLine, via a presented sheet, when the sheet is dismissed the view load without any content. I am quite sure I might be doing something in a way that is not the most canonical; but the bugs appear only on the M1 simulator. Anyone else with something similar happening? Cheers, Davide

The same error unluckily started happening also on devices. Fortunately I found a workaround, at the end of this thread: https://developer.apple.com/forums/thread/129956?answerId=409430022#409430022. I wapped the model-updating code into  DispatchQueue.main.async { } It must be a swift UI bug, but pushing these operations to the main thread seems to work. Davide

I will file a bug, but I cannot possibly attach a sample project. I tried to export localization with a vanilla projects, and of course it works as expected. I have 10 targets, some model and manager classes are shared; the bug happen when exporting my main app target, but I don't see how to "reproduce" it in a sample project, we're talking 100s of files here... Do you have any suggestion to narrow the issue down? If I managed to do it it might reproduce the issue in a sample project... I can tell you that the XLOC generation is instant; with my vanilla sample test, although it only contained a single string, it took 10 seconds. So I assume that XLIFF generation is skipped completely... But I get no error. Any debugging tip will be useful. Davide

Hello, I think this is indeed a UIKit bug, it popped out in my app with iOS 18, with no previous warning. To give you guys some context, I have a UIKit view controller, a master view; it has rightBarButtonItems and leftBarButtonItems. The detail view is a SwiftUI view hosted in a Hosting controller. In my detail controller I am hiding the navigation bar, and I have a custom button that pops the view controller. WIth iOS 18, if I navigate to the detail and back the app hangs and the crashes. If I remove the leftBarButtonItems from the master, no crash. I did some debugging, the loop is triggered by the navigation popping, it doesn't matter if I trigger it with a closure a notification etc. Reading your indications above I made sure I was not reusing the same UIBarButton item in other nav bars; I am not doing that, in fact this is the only section of my app where I set the leftBarButtonItems. I hope this helps. Davide