No correction necessary. That's all correct. Something complicated like the JDK would likely need entitlements for the hardened runtime if notarization was desired. But you're starting to get into obscure technical details here. Why do you care about the JDK anyway? For the vast majority of Mac apps, the Mac App Store sandbox is all you ever need to worry about. For all practical purposes, you don't have to worry about anything more complicated than the sandbox unless you have guaranteed external funding - and a lot of it - for some very specific end users. Look at it this way, if you are considering this JDK-based app for someone that you don't already know by name, you are in deep, deep trouble.

Anything involving local network restrictions should be easy to debug. Construct a program that fails. Then try it on a non-local connection. If it consistently works there and fails locally, then you've definitively confirmed that it's related to local networking. However, there were more changes in macOS 15 than just local networking. There are two big issues that end users encounter. Firstly, macOS 15 adds a new feature called "Private WiFi address" and defaults it to "rotating". As someone who sometimes does interesting networking myself, I immediately changed that to "fixed". This is not my problem to deal with. You can also change this setting to "fixed" and see if that eliminates the problem. Most people encountering problems are willing to change this setting to "fixed". Next, macOS 15 mades some low-level networking changes that broke many VPNs and network filtering apps, including Apple's own Application firewall. It turns out that most people really don't understand networking and believed that the Application firewall was a required security layer. Typically those folks added additional 3rd party filters and VPNs on top of that. From a technical perspective, this one is easy to solve too. Just don't do any of that. From a social perspective, this is much more difficult. You won't convince anyone that the Application firewall isn't doing anything more than protecting their Mac from hacking attempts from their printer. It would be a good idea to double-check this just to confirm that this isn't where your problem lies. If so, you've avoiding a major problem. There may be technical ways to solve the firewall problem. I encountered this a little bit back when I used to use libcurl. For that kind of low-level networking, you may have to perform some unusual operations in the presence of these kinds of exotic networking configurations. Those basic operations with sockets simply may not be viable anymore. Any connection may involve significantly more effort to deal with all the different hoops that these network modifications will have put in your path. It may have worked just fine before, but it doesn't anymore. From an OpenJDK perspective, you have to support a much wider range of networking operations. I'm sure you can't just require Private WiFi address to be fixed and you can't assume no networking filters. But I still think it's important to look at these settings to confirm or discount that they are involved with the problems you are having. That will give you important clues about where you need to look for solutions.

[Q] What is the modern equivalent of this solution? There is a similar shape in SF Symbols called "square.dashed". It's not quite the same, but it's a relatively stable resource. I guess there wouldn't be any content type for an unknown object. It's unknown, so by definition, you don't know what type it is. The only truly guaranteed resources are the ones you include with your app.

Additionally, I went to both zable.co.uk and zable.com websites. zable.com says nothing about "Lendable" and clearly says it is separate company. That alone appears to be the practice that this policy was designed to prevent. The zable.co.uk site does say that it's a trading name of Lendable, albeit with a copyright of "Zable". I don't know if that disclaimer is sufficient to satisfy Apple's policy for this site. Maybe you should partake of Apple's one-on-one App Store consultation?

"Apple will update its series of "Identify your ..." support articles once the devices ship. Those will provide Apple's official names, model identifiers, tech support links, etc." This is what it says: "MacBook Pro (14-inch, 2024) in Silver and Space Black. This model has the M4 Pro or M4 Max chip and includes three Thunderbolt 4 ports. Model Identifier: Mac16,6, Mac16,8" That doesn't say which model is which? How do I distinguish between a Mac16,6 and a Mac16,8? First of all, never use the "Comments" feature. All that does is hide your reply. Why do you need to differentiate? In your original question, you wanted to know the marketing name - i.e. "MacBook Air (13-inch, M2, 2022)". Either of those model identifiers maps to the same marketing name. If are now saying that you want to be able to lookup detailed, specific model information, then I'm afraid you're out of luck.All of that is proprietary. Technically, even the model identifier is proprietary. Apple is just kind enough to make it relatively unique and an n-to-1 mapping. This wasn't always true. If you look through the models on that page, you'll see that all of them come in multiple colours, but only some have different chips. Only those with different chips have different model numbers. That's the correlation maybe? You may be able to get the specific chip elsewhere, like sysctl or similar. But again, this is someone else's products, in someone else's database, using someone else's identifiers. None of this is what Apple considers "API" and therefore officially useable by 3rd party developers. Even those things that are "API" can, and will, be changed on a regular basis. Wouldn't you rather write a nice iOS game instead?

Here is a link to Apple's open source implementation of the MSDOS filesystem using FSKit. Just so you know, these projects typically won't build outside of Apple's internal system.

