eskimo

I’ve responded on your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

In cases like this its important to distinguish the Debug/Release build configuration from Development/Release signing. See Isolating Code Signing Problems from Build Problems. Once you do that, you’re be in a better position to debug this issue. Also, my experience is that the vast majority of broadcast and multicast problems are caused by folks not using BSD Sockets correctly. See Extra-ordinary Networking > Broadcasts and Multicasts, Hints and Tips. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='867287022, Mikesch8764, /thread/807578?answerId=867287022#867287022, /profile/Mikesch8764'] Unfortunately I do not have a separate Mac to test it. [/quote] One option here is to install that beta into a VM and test it within the VM. Last I checked you can’t use App Store, and that includes TestFlight, in a VM, but you should be able to run a development-signed build from Xcode. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I very much doubt you’ll get an answer to that. See tip 3 in Quinn’s Top Ten DevForums Tips. I’m absolutely certain that I can’t answer that. My knowledge of Bluetooth is quite limited. Given that, I’m going to close this thread and I recommend that you post any future replies to that other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This same question came up in another thread, and I figured out sneaky way to implement it with public APIs on iOS. See my response here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Earlier I wrote: But, honestly, it sounds like a fun weekend project And indeed it was (-: Pasted below is some iOS code that is able to detect how your code is signed using only public APIs. To do this, it uses a sneaky combination of XPC loopback and XPC peer requirement checking. This code comes with a bunch of caveats. Read the doc comment before you use it [1]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] By my count the doc comments represent well over half the total number of lines (-: import Foundation extension CheckSelfEntitlement { /// Checks whether the current process claims the get-task-allow /// entitlement. /// /// - warning: As explained below, you shouldn’t use this routine but /// instead should use ``isGetTaskAllowTrue()``. This routine exists solely /// to illustrate the following point. /// /// This routine checks for the presence of the entitlement, rather than /// checking for it being present

[quote='866973022, SoumyaMahunt, /thread/807924?answerId=866973022#866973022, /profile/SoumyaMahunt'] I think more appropriate solution for me will be deciding based on the way app was signed [/quote] OK. That’s easy to do on macOS, using SecCodeCopySigningInformation. On iOS the story isn’t as rosey. Historically there’s been no supported way to do this on iOS. Thinking about this today, I believe that recent iOS API additions make it possible, albeit in a non-obvious way. I got a proof of concept working today, and it looks promising. Unfortunately I don’t have time to flesh it out. But, honestly, it sounds like a fun weekend project so, with any luck, I’ll have an answer for you on Monday. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for the extra info. And that’s for filing FB21094920. That’s likely to be the best path forward with this. The behaviour you’ve described seems to match that on macOS 15. So, it’s not clear to me whether you’re reporting a regression? Or just a general issue with the API? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='867077022, DTS Engineer, /thread/808006?answerId=867077022#867077022'] It's possible that the keychain APIs might track lock state more closely [/quote] They do not. Using the data protection state as a proxy for the device lock state is a mistake. There are numerous ways in which this can fail, with the biggest one being that it’s a complete non-starter if the user doesn’t have a passcode set on their phone. There’s no supported way to track the device lock state specifically. If you’re building a VoIP app then, as Kevin noted, CallKit is the recommended way to wrangle you’re UI. If you’re not building a VoIP app, please clarify your goals so that we can see if there are any good options. What are you actually planning to do with this information? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='866998022, imaier, /thread/807154?answerId=866998022#866998022, /profile/imaier'] Does it need the is-Beta-App flag? [/quote] No. My expectation is that this wouldn’t be set. And yes, that flag is primarily associated with TestFlight. [quote='866998022, imaier, /thread/807154?answerId=866998022#866998022, /profile/imaier'] The code signing info from launchctl procinfo looks exactly like yours [/quote] Interesting. If, yesterday, you’d made me guess as to this result, I would’ve guessed the opposition. This results rules out my main theory as to what’s going on, namely that your app group was causing your entitlements to get invalidated. This is something I talk about in the Entitlements-Validated Flag section of App Groups: macOS vs iOS: Working Towards Harmony. And that leaves me out of ideas. My best guess right now is that this problem is the result of the different install machinery used on iOS and macOS. Well, the lack of install machinery on macOS, where Xcode just constructs the app and launche

[quote='866975022, nikhil2701, /thread/807854?answerId=866975022#866975022, /profile/nikhil2701'] What options do I have with NetworkConnection in that case? [/quote] Use TLS-PKI. To start you out, lemme point you at two posts: TLS for App Developers TLS For Accessory Developers The first defines key terminology. The second offers some suggestions for how to deploy TLS in local environment. While TLS-PSK is an option in that context, it’s not required. Indeed, most of that post covers options that use TLS-PKI. Regarding the better path and viability handlers, these are conceptually the same as the equivalent constructs in the old APIs, so you can look for information about those old APIs and map that to this API. The better path handler is typically not necessary in a peer-to-peer context. It’s more commonly used to handle the switch between WWAN and Wi-Fi. See Extra-ordinary Networking > Network Interface Techniques > A Better Path. OTOH, a viability handler is a good idea in most cases. I actually hav

Thanks for confirming that. But it leads to another question. If you’re no longer a member of a paid team, you can’t publish apps on the App Store. Given that, what are you planning to do with this App Store Connect API key? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’ve still no info to share on that front. Realistically, if something changes, that’ll show up in Feedback Assistant, not here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='808036021, Sandya, /thread/808036, /profile/Sandya'] I submitted a Feedback including a minimal reproducible sample project: [/quote] I got your crash report from that. In that I see this: Exception Type: EXC_BREAKPOINT (SIGTRAP) which strongly suggests that your app is crashing due to a trap, that is, some code has detected an inconsistency and deliberately crashed the process. The crashing thread looks like this: Thread 3 name: Dispatch queue: com.apple.NSXPCConnection.user.com.apple.FontServices.FontProviderLoader Thread 3 Crashed: 0 libdispatch.dylib … _dispatch_assert_queue_fail + 120 1 libdispatch.dylib … dispatch_assert_queue$V2.cold.1 + 115 2 libdispatch.dylib … dispatch_assert_queue + 107 3 libswift_Concurrency.dylib … _swift_task_checkIsolatedSwift + 47 4 libswift_Concurrency.dylib … swift_task_isCurrentExecutorWithFlagsImpl(swift::SerialExecutorRef, swift::swift_task_is_current_executor_flag) + 355 5 InstallFonts.debug.dylib … closure #5 in ContentView.register(scope:) + 96 6 InstallFonts.d

We’re currently discussing this issue in this thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com