“eskimo”

[quote='884993022, rbmanian75, /thread/815676?answerId=884993022#884993022, /profile/rbmanian75'] is it allowed in sandboxed environment? [/quote] I’m not sure the App Sandbox is the main concern there. That code relies on implementation details and is thus unsupported. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='884933022, amepatil, /thread/769640?answerId=884933022#884933022, /profile/amepatil'] In iOS … only apps hosting their extensions can talk to it via XPC. [/quote] That’s true for custom extension points but not true for system extension points. If your app publishes a CTK appex, any app on the system can use that. It’s not completely silent — the first time the app uses a CTK appex the system will ask the user to allow that access, per the example in your first post on this thread — but it’s relatively low impact. But, yeah, if you trying to sidestep that alert by using a custom extension point, based on ExtensionKit, then you will bump into this limitation. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='885020022, HolgerTh, /thread/822534?answerId=885020022#885020022, /profile/HolgerTh'] Quick update [/quote] Thanks. I’d appreciate you adding these updates to your bug report (FB22476701). That’s where the folks investigate that bug will look for them. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t think there’s an actual problem here, largely due to the magic of Objective-C. Consider the small test code at the end of this reply. It declares the requestedMountOptions property without any availability, and I think that’s just fine. Lemme explain… I put this in an Xcode command-line tool project, set the deployment target to macOS 26.0, and compiled it. I then dumped its imports: % otool -L MyTool | grep FSKit % It doesn’t import any symbols from FSKit at all. That’s because FSKit is an Objective-C framework and all the stuff used by the class is either found at runtime by name or is a C-style declaration that has no runtime impact [1]. This doesn’t mean that it isn’t connected to the Objective-C runtime. If you run this command: % otool -o -v MyTool … stuff … you’ll see lots of connection points. However, Objective-C is super dynamic, so that stuff all gets resolved by name when your class is loaded. And the runtime on macOS 26.0 will happily ignore the fact that you’re claiming to implement a re

Argun and I have been talking about this issue privately, and he asked me to comment on this: [quote='884915022, Engineer, /thread/823017?answerId=884915022#884915022'] I will leave the discussion of why UI elements are sometimes not initialized for non-UI (background) launches to others [/quote] Yeah, that’s been confusing folks since we first introduced multitasking to iOS |-: When the system launches your app in the background, it may or may not instantiates your views. Whether it does is based on a wide range of criteria, stuff that’s changed in the past and may well change again in the future. For example, the system might want to refresh its snapshop of your app’s UI, in which case it has to instantiate your views in order to do that. Or it might be happy with its current snapshot, and thus not. Which brings us to this: [quote='884915022, Engineer, /thread/823017?answerId=884915022#884915022'] In general it is not a correct pattern to make app-wide non-UI functionality dependent on UI elements [/quote]

[quote='823269021, ARG_007, /thread/823269, /profile/ARG_007'] Anyone can explain this abrupt nonisolated(unsafe) change? [/quote] What version of Xcode has this problem? And what version of Xcode didn’t have this problem? It looks like you reproduce this with a small test project. What template did you start from? iOS > App? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

In-app purchase is only support for App Store distribution, so Developer ID isn’t a factor here. In general, you can’t run code signed with an Apple Distribution signing identity. See Don’t Run App Store Distribution-Signed Code. [quote='823308021, DexterC, /thread/823308, /profile/DexterC'] Is there any other way to get a properly signed and runnable .app for testing IAP? [/quote] Yes. Use an Apple Development signing identity whose certificate was issued by your paid development team (the same team you used to set up the Apple Distribution signing identity). Apps signed this way will talk the StoreKit sandbox, can use StoreKit Test, and so on. I can’t help you with the third-party tools you’re using, but to do thish in Xcode you: Navigate to Signing & Capabilities. Enable “Automatically manage signing”. Select your paid team is the Team popup. Select Development in the Signing Certificate popup. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo

[quote='823247021, Pushpak-Ambadkar123, /thread/823247, /profile/Pushpak-Ambadkar123'] Could you please let us know the estimated timeline for approval of our OHTTP relay request? [/quote] No, sorry. While I can see these requests, I’m not involved in the approval process. Having said that, the fact that you submitted a request for a test app — with bundle ID com.example.apple-samplecode.SimpleURLFilter[…] — rather than a real product is a concern. My advice is that you only submit an OHTTP relay request once you’ve got things working with the test environment to the point where you can justify the effort required to create a real app to reference in your request. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='882607022, DTS Engineer, /thread/817264?answerId=882607022#882607022'] I recommend that you continue testing with new macOS betas as we seed them [/quote] We recently started seeding macOS 25.5b2 (25F5053d). As I mentioned above, the situation with this bug is complex, so I can’t say definitively that this will fix your problem. However, I’d appreciate you retesting with the latest beta seed and posting an update here with your result. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

eddiewangyw, Thanks for sharing your experience with this. [quote='884115022, eddiewangyw, /thread/820379?answerId=884115022#884115022, /profile/eddiewangyw'] ANE access is unreliable without a session [/quote] Yeah, that was one of my concerns. I’m also concerned about the GPU itself, because it’s not clear to me whether that’ll be affected by the window server lifecycle. Earlier I wrote: [quote='883507022, DTS Engineer, /thread/820379?answerId=883507022#883507022'] I’m still working on this. [/quote] I’m starting to make some progress here, but I’ve still nothing concrete to share. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='884845022, Pavel, /thread/823101?answerId=884845022#884845022, /profile/Pavel'] To avoid confusing users with unnecessary UI, this container app must run in the background without a Dock icon. [/quote] This is something I specifically recommend against. Your container app should have some sort of UI. Ideally that UI should allow the user to enable and disable your product (subject to appropriate authorisation). If you want something that does processing in the background without a UI, do that in: Your launchd daemon, if the work doesn’t require a user context Or your launchd agent, if it if does Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='884819022, DTS Engineer, /thread/823121?answerId=884819022#884819022'] so blocking in a signal handler has a HIGH probability of creating deadlocks [/quote] I want to emphasise just how tricky this is. Your signal handler is not allowed to: Use Swift Use Objective-C Allocate memory Touch the dynamic linker And if you block in your signal handler then all the unblock code paths are subject to the same limitations. This is really hard to get right. I talk about this, in a different context, in Implementing Your Own Crash Reporter. This links to Async Signal Safe Functions vs Dyld Lazy Binding, which is a very sharp edge case. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='884793022, Cygno, /thread/822109?answerId=884793022#884793022, /profile/Cygno'] How long could I expect this to take? [/quote] There’s no official answer to that. Unofficially, based on my experience with folks here on the forums, it typically takes a day or two. If your requests are stuck for more than a week, write back here and I’ll take a look. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com