i am posting this because i seek an understanding of Apple's cross-platform UI strategy. That's pretty easy. Deprecate all platforms other than iOS. Then re-brand iOS to match product lines. my background is UIKit, Core Animation, and Chameleon a UIKit workalike for (then) OSX. Chameleon? The Github project hasn't been updated in 11 years. The project web site redirects to what appears to be a Vietnamese sports gambling site. UIKit evolved and Mac Catalyst came along. what is the positioning of Mac Catalyst? it extends and at the same time it limits AppKit. is it an AppKit extension or is it a UI framework of its own? a Mac Catalyst app is not an AppKit app, or is it? or is it sort-of? I don't know if Apple even thinks in terms of those kinds of architectures and strategies. Or if they do, they sure don't make it public. And even if they did, it wouldn't necessarily mean anything to 3rd party developers. It's a radically different perspective than anything Apple enjoys internally. SwiftUI sit on top of UIKit (for iOS) and Mac Catalyst (for macOS) or is it an unrelated technology? I can't speak to Official Apple Positions. I can tell you that those Official Positions can and do change regularly and without notice. As a 3rd party developer, it's closer to reading tea leaves than to reading documentation. From my completely non-official, outsider perspective, Mac Catalyst is dead. SwiftUI is (for now) the official API of the Future for both iOS and macOS. Unfortunately, Swift (and SwiftUI) are still under active development. Bugs and other limitations are common. I don't know if this is something that will be fixed or if it is a strategy to more permanently limit 3rd party app complexity, customization, and support for old OS versions. more recently i see CoreUI messages in the debugger console. where does that fit in? will future UIKit, AppKit, Mac Catalyst, and SwiftUI all build upon CoreUI? will CoreUI become a public framework like CoreGraphics, CoreAnimation? There is no one outside Apple who can answer that question, and no one inside Apple who will. The Apple rumour sites are predicting a major redesign this year. That's seems reasonable. in the old Apple docs there were block diagram overviews of how the individual frameworks would sit one on top of the other. this is what i am looking for... I'm sure if any such documentation is produced for public consumption, it will be made available in exactly 3 months from now.

Who knows where the problem lies with this? How would anyone know? You haven't provided any context. It is pretty common for people not to provide any context in questions like this. There is a good reason for that. On the few occasions that people do supply some context, Apple's rejections seem completely reasonable.

Don't use the "comments" feature here in the forums. It hides your posts. Core Image is designed to be a black box where you don't know the implementation details. The more complex your pipeline, the greater the risk to performance. Generally speaking, think of how you would implement any given Core Image filter. If it seems like it could be implemented on the GPU in a straightforward way, then it probably was. If not, you had better investigate that filter more closely. Review Apple's Core Image documentation for Getting the Best Performance.. These suggestions are more than just general best practice suggestions. I'm sure the reflect the internal limitations of Core Image as well. These suggestions say to "Make sure images don’t exceed CPU and GPU limits", "User[sic] smaller images when possible", and "Avoid unnecessary texture transfers between the CPU and GPU". Sometimes you have to read between the lines. For example, Core Image has image tiling support that violates all of these principles - and is horribly slow as a result.

I think my biggest bottleneck is needing to process a ProRAW image immediately after capture which seems a few seconds to even start the image processing. That doesn't sound like it has anything to do with Core Image. That sounds like more of a threading or concurrency problem. When I talked about Core Image hitting the CPU resulting in "horribly slow" performance, I was talking about a reduction in frames per second, not seconds per frame.

I've heard that these kinds of images encoded into smart cards use a jpeg2000 code stream, which apparently Apple's built-in JPEG2000 logic either doesn't support or doesn't expose in existing image-based and PDF APIs. You will probably have to use a 3rd party framework like OpenJPEG to get access to lower-level decoding routines.

Are you sure Xcode isn't just locked up? When you hit a breakpoint, or sometimes even step to the next line, it can take a long time before the debug inspector pane is useable. I assume that any operation you do in Xcode during this time is likely to fail. You just have to wait for it. Once the debug inspector pane has its data and is useable, then I expect everything should work. But this can take anywhere from 3 to 30+ seconds, even on a fast machine.

I'm pretty sure that if Apple thinks your app would be useful in Apple's marketing, they'll be sure to reach out to you.

The FSEvent create flag kFSEventStreamCreateFlagWatchRoot was specifically designed to handle this event. I haven't used this event yet. It doesn't sound like you need to recreate the event stream. The documentation for kFSEventStreamCreateFlagWatchRoot describes how to handle it. It specifically says to open the directory before creating the stream so you have the file descriptor handy.

You'll need to access the main screen via NSScreen and then check the top safeAreaInsets. This will be in screen coordinates, of course.