“eskimo”

[quote='880046022, premak, /thread/818636?answerId=880046022#880046022, /profile/premak'] All the requests are processed. [/quote] Cool. [quote='880046022, premak, /thread/818636?answerId=880046022#880046022, /profile/premak'] Will this (in-depth analysis) can trigger again on our new uploads? [/quote] Possibly. Lemme quote my previous reply: [quote='879797022, DTS Engineer, /thread/818636?answerId=879797022#879797022'] You can expect that most uploads will be notarised quickly. [/quote] [quote='879797022, DTS Engineer, /thread/818636?answerId=879797022#879797022'] Occasionally, some uploads are held for in-depth analysis and may take longer to complete. [/quote] [quote='879797022, DTS Engineer, /thread/818636?answerId=879797022#879797022'] As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. [/quote] We don’t document the exact criteria that determine whether a request is sent down the in-depth analysis path, something I was talking recently in a different

Albert asked me to chime in here: [quote='818807021, ImaRobot, /thread/818807, /profile/ImaRobot'] I understand that apps submitted to the App Store must use Secure Transport as the TLS backend on iOS. [/quote] That’s not right on a couple of levels: AFAIK App Review has no requirement that you use a specific TLS implementation [1]. Secure Transport is deprecated, so it’s not the recommend path for anything (-: We generally recommend that you use the built-in networking stack. You can access that using Network framework. See TN3151 Choosing the right networking API for more background and links. Note Network framework does support TLS-PSK. This recommendation is particularly relevant for TLS, where users expect the TLS behaviour of your app to match the TLS behaviour of the system as a whole, for example, in Safari. However, that’s only applies to TLS-PKI. TLS-PSK requires prior agreement between the client and the server, by definition, and so compatibility isn’t a concern. Thus, while you can use Network fr

I’m confused. To start, I’m concerned about this path: [quote='818938021, chapo213, /thread/818938, /profile/chapo213'] I decided to rely only on the Team Identifier. [/quote] I don’t understand how you can trust anything about the code signature, and that includes the Team ID, if you don’t first validate the code signature. Next, in cases like this I usually ask about the big picture. And on that subject you wrote: [quote='818938021, chapo213, /thread/818938, /profile/chapo213'] In my application I validate the authenticity of my own binaries [/quote] Programs can’t authenticate themselves. If an attacker is able to modify your code, they can also remove or subvert any checks that you add. What problem are you trying to solve here? ps On iOS I usually point folks at App Attest, but I’m presuming that you’re on the Mac. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

First up, make sure your external drive is formatted as APFS (or HFS Plus). If you do a lot of Mac-specific stuff on, say, FAT32, you will eventually run into weird problems. Second, there are a number of things you can definitely move to an external drive: Xcode itself The three items (Derived Data, Archives, Compilation Cache) listed in Xcode > Settings > Locations. After that things start to get more complex. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Just to confirm, you’re talking about iOS, right? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

There are some key things to keep in mind here: Your provisioning profile acts as an entitlement allowlist. Your .entitlements file is source code that feeds into the code signing machinery. The entitlements claimed by your app are baked into the app’s code signature. Likewise for embedded app extensions, DEXTs, and so on. The fact that you’ve been granted access to a capability lets you create an provisioning profile that authorises your use of the associated entitlements. However, you still have to claim that access, by updating your .entitlements file. You can then verify that the claim and the profile are in sync using the codesign and security tools, respectively. For the exact commands, and more general background, see TN3125 Inside Code Signing: Provisioning Profiles. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m not aware of any way to do this from the UI, or from tools like altool. However, you can certainly do it using the App Store Connect API. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='818948021, Ere0n, /thread/818948, /profile/Ere0n'] this private key is clearly stored in the local P12 file [/quote] That’s not the caes, at least on macOS. SecPKCS12Import behaves differently on iOS and macOS: On iOS it imports the PKCS#12 file and gives you back an in-memory digital identity. On macOS, it defaults to importing the PKCS#12 file to the default keychain, and gives you back a digital identity that references that keychain. If you want the iOS behaviour on macOS, you have to opt it to that by setting kSecImportToMemoryOnly. Having said that, I’m not sure that continuing to re-import the file is the right option. In general, it’s better to store secrets in the keychain rather than in a .p12 file on disk. But that raises the question of which keychain. I generally recommend the data protection keychain, in which case the path forward is: Get an in-memory digital identity. Call SecItemAdd with the kSecUseDataProtectionKeychain to add it to the data protection keychain. For a detailed explan

