Interesting to know it works on Mac (even when running as iPadOS). I wouldn't rely on that. I'm sure its all based on Unicode, fonts, and font cascade lists - none of which are API. Sure, these things exist in the API, but there's no guarantee that the OS will have it configured to properly display your Unicode string in all cases. Using NSAttributedString and NSAttachment is pretty impractical. It's really not that difficult. And when you build it with attachments, you have full control over how it gets displayed. That should be handled by the compiler, to generate the required code. I filed a bug report for suggestion FB24474671. It already does. SF Symbols show up in the text under a private use area Unicode. It looks like the fonts on iOS don't include these symbols, whereas they do on macOS. That one pen example above is an actual Unicode symbol, so it does show up properly. Apple certainly could add SF Symbols to iOS fonts like they did on macOS. In my opinion, it's much better to just stick to plain ascii. All of my strings are (x)html snippets. That way, I can control everything about them. Yes, I did have to write the code to add attachments to an attributed string. But I only had to do that once. I also had to write a parser for xhtml, but that wasn't too difficult either. Earlier I had made the mistake of using the built-in API on macOS. But it was horribly slow and broke one day on a minor OS release. In the process, I learned why it was so slow. It was an out-of-process XPC call. It's always better to stick to the lowest-level interface that you can practically use. I've been burned so many times it's unreal.

Interesting. All of this works fine on the Mac. But on iOS, some symbols work and some symbols don't. You'll have to do it the old fashioned way as Frameworks Engineer described.

display the symbol how? In what context? You said "button" and buttons already have image support. I would never use anything other than plain ASCII in source code. That's begging for trouble. But Xcode encourages it and obviously displays it as rich text, with different colours too. You can display rich text with attachments. Maybe that's how Xcode is doing it.

It does blur the background when you hover over a menu. But the menu itself isn't blurred like it is in your screenshot. Apple has like 58 million developers. Are they all seeing blurry pages and not saying anything? Am I the only one who sees is correctly? Or are you the only one who sees it wrongly?

Probably some extension you have installed.

Don't use the comment feature. It hides your replies. Swift is open source too. See https://github.com/swiftlang/swift There is certainly still lots of Objective-C, but even something like AppKit isn't 100% Objective-C anymore. If you poke around in the Xcode debugger, especially UI debugging, you'll see more and more SwiftUI being used, even for things that were once ancient Objective-C code.

Apple's system-provided dynamic libraries are all pre-cached in the operating system and don't exist on disk. You can find the source code to the Objective-C runtime here: https://opensource.apple.com However, the open source site is always a little behind. It only has 26.5 right now. I'm sure it will be at least a year before 27.6 shows up. Generally-speaking, Objective-C itself is outdated. Any documentation you find will be ancient. If you did find something really interesting, it's possible that it won't be useful because Apple will have already re-implemented that part in Swift.

The sites are genuinely benign: no brand impersonation, no third-party credential harvesting, no malware, no drive-by downloads. The process isn't any kind of positive verification. By that I mean if your website did any of that, it would absolutely be reported and flagged. But the fact the website doesn't do any of that doesn't matter. It's been about a week with no response. You're never going to get a response. Consider how much fraud there is on the internet. Now consider the fact that you're underestimating that by several orders of magnitude. There is obviously not going to be any way to dispute these kinds of issues. Just move on. The easiest solution is just to setup a new site with an unrelated name that you know to be valid. Use AWS, Azure, or some similar, household name service. Use their tools for all the pieces. Observe that it isn't flagged. If you don't want to use those kinds of services, then there are still plenty of options. I don't let AWS handle my DNS, for example. But if you're going to take risks, then you may need to try things out with burner domain names first.

