How can I shield myself best against accidentally submitting a malicious version of this third binary via notarytool to Apple? Is this a trick question? Only submit code that you have written yourself and that you're 100% sure isn't malware. Note that this also includes code written by an AI. Should I separately submit versions of this binary for notarization from submitting new versions of my app? This binary is bound to change way less frequently than the app I'm actually developing. I don't understand this question. But it's a moot point. While Apple doesn't publish the internal mechanism behind notarization, it should be easy enough to guess. It does a basic malware check against known signatures. It also records the submission for malware that might not be discovered until later. Anything you submit, regardless of provenance, goes against your account. I really don't want to risk termination of my Apple Developer account because it has many high-value applications available. So what's the value of these open-source packages to you then? You haven't specified what these packages actually do, which is a really important point. In many cases, the risk of supply-chain malware from an open source project is very low. If you're a heavy AI user, the risk from 3rd party code might even be less than the risk from your own, AI-generated code. But in certain domains, the risk of malware is very, very high. Which domain are you working in? I don't know. I would love to hear if there's other steps I can do to protect this pipeline and my company from accidents like these that may unintentionally damage our reputation. Nothing new here. It's always a risk/value trade off, eh? It's a little bit different in software development just because standard industry practices are typically the most risky ones imaginable. If everyone else is doing it, it must be correct, amiright?

is Apple recommending that developers ... rely entirely on the framework to determine whether Texas age assurance requirements apply? Yes. My understanding is that Apple is leveraging its Apple Account information that will already have the users' legal residence. It's possible that Apple may also use device location, but it would be Apple system frameworks performing that query, not your app. You wouldn't need to worry if location services is enabled or not. When governments mandate these kinds of personal information disclosures, they also aren't going to allow personal privacy that would be in conflict. All that being said, you should carefully review any result codes and gracefully handle unexpected failures. At Apple's scale, an app that works great 99% of the time could swamp your support and lead to thousands of complaints. Per day.

in my case, there's absolutely nothing to go on. No one here knows anything about your app. It's obvious that Apple did give you feedback. You literally quoted them. what's the safest way to proceed? Again, that's obvious. Submit a newly designed app that Apple wants to have in the store. Apple has publicly announced, through its updated App Review Guidelines and social media outreach, that it intends to try to raise the quality of apps in the store. There's no mystery here. We all know what's going on and has been going on for years. It's unfortunate that Apple waited so long to take action.

This is not a normal delay No. It is not. This is exceptionally good response time from Apple. We have submitted 4 expedited review requests — all approved. We have contacted Developer Support multiple times. Every time we are told “it will begin shortly.” It never does. When you submit expedited review requests under conditions like this, then that diminishes the values of those requests for other developers. June 23: Resubmitted again with additional bug fixes • Today: Still “Waiting for Review” — no movement, no communication Today is June 23. We have addressed every single issue Apple raised — promptly, thoroughly, and without complaint. You're literally complaining right now. It looks like you've set up unrealistic deadlines and now you're rushing. It's never going to turn out well if you're in a hurry and depending on the actions of someone else, who isn't in a hurry, and has more power than you. App Store Connect has a feature where you can take as much time as you need to submit your app, fix bugs, and get ready to release. Then, when you're ready, and on your schedule, you can start your marketing campaign and release your app at the appropriate time. However, I should point out that even in that case, it can take up to 24 hours for your app to be published in all selected global storefronts. So you should probably release your pre-approved app the day before you need it. This is generally a business of months and years, not days.

What you describe sounds exactly like my own experience. It's really slow. But I'm pretty sure that LLM agents are not involved. It seems noticeably better than it was 2-3 years ago. It doesn't go insane and start moving elements around on its own like it used to. Unfortunately, I don't see any future for Interface Builder. Many people have already switched to SwiftUI. Ironically enough, Interface Builder is much faster and more reliable than SwiftUI Previews. Maybe just start scaling back use of Interface Builder. Use it only for top-level objects like windows and view controllers. Do anything lower than that in code. In particular, Interface Builder really struggles with auto layout. So once you feel the need to start doing layout, that's your signal to switch to code. As more and more people are using AI, you're going to see even less use of Interface Builder. I guess it's time to start the deprecation clock. It's not as if I'll really miss it. I miss what it could have been. I miss the functionality that so many other IDEs have been able to deliver, but Apple never could. I still remember when Metrowerks CodeWarrior was gold standard. Its UI API PowerPlant was just awful. I think Interface Builder was one of Xcode's (né Project Builder) most attractive features at the time, because it was so much better than PowerPlant or Apple's own MPW. A code-based UI is definitely possible. I used to use a great product calls Tools Plus for all my UI. It was 100% code-based, but much easier to use than anything else. But Apple took over so much of the logic with MacOS X that the Carbon-based Tools Plus was no longer possible. But I think it the idea might be viable again in the future.

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.