Apple Maps Guides

[quote='863937022, kukukaki, /thread/805437?answerId=863937022#863937022, /profile/kukukaki'] I tried this on iOS platform. [/quote] Yeah, I thought that might be the case )-: I discuss the current situation on iOS in this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='863962022, ETY, /thread/805466?answerId=863962022#863962022, /profile/ETY'] I am specifically trying to get flow-based data [/quote] Content filters work in terms of flows, not packets. They’ll give you local and remote IP, local and remote port, and protocol. They won’t give you per-packet flags (SYN, ACK, FIN, and so on) and, at least for TCP, there’s no concept of record boundaries. If you’re coming from a BSD Sockets background, they operate above the socket layer, not below the IP layer. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='863936022, chevalierpg, /thread/805044?answerId=863936022#863936022, /profile/chevalierpg'] I originally did file a bug report (Case-ID: 16602242) [/quote] Ah, you’re being confused by Apple’s many systems )-: The above is a DTS case number. I bounced you to the forums so that I could clarify the exact problem you’re seeing. I’m now suggesting that you file a bug report. You do that in Feedback Assistant. The resulting bug number will look like FBnnnnnnnn. I have lots of details about how to file bug reports in Bug Reporting: How and Why? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

There are two parts to this: What works? What’s sensible? AFAICT an OS activity is thread safe. You can happily create it in one thread and apply it in another. However, there are reasons to be careful here. The doc comments in make it clear that the current activity — well stack of activities — is per-thread state. That raises a couple of concerns. The first is just confusion on your part. If you start the same activity on multiple threads then you could easily get confused about what’s happening where. I think the OS will handle it just fine, so it’s really just a matter of whether it works for you. The other concern is Swift concurrency. It uses a pool of worker threads and the thread running your task can change at any suspension point. That means you have to be careful with per-thread state. Specifically, you have to make sure you clean up any per-thread state that you apply before you suspend. This comes naturally to os_activity_apply because the closure you supply is synchronous. OTOH, os_activity_sco

Hi Quinn, Thank you for your response and for clearly outlining the current situation. Although I appreciate the information, I must say that the outcome is quite disappointing. The guidelines introduced around macOS 10.7.3 effectively create a perpetual non‑compete for existing window‑manager applications, giving those apps an almost monopoly in this niche. It’s hard to believe that this aligns with Apple’s stated commitment to an open market and product diversity. I have no intention of selling my app outside the App Store; on the contrary, I consider the App Store to be the premier distribution channel for macOS software. Most Mac users I know turn to it first because of its convenience and the trust it inspires. The “tax” that developers pay to sell through the store is a reasonable price for the exposure and credibility it provides. That said, I understand the rationale behind sandboxing, but I don’t think this should be the final word on the matter. Either existing non‑sandboxed window managers

As Albert suggested, I recommend that you isolate this in a small test project. You can then experiment with adding and removing NSAllowsArbitraryLoads. That’ll tell you whether ATS is a factor or not, and that’s always a good first step in situations like this. That -9802 error is errSSLFatalAlert. This is a common symptom of ATS problems because ATS simulates the TLS fatal alert on its failure path. However, it’s not a definitive, because TLS fatal alerts can have other origins. Finally, is your server available on the public Internet. If so, and you post the URL, I’d be happy to take a look. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Self-signed server certificates are tricky, and I recommend that you avoid them. Rather, my advice is that you set up a test certificate authority (CA) and then have it issue a certificate to your server. That’s a path that works reliably. I use Certificate Assistant for this, as explained in TN2326 Creating Certificates for TLS Testing. Once you have this set up, you can install your CA’s root certificate as explained in QA1948 HTTPS and Test Servers. This process might actually work for your existing server certificate, but my experience is that it’s quite brittle. Still, you’re falling at the first hurdle right now: [quote='805559021, Bawenang, /thread/805559, /profile/Bawenang'] I have the .pem file [/quote] You need to convert this to DER. The ‘dragging to the simulator’ technique doesn’t work for PEMs. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I might’ve missed a memo here, but is the messages URLs scheme documented anyway? If so, please post a link to the docs so I can come up to speed. If not, see Supported URL Schemes. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t have any good news for you here )-: First up, we need to split this into a policy side and a technical side. The policy side is the domain of App Review. I don’t work for that team, so I can’t speak for them definitively. However, the published App Review Guidelines are pretty clear here: 2.4.5 Apps distributed via the Mac App Store have some additional requirements to keep in mind: (i) They must be appropriately sandboxed … Note Not all Mac App Store apps are sandboxed. Sandboxing became a requirement in the macOS 10.7.3-ish timeframework. If an app was first published before then, it might not be sandboxed. Which brings us to the technical side of this. It’s not possible to use the Accessibility APIs from a sandboxed app. The Review functionality that is incompatible with App Sandbox section of Protecting user data with App Sandbox is quite clear about this: Certain activities are forbidden by the operating system when an app runs in a sandbox … The restricted activities are: … Use of accessibility

I’ve seen reports from other developers but they didn’t include any bug numbers so it’s hard for me to track down what’s going on. I’d appreciate you filing a bug about this and then posting the bug number here. And yeah, you’ll have to use the website to file the bug (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I sent a support email to apple, I suggest to do the same Let me know how it goes