just watched the "Build an appkit app with the new design" video. There is a section on the scroll edge effect but there is no mention how to deal with it. How can I customize my drawing when my view is inside the "scroll edge effect" There was stuff about Split View, toolbar items, but nothing about collection view.

Nope I gave up on it.

FB20272917

I filed FB20272813

This should do it. NSPopUpButton *popupButton = [[NSPopUpButton alloc]initWithFrame:NSZeroRect]; [popupButton addItemsWithTitles:@[@"Animal",@"Dog",@"Cow"]]; popupButton.bezelStyle = NSBezelStyleFlexiblePush; popupButton.showsBorderOnlyWhileMouseInside = YES; [popupButton sizeToFit]; It should be easy enough to translate my Objective-C to Swift if needed.

So returning to this issue after while I made the following discovery: The image was parsed from a PDF stream. Data was obtained using the CGPDF APIs. The decode array appears to be explicitly included in the PDF file but for some reason it wasn't in the stream dictionary. Around the time when I wrote this I think I just grabbed a copy of the image data, saved it, and starting messing with it using the Accelerate APIs/NSBitmapImageRep in a small sample project.. Looking at the PDF spec there are default decode arrays for color spaces. Passing the default decode array as documented by the PDF spec to CGImageCreateWithJPEGDataProvider and it works. No need to to convert with vimage at all.

Yeahhh it's broken. Very annoying.

wow i haven’t got on 26 but i have plenty of nibs with autolayout constraints. hopefully they don’t ship this. i’m one of the three still using AppKit. i won’t touch SwiftUI with a ten foot pole

What about exposing Objective-C API to Swift only within the framework? Private framework API shouldn't be imported in the umbrella header

I filed: FB18281521

I met with the UIKit team last week and discussed this briefly. They explained some of the challenges that led to this decision, and that they didn’t make it lightly. I might’ve been more receptive to this change had the messaging been better. For instance, if it were explicitly mentioned in a WWDC session or, ideally, at last year’s WWDC—a year before the removal of support. They thought it was mentioned in the release notes this year, but I haven’t found it. What did they say? I'd love to know why unarchiving a nib became too much of a burden all of a sudden, to the point where they couldn't even give proper notice before removal. I don't have a Catalyst app that loads the menu bar from a nib but so many changes in recent years pulls us back instead of pushing us forward. Remember when you could just set restoration identifiers on view controllers and UIKit would restore your entire view controller hierarchy? Now why didn't they apply that same approach to scene based apps? I mean I did it but they're supposed to be the geniuses why are they making every developer repeat that code? Now they want us to type nibs by hand. What are they going to take away next?

How is the alert presented in the second UIWindow? Is it the root view controller, or is presented on the root view controller? Not sure if this works but did you try implementing the AppDelegate method: (UIInterfaceOrientationMask)application:(UIApplication *)application supportedInterfaceOrientationsForWindow:(nullable UIWindow *)window API_AVAILABLE(ios(6.0)) API_UNAVAILABLE(tvos); I heard UIApplicationDelegate is on the chopping block so even if it does work who knows how long it'll work for (IMO AppDelegate still has useful APIs that scene delegates don't cover and certain things are really quirky to do in a scene delegate) . I use a separate UIWindow to display some critical alerts too because injecting alerts in the UIViewController hierarchy can lead to some nasty bugs, especially if you run a network operation and get an error, the user might have hit a button and presented or pushed another view controller on screen in the in between but you really want to display that error. Separate UIWindow avoids a lot of potential problems about presenting on detached view controllers, interfering with the state of view controllers the error alert know nothing about, etc. ..But I let my alerts rotate. Consider whether you really need to do this. Usually you should allow rotation in both windows but if you really can't you can try implementing the method above but note on iPad with resizable windows the concept of orientation doesn't make sense if you're not full screen. If you're feeling really hacky I guess you could respond to the rotation in the alert window and just move everything where you want it to make it look like it's not rotating but I don't think I'd do that.

Interface Builder has fallen out of favor at Apple which really is a shame. Are they throwing an exception or just logging a warning? If they are throwing an exception IMO that’s really unacceptable to kill something so core to an app’s functionality without giving a depreciation notice and at least a year (ideally two) years to migrate. So nice to have to spend a month rewriting my app after WWDC each year. Re-creating a complex menu hierarchy in code is exactly what I wanted to do. Ugh. yea it’s getting old. Rewrite this. Rewrite that. get nothing in return. Swiftui swiftui swiftui. I think they are more likely to drive veteran developers to a third party frameworks than invest in their new “goodness”

I also have a Mac App Store app that uses the 'Mac style' group I'm going to update. I'm looking for advice on how I should proceed. Xcode nudged me to toggle "Register app groups" and now I have the old identifier listed in "app groups" for all target and it is in red text. So if I hit the + and make a new identifier with the group. prefix, am I supposed to duplicate the old preferences to new container? NSUserDefaults *oldGroupPrefs = [[NSUserDefaults alloc]initWithSuiteName:@"oldcontainerid"]; NSUserDefaults *newGroupPrefs = [[NSUserDefaults alloc]initWithSuiteName:@"newcontainerid"]; // save the values from oldGroupPrefs to new? Documentation states: Format the identifier as follows: group. Apple ensures that the group name you choose is unique when you register the app group on the Apple Developer website. For more information, see Register an app group. In macOS, you can also create app groups or add apps to existing app groups using this identifier format: . You don’t need to register app groups that use this format on the Apple Developer website. So I'm confused. Docs state using the old format is okay.. In the App Groups working towards harmony post: Without that, you can’t submit an app that claims both styles of app group ID to the Mac App Store. [...] It is possible to work around this limitation, but it requires ‘heroic’ measures. The trick is to split your code into a main app and a helper, with the main app only claiming the iOS-style app group ID and the helper only claiming the macOS-style one. Your main app can then call on the helper to do the necessary work, for example, to access the app group container for the macOS-style app group ID. I don't want to do this. I don't have a Catalyst app and I only need one group to write shared preferences in. So I don't really need to do this....unless it is going to be enforced policy. Migrating data from a container is annoying enough but having to migrate from a helper tool seems kind of insane.

So I just read this. >Even outside of the Mac App Store, the presence of the macOS-style app group ID causes problems. It is possible to work around this limitation, but it requires ‘heroic’ measures. The trick is to split your code into a main app and a helper, with the main app only claiming the iOS-style app group ID and the helper only claiming the macOS-style one. Your main app can then call on the helper to do the necessary work, for example, to access the app group container for the macOS-style app group ID. This helper can be an XPC service or an embedded helper tool. Overall, this isn’t a lot of fun [1], and if you’re in this situation you might want to wait for a fix to FB16664827. [1] Unless, like me, you revel in implementing wacky workarounds (-: I have an outside the MAS app that claims both style containers. I only added the group. prefix because I just updated to Xcode 16.3 and it nagged me to. What kind of issues can I run into here? I'm not actually writing to the new "group." container prefix yet but I did claim it.. I'm about to push the outside the Mac App Store app out..(already notarized...seems to be working fine) should I not go forward with it and take away the "group." from all targets?