Never used Vulkan so I can't comment on it. But with respect to OpenGL and Metal, you seem to have them swapped. It's OpenGL that requires an initial compilation phase. One of the key features of Metal is that it doesn't need that. I'm unaware of any performance problems with Metal, although some higher-level APIs like SpriteKit have had performance problems recently. Perhaps your 5 second startup time and performance problems are related to whatever Godot happens to be. Try Xcode and Swift instead.

Never use the comment feature to reply. It hides your reply both from people and the forum's "read/updated" status. Unfortunately, there is no possible solution here. This is one of my long-standing pet peeves. What you ask is flat-out impossible. At no point in the auto-layout system can you ever know the "final" layout. In fact, there is no "final" layout. In theory, layouts can always be modified or ambiguous. Your only option is to rethink what you're trying to do. If you need to take some action on layout, then add it to the layout method, and don't disturb the existing layout. Otherwise, if you need to pre-calculate some value, you'd probably be better off making it a dynamic property that gets calculated as needed.

Maybe back up a bit. To distribute iOS apps to internal users of your organization, you need to have an Enterprise Developer account. You can then distribute your iOS apps via your own internal website, as described here: https://support.apple.com/guide/deployment/depce7cefc4d/web I don't have an Enterprise account, so that's all I can say about it. It sounds like you are trying to run iOS apps on your Macs. You can certainly do that. However, that is a feature designed for end users' convenience. From a developer's perspective, it isn't more convenient. You can bypass the complications of the Enterprise account by developing Mac-native apps. Then you can distribute them on your own website as DTS Engineer describes. The difficulty here is going to be how you develop the iOS apps. If you are developing stand-alone apps, you could use SwiftUI or the Mac Catalyst framework to built Mac apps using cross-platform or iOS APIs. But if you are using some 3rd party tool to build your iOS apps, then you'll have to explore what Mac options are available with your 3rd party build tool. From what I understand, most of them do have Mac target options.

You can contact App Review any time. There are many App Review appointments listed in Meet with Apple

It looks like a combination of settlement delays and a short fiscal month. If you download your financial report, that should explain it. The end date for March is 03/28/2026. So depending on individual transactions, any purchase from 03/23/2026 might not get paid until the next month. So definitely any purchase on the 29th or 30th won't count. Some purchases settle on the same day of the transaction. Some take several days to settle.

The most frustrating part for independent developers is that the category you fall into seems to matter more than the actual value your app provides. Whether the app is positioned in lifestyle, entertainment, or productivity, a rigid "category quota" can prevent reviewers from truly seeing the unique features we built. It's all a numbers game, and Apple understands that. If Apple is rejecting your app under this criteria, then there's a very strong possibility that your app would never get noticed in the first place. It's bad enough that you've spent time and effort in developing this app. Perhaps Apple is saving you from throwing good (future) money after bad (already wasted) money. a rigid "category quota" can prevent reviewers from truly seeing the unique features we built. App Review is going to be much more accommodating and open to new, unique features than end users will be. early arrivers have a permanent advantage over newcomers Sounds like you're starting to figure out how the consumer software industry works. 😄 Users deserve the opportunity to discover and decide between new, modern alternatives, rather than having their options restricted by a pre-determined saturation limit. But are they actually going to do that? Or are they going to pick whatever the most popular, free option is?

I've been running into lots of issues since I upgraded to 26.5 beta, spotlight doesn't work, mail index was broken and after deleting it I can't reindex my mail., after a while I get an error that reindexing failed and that I should relaunch that app and it will start over. It never succeeds That all sounds like OS-level issues. As a developer, it's not your concern. That's Apple's problem to fix. You only need to worry about it if it impacts your apps. And if it does impact your apps, you'll have to evaluate how your app responds to this kind of OS-level failure. If your app is heavily dependent on Spotlight, then maybe you need to re-think that approach. Looking into the console I wouldn't recommend doing that. That data doesn't have any meaning for 3rd party developers. So I guess the sqlite version is a dud ? It may be that you have some corrupt SQLite databases. If so, you'll need to wipe your drive and reinstall. I recommend running Apple beta OS versions, and even any .0 versions in a VM. And I strongly recommend developers have at least two separate systems, one running a stable OS like Sequoia, and another for the current OS version. And then a VM on top of that for any betas/.0 versions.

That's the way the world works today. ChatGPT was successful, so now they have de-facto control over the acronym "GPT". App Review thinks that end users would be confused and think your app is associated with ChatGPT. Apple knows how people think. Just change the name. And make sure to do a trademark search first.

