I don't see how you could ever do pixel-perfect layouts in storyboard in the first place. It's extremely buggy. I generally have a lot of constraints that I configure to be removed at build. I just need them in IB to keep the size greater than zero and less than 7000. Then I set accurate constraints in code. That's really the only option. What you see in IB is just a very rough facsimile of what it will look like when running. And many Mac controls don't support constraints at all.

I was about to respond in a similar fashion. An exploit is typically considered a binary operation. The app is either secure or exploited. XPC Services make that a floating point. The app can be partially exploited, on either the main or the XPC side(s). That both limits the risk and increases the cost of the exploit. However, then you mentioned daemons. That's something completely different. XPC is many different things. It is a communication protocol that can be used by both XPC services and daemons. But XPC services are not the same thing as daemons. XPC services are easy to use and deploy. They give you some flexibility with sandboxing. But there's nothing easy about daemons, including The XPC communication.

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/

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.

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.

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.

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.

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.

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

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?