It depends. First of all, you must setup an app group. No option there. However you do your communication, you'll need an app group. Next, you'll need to make sure your launch agent is an "app-like wrapper". What you do is create a new app target and bundle it inside your main app. You can strip off all the things you won't need like storyboards and such. It needs to be an app-like wrapper to have a real bundle ID, sandbox, and understand that it's in a group. Next, make sure the launch agent works. Run it every 60 seconds or something. Later you can change that. There are multiple options for communication. You might not need anything. If you can run your launch agent on a schedule, you can save the configuration to a file the next time it launches. If you do need a continuously running agent, then you'll need some kind of client/server connection. You could do that manually with sockets or named pipes. Or you could use XPC. The first time I tried all of this with XPC, it failed miserably. I don't know what I did wrong. I didn't really need it as I could use a configuration file. However, I do have a test app right now with a functional launch agent talking via XPC. No entitlement needed. I'm not sure what I did differently this time. It is a fragile architecture. Also pay careful attention to user authorization. Your app needs to gracefully handle when the user disables the launch agent. I recommend loading the agent first thing and then handle the case when the user later disables it. Otherwise, if not loaded for the first time, it'll be in an odd "not found" state. Good luck!

Since Tahoe, that's just a shortcut for Spotlight search. Do a manual Spotlight search and agree to the terms. Then the shortcut will work.

Apple has something like 50 million developers. It might be a while before they get around to your question. You can start by clarifying a few things. Who sent this e-mail? Apple or your bank? If the bank refused the payment, then it stands to reason that they wouldn't have any record of the transaction. There was no transaction. Make sure all of your banking information is correct. Since this is an international account, you'll need Swift codes and all kinds of stuff. You'll have to inquire directly with your bank regarding what they need. Note that your bank probably only deals with transfers from within Japan. They may not have any idea of what you're talking about. Apple has more experience with these kind of issues, but there's no guarantee they actually have any information other than the refusal. Plus, due to privacy laws and the ungodly torrent of daily financial fraud, nobody is likely to tell you anything about anything. The best place to start is with the bank. Confirm exactly what information they need for an incoming international wire or transfer. Note that those may not be the same thing. There are many different methods of financial transfers in the world. The US only recognizes 1 or 2 of them. Since Apple is a US company with US banks, they're going to expect what US banks expect circa 1983. I would guess that most foreign financial transactions wouldn't qualify for Apple.

There is no "system data" area. That's just data that the operating system can't categorize as documents, messages, videos, etc. You'll have to use some 3rd party storage tool to find out where the storage is being consumed. I experienced this once myself. It's impressive how fast a modern SSD can allocate 300 GB of storage. In my case it was deep inside some Apple system folder where it was creating a huge number of huge disk image files. I had to disable SIP and hack the permissions of a parent folder so that it couldn't be written to. That fixed it. I was able to undo the change after a later update. But since then I've even had to roll back to 26.3.1 when Apple News started crashing a few seconds after launch in 26.4. There's no point in putting up with any of the reports I've heard about 26.5 or 26.6 since 27 is only a few hours away.

it's a one person team. Me. The forum has many sections, this one is called: "App Store Distribution & Marketing" you would think I would ask about apps and their distribution instead of just pure code? From what I understand, Apple itself often runs with teams that are ridiculously smaller than what you would have expected. They re-designed this forum a few years ago, before COVID, and added all those tags. (There are no sections by the way, just tags.) Then, as Apple often does, they lost interest. So you are more than welcome to ask about App Store Distribution and Marketing. Just don't expect to get any replies. Apple does have regular videos and "Meet with Apple" programs regarding distribution and marketing. Next week is WWDC, so there will be all kinds of videos to watch, and supposedly some Q&A sessions in the forums on distribution and marketing. But I doubt any of that will answer your payment processing questions. It will be more focused on what you see in the App Store Connect interface - offers, analytics, win-backs, subscriptions, etc. Is this an attempt to send people to that? I don't have the money for it unfortunately. I thought I had made myself clear. Perhaps I was wrong. I assumed you were a one-person team and I was just making a joke. Even trivially minor legal/accounting issues will cost many thousands of dollars/euros. Don't be misinformed by the internet. Those DMA rules and legal judgements were all meant to serve large corporations that don't want to pay any money to Apple. Some of them literally own their own payment processors. Even small companies will save millions by finding ways around Apple's 15%/30% fees. And it just so happens that many of those companies are pushing apps that Apple doesn't want on the App Store in the first place. So it's a win-win for politicians and billionaires, as it often is. But you don't have to do any of that. You can just do standard in-app purchases and let Apple handle all of those legal and payment details. You pay a flat $99 yearly fee and 15-30% of revenue. It's literally the best deal in the world. No, it's not perfect. But it's as good as you're going to get. That's what I'm trying to send you to.