There is no login form, no payment form, and no field anywhere that asks a visitor for credentials, card details or personal data — authentication happens inside Telegram, not on the page. The site does not imitate any brand or product; all content is our own. Privacy policy and terms are published at /privacy.html and /terms.html with a working contact address. Nobody cares about any of that or will ever look at it. Google Safe Browsing: clean Doesn't matter. VirusTotal: no detections LOL! Chrome, Firefox and other browsers on the same device: no warning So publish your apps on those platforms then. The warning appears only in Safari Typical response in these cases is to just blame Apple for some bug or wrong-doing and write a blog post about it. Or would you rather solve the problem and prevent it in the first place? Now that's a radical approach. After migrating hosting I created a brand-new subdomain that had never been published, linked or crawled anywhere, pointing at the new IP. Safari flagged it immediately on first load. That strongly suggests the entry applies to the registrable domain and all of its subdomains rather than to a specific URL or IP — and therefore that nothing I change on my side (hosting, content, subdomain) can clear it. That seems likely. Furthermore, you should consider that domain name to be dead. It may be possible to resurrect, but I don't know. What I have already submitted "Report an Error" from the Safari warning screen The Fraudulent Website Warning review request form Feedback Assistant: FB24430497 Apple certainly loves feedback. Doesn't mean they'll do anything about it. Generally speaking, if this is a problem that only affects you, and not Apple, then you're on your own. Is there a review channel for the Apple-side list other than the three above, and is there any way to tell whether a submission was received at all? You can be confident that it was received. Since a never-published subdomain was flagged on first load, is the entry expected to apply to the whole registrable domain? If so, is a domain-level review the only path? There is no path. You've reached a dead end here. Has anyone here had a Safari-only false positive cleared, and roughly how long did it take? Probably the single most annoying request in this forum - the appeal to anyone else who has had this problem. What do you expect to get out of this request? I saw a virtually identical post 3 days ago. Didn't you? Does it matter? I assure you, it does not. I am happy to provide anything else that would help — full URLs, screenshots, timestamps. None of that matters in the least. Here's what you do... Recognize that you're talking ".ru". This is the world as it is. It's working very much "as designed". When you find a nice web host, register a throwaway domain name. Check it in Safari. If it fails, find a new host. Repeat until Safari is happy. Ideally pick a nice, Apple-friendly host like AWS or Azure. I recognize that may be problematic for .ru, but such is the state of the world. Maybe try avoiding the ".ru" domain. Maybe that helps. Once you're confident that you have a workable stack from host to DNS, try your real domain name. Hopefully that works.

Never use the comments feature. That hides your reply. Sounds like a clear win for Apple. Go for it!

Since going through Apple for a D-U-N-S comes with advantages Such as? You can go through Dun & Bradstreet to get your Dun & Bradstreet number in a couple of weeks. Maybe revisit this thread in a couple of months and let us know if you made the right decision.

I think it's just ambiguous wording on Apple's part. When they say "have the option to submit your information to D&B" that just means this is something you can do. You are interpreting this as Apple saying they are going to give you an optional button to submit your information to D&B. You have to leave the Apple website and get your DUNS number on your own. Then, in theory, once Apple syncs with D&B's information, your LLC will show up on the lookup list.

Works fine here. I think the problem lies somewhere in your hitTest logic. That does seem to be the problem you're having, but none of the example code that you posted does anything with hit testing. In my case, I have a custom NSImageView specifically so I can get the location of the toolbar item. That is a little tricky. But your example is straightforward. I commented out my code and replaced it with your code and it printed the desired message. What I do is set a custom callback in my NSImageView-derived class. When I setup the toolbar item, I assign a closure to his callback that calls my method, passing in the toolbar item itself. Then, in the NSImageView subclass, I override mouseDown to call my custom "onClick" closure. That closure calls my parent view method with the toolbar item as a parameter. From that, I can get the toolbar item view's bounds and use those to display a popover. I think you're in a rabbit hole with the hitTest path. It seems irrelevant. Buttons really aren't appropriate for the toolbar anyway. It sounds like you've got some other code that's doing something funky with NSView and that code is incompatible with life in the toolbar.

THE APP WAS ALREADY APPROVED ONCE Approval is not a one-time, permanent state. Any update requires a new review. That being said, a new review doesn't even require a new update. I already got a job for another big AAA game and have moved on from the whole thing. So why are you pressing the issue?

What does 'multiple times' mean? Twice? Five times? Ten times? The OP said 4-5 times. I cannot find 3.2(f) section in the guidelines Someone else posted something similar. It's paragraph 3.2(f) of the Apple Developer Program agreement. This paragraph lists issues such as, "any act intended to interfere with any of the Apple Software or Services, the intent of this Agreement, or Apple’s business practices" and "any unlawful, unfair, misleading, fraudulent, improper, or dishonest acts or business practices". As is always the case, Apple provides some examples, but those examples are always "such as" or "for example", not an exhaustive list. These criteria are not vague and do not require a published app, or any app, really. The takeaway here is that violations of the Developer Program are serious, full-stop issues. One could view repeated submissions in this case as an attempt to find a different reviewer who might inadvertently approve the app. So those repeated submissions could, themselves, be the violation in question.