It looks like it's already been solved with those coefficients, so why is there a "Solve" button? It's all text. It really should show the quadratic formula. Ideally, display the formulation and then have an interface to supply the coefficient values. The solve button should do an animation to replace the variables with the value and do that math in stages, animating each step. That would be cool.

This is a developer forum, not a link to the review team. So that's not the best place for asking such question. I was all ready to make a joke about Claude, but then I realized that might cause confusion, since you're Claude, but not the one I was going to joke about. Perhaps you should consider asking if your user ID can be changed. I think some people on this forum might sincerely confuse you two. Maybe the issue is with the purpose "to connect tourists with verified local guides": who verified, how do you prove that those local guides are trustworthy ? Oh, I'm sure it was the "travel companion" part. 😄 But not on this forum. While I can't make the funny joke about asking Claude, I think we can all agree that ship has sailed.

That sounds like French encryption laws.

It’s not clear whether simply removing the Python executable would be enough to satisfy Catalin_e10’s security audit. If the Python executable didn't exist, then there wouldn't be anything to audit. It’s likely that Python is used by other parts of the developer tools. That was my original assumption. In theory, this is also possible if Apple switched to the ancient bash or Perl. Since Python is a popular tool, it's more likely to be updated upstream and show up as vulnerable on macOS. Swift scripting would solve those issues as it would probably never be part of a security audit and Apple's version would likely always be updated. But it's a moot point as my feedback has already been closed. The reply said that "Feedback Assistant is only to submit bug reports and request enhancements to APIs and tools" and my enhancement request for Xcode was rejected. The Apple reply also explicitly told me not to submit this kind of feedback again.

Fair enough. But just to set expectations here, LLDB is one of Apple’s core developer tools and Python is a core component of LLDB [1]. Breaking that dependency would be… tricky. Don't worry. No expectations are at risk. 😄 I wasn't aware that Python is tied into LLDB. That would complicate matters. It looks like there is a flag to build LLDB without Python. I have a big project (GDAL) that includes components with similarly deep levels of integration with Python. Removing Python takes some work, but the results are always great. Taking Python out of a project makes so many problems just evaporate into thin air. But even if you can't remove python from LLDB, I'm still not sure that LLDB requires a standalone python interpreter. Couldn't it simply be embedded for real?

Just submitted FB23940030 to definitively fix this problem. There is no reason that Apple should still be dependent on an old version of Python. Whatever Apple is using Python for could be done using Swift scripting instead. Furthermore, using Swift would allow sysadmins direct access to the appropriate Apple APIs without resorting to fragile, cryptic solutions based on sed/awk/grep/etc.

We have also found a similar report from another developer: https://developer.apple.com/forums/thread/827331 And this one too: requestReview() prompting repeatedly Could you please clarify: Can SKStoreReviewController.requestReview() or AppStore.requestReview(in:) result in the prompt being shown more than three times within 365 days in a shipping App Store build? What do you need clarification for? Haven't your customers already demonstrated that this is possible? We can provide affected app versions, iOS versions, device details, screenshots, and examples of user feedback immediately if useful. That sounds like a lot of work. Assuming it is a known OS/API level bug, a reasonable estimate for a bug fix would be weeks to months. And that doesn't even take into consideration the current beta status(es). And if it's an unknown bug, it's even worse. My suggestion for you is the same as the one from the other thread. I don't understand this issue at all. Review prompts aren't limited in debug builds and they're infuriating. I can't imagine anyone not adding their own rate limiter. It seems like a trivial, guaranteed fix for something that could be a OS bug, an API bug, a developer bug, a documentation bug, a beta bug, a configuration issue, and probably a dozen other reasons. You can fix them all - today. Apple's APIs are required for interacting with various OS-level services. But that doesn't mean they are sufficient by themselves or 100% reliable.

This is a known problem with those scanning tools. A copy of Python sitting on the disk isn't an exploit risk. Apple does sometimes update the bundled scripting tools included with Xcode, but there's no guarantee that an updated version will pass your security scans. In fact, the opposite is more likely true.

This strongly suggests an account-level hold rather than a problem with any particular package. Yes, of course. This matches the documented "in-depth analysis / notarization profile-building" behavior for newly enrolled accounts Indeed. 50+ hours is past the typical 24-72h window 50 is less than 72.

The pattern matches other "first notarization on a new account stuck for 24-48h" reports here. Could someone please manually push these submissions through (or let me know if something on the account side needs attention)? And what was the resolution for those similar reports? Did anyone get anything manually pushed through or did new developer simply have to wait? Normal submissions for me would be expected in minutes. So why not use that account? If you're creating a new org account to replace a personal account, then it would make sense to transition to a new account. But I don't see any reason to transition from one individual account to another individual account. If anything, that's something that could cause delays. Fraud is a huge, extremely lucrative business. $99 isn't even a business lunch for those folks. New accounts get extra scrutiny.

Apple has 60+ million registered developers, and a lot fewer support reps. AI slop and "vibe coding" are obviously hitting the company very hard. What's your code signing issue? There are some people in this forum who can help with that.

Please explain why the original application was rejected as spam if it is clearly not? A spam rejection is probably based on the app category, not the source code. Apple doesn't have any access to the source, the backend, servers, or proprietary technology. But if it looks and acts like other apps, Apple might decide it doesn't need any more similar ones. Is the initial review performed entirely by a human reviewer, or are automated systems also involved in identifying potential issues? Apple uses both, see this press release.

Never use the comments feature. You're replies are hidden. That was a rhetorical question. The purpose of the beta builds is for you to test Apple's software for them. If you find a bug, submit a feedback report. The betas can also be used to identify changes to APIs and/or OS versions that might break your apps. You can then add some workarounds for the new OS versions. But you're obviously not going to be shipping anything with standard input. Just file a bug report and maybe Apple will fix it. In the interim, you'll have to run this app using Terminal. There might be some hidden, ancient method to debug a process actually running in Terminal. I think there once was such a feature, but maybe it's gone since the Xcode console redesign. I suppose you can always just debug an arbitrary process that you're running via Terminal.

You should wrap that in your own rate limiter. Sometimes the system is buggy and you can't control that. But more importantly, the system doesn't limit behaviour in debug mode and that gets real annoying real fast.

Can you reproduce? Nope. launchservicesd sitting at 97 MB after 37 days uptime. Has anyone seen whether this is addressed in macOS 26 or the macOS 27 betas? Doesn't look like it. Uptime there is 10x less and the memory usage is also 10x less, 10 MB.