What does your corporate legal and financial team say? Wouldn't they be the best people to answer these questions? This is the Apple Developer forum. At one time, it was a place where developers could ask questions about code-related issues. Today, it's been taken over and destroyed by people complaining about their app rejections and enrolment delays. Aside from about four Apple developer support engineers, and another four external people who sometimes post, it's dead and buried. I'm not exaggerating - it's like 10 people, max. Of course I realize that you probably don't have corporate legal and financial support. Are you sure you want to try to figure this out on your own? Or worse, rely on advice from the internet? Although there have been legal judgements in various jurisdictions that affect Apple's App Store policies, there is nothing preventing you from ignoring that. You can forget all of that and live like it's still 2016 and just let Apple handle all those details.

I wanted to turn a class in a struct and move intelligence in a protocol extension Why? There's a lot of pressure for developers to use static typing practices like using structs instead of classes. But a dirty little secret is that Swift is a great object-oriented language. How do I call self.init or assign to self before updating the values? You don't have self until you call init. Despite my previous statement about Swift, it does have its quirks. In object-oriented Swift, you must initialize instance values before calling super.init, which is actually backwards. (There are "reasons" for this, but rather than making those edge cases a developer responsibility, they built it into the language. Because Swift is safe by default, except when it isn't.) But if you're writing an extension on a struct, then it's more logical. You must construct the object before you can use it.

Never use the "Comment" feature. All it does is hide your replies. I'm aware of this so sometimes I check my old replies to see if there's a hidden comment. But other people might not do that. Just use the standard Reply box at the bottom. RevenueCat already handles that Apparently not It doesn't matter that it's a native OS prompt. There are lots of apps out there from years ago that may still need the old restore feature. But that doesn't mean that Apple wants any new apps to use the old system. I can't speak for Apple, but I'm pretty sure there's no mistake here. StoreKit2 is radically different than the old mechanism. There isn't even any true "Restore" functionality anymore. It's now just a reset. But the reset doesn't have any user-facing UI. They definitely test with logged in Apple IDs. It wouldn't work otherwise. The only difference is that these Apple IDs aren't connected to real credit cards.

The App Review decision is policy. Your only option in a policy case would be an appeal. A technical solution would be to bundle the two apps together into one. On first launch, ask the user to pick which language to use. You should be able to use downloadable asset packs for this. You would need to rename the app as well. Another possibility could be to change the distribution of the app to make the Osage app available only in the US and the Cree available only in Canada. Perhaps that might be something you could do in the interim that would be acceptable to App Review while you build a multi-language version. And finally, this is an excellent case of using Apple's "Meet with Apple" service to talk directly to App Review and work things out. They run that service throughout the year. But WWDC is coming up soon and there are also App Review sessions there.

Is there an updated version of the RevenueCat SDK you can use? SKPaymentQueue is deprecated. The note in the documentation says "No longer supported". The restore purchase behaviour in StoreKit2 has significantly changed. Years ago, it was a big deal. I think Apple still requires a Restore feature in the app, but it's really only because end users expect to see it. In StoreKit2 itself, there isn't any restore functionality. You just call refresh() on the AppTransaction. This may be a user privacy issue. In the old system, when someone would run a pirated version of an app, it could display the AppleID of the original purchaser, who was some rando on the internet.

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.