I like galad87’s take on this. Rather than worrying about other folks’ apps, I suggest that you on your own products. And in that case the messaging is super clear: If your build system or final software depends on Rosetta, you should be working to break that dependency as a matter of priority. And if you have technical questions about how to do that, please post them here on the forums. We’re hear to help. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Unfortunately I don’t have any good answers for you here. The correct escalation path — as described here and in the error itself — is DevPrograms, so you’ll have to continue pushing via that channel. [quote='818822021, Kuroglo, /thread/818822, /profile/Kuroglo'] Has anyone experienced a similar situation with a new account? [/quote] I’d also love to hear other folks’ experience with this process. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Let’s focus this discussion on your original thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Let’s focus this discussion on your original thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I was able to get this working today: On my Mac, running macOS 26.2, I downloaded the Mac version (mitmproxy-12.2.1-macos-arm64.tar.gz). I unpacked it. I moved it to the Applications folder. And launched it (which opens a Terminal window). It creates its CA (certificate authority) certificates in ~/.mitmproxy . I check that was all present: % ls -l ~/.mitmproxy total 48 -rw-r--r--@ 1 quinn staff 1172 13 Mar 12:05 mitmproxy-ca-cert.cer -rw-r--r--@ 1 quinn staff 1035 13 Mar 12:05 mitmproxy-ca-cert.p12 -rw-r--r--@ 1 quinn staff 1172 13 Mar 12:05 mitmproxy-ca-cert.pem -rw-------@ 1 quinn staff 2384 13 Mar 12:05 mitmproxy-ca.p12 -rw-------@ 1 quinn staff 2847 13 Mar 12:05 mitmproxy-ca.pem -rw-r--r--@ 1 quinn staff 770 13 Mar 12:05 mitmproxy-dhparam.pem On a victim device running 26.2… IMPORTANT This process involves changing system-wide trust settings. Given that, it’s not appropriate for a device you actually care about. I launched Safari and open a private browsing tab (this helps with subsequent steps). In Sett

[quote='879687022, DTS Engineer, /thread/818501?answerId=879687022#879687022'] If that doesn't help, try to remove the iCloud capability [/quote] Yeah, that’s what I recommend you do first. As Ziqiao says, it’s all disabled, so removing it doesn’t cost you anything. And I think it’ll get your app building again. Once you’re back in that stable state, you can add it back in and let Xcode’s automatic code siging do its thing. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='879742022, rsfinn_halcyon, /thread/818568?answerId=879742022#879742022, /profile/rsfinn_halcyon'] I would enter the service name for the single listener under both keys in the Info.plist file. [/quote] That’s not going to help, and it could hurt: It’s not going to help because you can achieve the same effect by putting that name into either of the spots in your Info.plist. It could hurt because… well… it’ll be exercising code paths that are very likely to be untested. [quote='879742022, rsfinn_halcyon, /thread/818568?answerId=879742022#879742022, /profile/rsfinn_halcyon'] I'm seeing that refer to Mach service names and the like. [/quote] XPC is implemented on top of Mach messaging. In some contexts an XPC named endpoint name is synonymous with a Mach service name. For example, when you use XPC in a normal launchd daemon, you put your XPC endpoint name into the MachServices property. However, there are places, like XPC services, where using Mach messaging directly, rather than XPC, is not viable. Aprop