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.

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.

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.

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.

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

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?

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

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.

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.

please correct me if I misunderstand Entitlements only apply to the sandbox. They "entitle" the sandboxed app to break free of the sandbox for very specific needs. Those Java tools would not be distributed as sandboxed executables.

There were both renamed to animate(_:changes:completion) There are always two sources of documentation. Option click the statement to see the fancy docs, context menu > Jump to definition to see the header docs. You'll find this information in the header docs for this.

You should be able to change your user name by clicking on your profile icon and selecting "Edit Profile". There you can edit your details. I don't think non-Apple people can change their user names. Mine is disabled.

There is no way that Apple could possibly employ someone who reads that obviously-spam message and thinks, "this needs to be on the Apple Support forum". No, impossible. I'm sure they don't think that. But the Apple Support Community has better staffing to handle these kinds of issues. The developer forum might not even be able to ban a user. My cyberstalker still seems to be able to post after many abuse reports. They can delete posts, but for whatever reason, that's extremely rare. The only post I've ever seen deleted was posted by an Apple employee who said something they shouldn't have.

I don't believe you. A canned reply is not the same as a bot. After all, "bot" is just short for "robot". That requires some sort of automated processing. I have seen no evidence of any kind of automated processing being done by Apple developer support. Everything seems to be manual and done by a woefully understaffed team.

An EtreCheck report tells that my app is not signed, while codesign -dv /Applications/***.app returns a valid signature. I'm lost... EtreCheck isn't designed to be used with developer builds of apps. It only considers Developer ID and App Store builds as valid. You should consider spctl the authoritative result. Years ago, I used to use codesign more and I would test a Developer ID build with "codesign -vv -R="anchor apple generic" /path/to/app". However, you also mentioned TestFlight. I've never used TestFlight, but isn't that an App Store thing? So are you doing developer-signed builds? EtreCheck has no idea about that. Never attempt to disable Gatekeeper on your developer machine. That would be a bad idea. Thankfully, Apple recently added an extra hoop to jump through that saved you. I'm sure your Sequoia install is fine. It's the app that's corrupt. I was confused at first when you were talking about Monterey and App Store. You need at least Ventura/Xcode 15 for App Store submissions. I guess you are using Sequoia only to submit? I think you're just hitting some odd edge case on Monterey. My recommendation is to build and debug on the oldest supported configuration. As of right now, that's Ventura/Xcode 15, but that could change any day now. Then test on any other supported OS versions, heavily favouring Sequoia and Sonoma. There is one developer feature in EtreCheck. Look at EtreCheck's "Operating System Adoption over Time" page in "Insights". Sequoia is 66% of installations. Monterey is still holding on at 9.1%. Anything before Monterey is a waste of your time unless you have a very specific user base. If you post more details about your app, then maybe someone could see what's wrong with it. Maybe disable any DRM and build a notarized Developer ID version and fully test that in a VM. Make sure to actually download it from somewhere so you get the correct quarantine flags.