by console, I am referring to a command line tool. Yes. I realize that. But use of the word "console" is triggering. It's better to say "Terminal" or "command-line" to minimize the distress of your fellow developer. My intention was to use the command line tool to test a package I am working on, as the eventual target will be a window app, I may abandon my efforts to localize my command line tool. I am using Swift Testing to unit test the package. I was hoping to hear from someone who had actually done this already. I'm not sure what you're trying to do there. I do have an app that can operate both normally and on the command line. So I can verify that it does work. But unless you have very specific requirements, and someone paying your bills for you, stay far away from any kind of command line tool on the Mac. The command line is a radically different environment and is wholly unsuitable for testing a normal app. If you want to do unit testing, I guess that's fine. You can use the Xcode debugger too. Just be aware that modern versions of Xcode integrate that horrible "console" tool. Depending on what kind of app you're developing, your development machine may not be an adequate platform for testing at all. You may need a virtual machine to isolate all the systemwide developer modifications. In some cases, you'll need a separate machine that has never run Xcode. Good luck!

Just to clarify, "console" is Apple's UI for viewing data from the "unified logging system" and crash reports. If you want to localize a command-line tool using Apple's localization framework, then you must bundle it in an app. But you can directly run the executable in Contents/MacOS and it will run in the current localization. You can even supply: -AppleLanguages "(fr)" on the command line to force a specific language. All of this might only work if you are actually running a full user session and running the app in Terminal. If you are logging in remotely or something, all bets are off. That's a different environment and sometimes these things won't work. Some Apple command-line tools get around this by linking to bundled frameworks that are, themselves, localized. I guess you could to that too.

A non-empty folder results in an icon with paper sticking out on macOS Tahoe but an empty folder doesn't have the paper sticking out. Interesting. I didn't realize that. However, it doesn't seem to always work. I just now figured out that if the folder has a "." anywhere in the name, then it will display in the Finder as the old default, empty folder, even if it has contents. If you remove the "." then it will add the paper. And Finder has its way of being exempt from all of this, natch! But of course! Edit: This is strange. There's some kind of heuristics in the Finder. You can put a "." up towards the beginning of a folder name and it displays correctly. But if the "." is towards the end, then it reverts to the default folder appearance, losing any "modern" folder customization. Ironically enough, adding a "." doesn't affect the old folder icon customization method, which, from what I hear, is completely broken on Intel.

How are you getting the icon otherwise? It's not quite "otherwise". Normally I just use "NSWorkspace.shared.icon(forFile:)". But folders require special logic. If the folder name has a "." prefix, then I call "NSWorkspace.shared.icon(for: .folder)". I'm not sure why. Probably should have commented that. But if the folder doesn't have a "." prefix, I use the standard "NSWorkspace.shared.icon(forFile:)". Then, I check to see if I need to do more. I the URL has the "com.apple.icon.folder#S" extended attribute, I try QLThumbnailGenerator. QLThumbnailGenerator is async anyway, so it really always requires the two-step process.

This might be an older bug. I experienced this years ago. In addition to using the main thread, I even moved this method call to an XPC service. And then later, I added another crash-happy API call to my service as well.

I see that too. Luckily, I only use the new QLThumbnailGenerator flow if the url has the "com.apple.icon.folder#S" extended attribute. I'm sure that's an "implementation detail", but still a good idea. Most folders display properly and immediately. It's only the folders that are customized using the new system that don't appear correctly.

Well what the F do they want me to name it? You can name it whatever you want. What is it you want me to learn here? Because you pose a giant riddle of name something that you should be given a name for... This looks like an exercise where you need to save multiple pieces of associated data based on some criteria. My friend said to me that this is a common thing you will have to do and they were right however... You have good taste in friends. What are you asking me to do? As the description says, "keep track of which kind of number was the largest". those are math terms from 20+ years ago Math is not the same as programming. It doesn't change. Technically they are math terms from "20+ years ago". They are concepts that are thousands of years old. The Fibonacci sequence is the newest of these. It was named over 800 years ago, but even then, was just a European discovery of a concept that had been known to non-Europeans for hundreds of years before that. But it's Europeans who typically impose their cultural nomenclature across science. I have no idea how to classify those terms... You aren't being asked to classify them. They're already classified. You're just being asked to identify the one that includes the largest number from the provided data. Are you asking me that? No. So why is that in the problem. I'm not sure what you're asking. Perhaps you should consult your friend again. They seem quite knowledgeable. These conundrums mixed in with legitimate problems honestly make me not want to learn Swift at all. This has absolutely nothing to do with Swift. This would be a legitimate exercise in any language. There are some interesting follow-on questions that would involve useful things to know about in Swift.