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!

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.

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?

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.

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

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.

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.

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.

Why don't you schedule a "Meet with Apple" session and ask the App Review team directly?

It would be helpful to know which line exhibits the actual error. But generally speaking, none of the classes defined in any Apple API are actually sendable. That's why Apple pushes structs so heavily. This is a bit of a catch-22. It isn't the first time Apple rolled out some cool new feature but then didn't support it in their APIs. Supposedly, there is some new "sending" modifier, but it does't seem to work. I recommend using Apple data structures only for Apple APIs. Create your own data structures for your data and use that in your code. You can make them Sendable by any means necessary. But then, when you need to give them to an Apple API, add a little function that will export them to the non-sendable Apple class that the API expects.

This is a developer support forum, for programming questions, theoretically. I think what you're seeing is a side effect of the area's autonomous and multilingual nature. When I look at those islands from my Canadian English context, the names that I see are the ones that you say are correct. Goggle agrees with Apple for the most part. Google shows just Ciutadella, not Ciutadella de Menorca like Apple. However, if you are viewing from a Spanish-language perspective, then you are probably going to see the Spanish version of all of these place names, not the local Catalan versions. In certain regions, this being one of them, online map systems have to carefully check who is looking at a map to keep everyone happy.

Hmmmm, that’s a bit extreme. There are plenty of classes that are sendable in our various platform SDKs. Sorry. Perhaps I should have qualified that statement to make it clear I was talking about a general type of behaviour rather than a mathematical absolute. What I meant to say is that sometimes Apple APIs are simply incompatible with standard software development techniques and architectures. The example I was thinking about at the time was Objective-C exceptions. Another example is multithreaded code. Most Apple APIs, with very few exceptions (the general kind, no the try/catch kind), should only be called on the main thread. And even the few documented thread-safe APIs aren't always safe. Swift finally seems to have solved that via Approachable Concurrency. But now that I think about it, it seems there is yet another fundamental incompatibility. This likely explains the problem I had trying to use "sending". Swift concurrency is incompatible with object-oriented programming. Simple demos work fine because they're simple functions. But a complicated, real-world app is always going to have "self" objects. That's where the problem comes in. I think the OP in this case was hitting this problem too. They moved code to an actor to fix it. But that's not a solution in all cases. There are many cases where I want to have a "sending" behaviour which isn't possible in OO. For example, at some point in applicationDidFinishLaunching or viewDidLoad, I have the information needed to start a timer or other long-running task. I can't do that because self isn't sendable, and isn't ever going to be. And yet, it's still safe because Approachable Concurrency requires Task/await with sendable data from the concurrent thread to call back into the main thread. What I've done is add "@unchecked Sendable" to the higher-level class (a shared Model rather than a view in this case). The cognitive effort required to ensure that all public and/or concurrent access is safe via os_unfair_lock is less than trying to deal with Swift's "data race" errors. Ultimately, I think the question does come back to mathematics. I don't think the word "safe" is really the binary that Apple wants to claim. Driving isn't safe, so I wear seatbelts, but not a crash helmet. Is that "unsafe"? Maybe. But sometimes I need to go places and there's always a sweet spot between absolute safety and practicality. Programming's the same way.

Judging from your other threads, perhaps you're overusing actors and completion handlers. I've only used one actor and that was on my first Swift 6 app. I've learned a lot since then. Completion handlers are a different problem. They are largely a legacy of Apple's now-abandoned GCD architecture. The Swift concurrency approach is to use sequential, but asynchronous code instead. That new Swift approach is great. But so many Apple APIs are still based on blocks/closures. Easily the vast majority of all the "sending" problems I've encountered have been with blocks/closures. I would love to be able to write the kind of asynchronous Swift code I see in the WWDC demos. But it seems like it's never possible with Apple APIs. So my suggestion is to re-think the actor and the completion handler. Obviously, if you have an API that requires a completion handler, you often can't get around that. Sometimes APIs do have an asynchronous version. But if they don't, then you have to handle that code more carefully. And when I look at the delegate method in question, I see that it actually does have an async version. I think your best solution is to just use that. Pass the identifier to your GeoreferenceQueue and let it handle it however it should. I think this case, an actor might be appropriate. I was thinking about your Timer actor from the other thread. It's better to integrate timer functionality into the class where it's needed, avoiding completion handlers whenever possible.

You'll have to provide a whole lot more background here. What are you coding in Perl? An app? How is Perl related to it? I'm unaware of any environment variables being blocked. If you're trying to integrate something like Perl into an app, you aren't going to be able to use basic techniques like you would in a bash or zsh shell. There is more than one way to do it, but it depends on detailed answers to those questions above.

Here's an OS-level overview of low-level security features: https://support.apple.com/guide/security/sec8b776536b/web This is a video on Memory Integrity Enforcement: https://developer.apple.com/videos/play/meet-with-apple/206/ And this is a research paper on the same: https://security.apple.com/blog/memory-integrity-enforcement/