“eskimo”

It seems that you’ve already seen my standard spiel about this. I’ve included it below, for the sake of others that stumble across this thread but also so I can quote it. [quote='819061021, AppDevObb, /thread/819061, /profile/AppDevObb'] What is causing my requests to always require in-depth analysis … ? [/quote] I’m not sure I’d put it that way. Rather, it’s that the system is taking its time to “learn how to recognise” you submissions. [quote='819061021, AppDevObb, /thread/819061, /profile/AppDevObb'] is there anything I can do to prevent it? [/quote] We have some advice on that topic in the “Q&A with the notary service team” that I reference in my standard spiel. 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 rec

Some more hints and tips in this space: The easiest way to determine the actual calling conventions for a given function is to create a small project in Xcode that calls the function and then looking at the resulting assembly. The Product > Perform Action > Assemble command is super helpful in that case. But you can also run the program and choose Debug > Debug Workflow > Always Show Disassembly [1]. Apple documents its calling conventions in Xcode > Application binary interfaces. This is basically Arm’s Procedure Call Standard with a few tweaks. And one of this tweaks affects varags. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] It says something about me that I have a hot key for that (-:

Error 8 is .internal. This has come up on the forums a bunch of times, so I decided to write up my advice in Understanding NEHotspotConfigurationErrorInternal. [quote='819088021, Abel_Kefan, /thread/819088, /profile/Abel_Kefan'] Here's the logs: [/quote] That’s very hard to read. In future, please format such logs as a code block. See tip 5 in Quinn’s Top Ten DevForums Tips for advice on how to do that. 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. ps I think this is now sorted out, bug please do reply here if you continue to have problems. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

My standard process for debugging problems like is: Test with a new project, with a completely different App ID. If that fails, something fundamental is wrong. But if it works, test with another new project, but this time using the sample App ID as your original project. If that fails, then the issue is tied to the code signing setup for that specific App ID. But if it works then you know the issue like in the main project itself. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='879809022, FeiYehua, /thread/818161?answerId=879809022#879809022, /profile/FeiYehua'] Same problem for me [/quote] Is this for the same Apple Account you’re using to post here on the forums. If so, that Apple Account isn’t associated with any paid developer teams. If it’s some other Apple Account then you have a couple of options: You can either post here with that account so that I can check things based on that. Or if you can’t do that, seek formal help via Apple > Developer > Contact Us. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Consider this: Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x0000000102c799bc This typically means that the app trapped, that is, it detected an internal error and deliberately crashed. For example, if you force unwrap an option that’s nil, you’ll trap like this. Now look at the backtrace: Thread 1 Crashed:: Dispatch queue: com.apple.root.utility-qos 0 DIM … 0x102c6c000 + 55740 1 DIM … 0x102c6c000 + 128212 2 libdispatch.dylib … _dispatch_call_block_and_release + 32 3 libdispatch.dylib … _dispatch_client_callout + 16 4 libdispatch.dylib … + 32 5 libdispatch.dylib … _dispatch_root_queue_drain + 736 6 libdispatch.dylib … _dispatch_worker_thread2 + 180 7 libsystem_pthread.dylib … _pthread_wqthread + 232 8 libsystem_pthread.dylib … start_wqthread + 8 frames 8 through 2 are Dispatch (GCD) machinery. Frame 1 is your code, which calls frame 0, which trapped. To learn more about this you need to symbolicate frames 1 and 0. See Adding identifiable symbol names to a crash report. Share

Again, I recommend that you review tip 5 of Quinn’s Top Ten DevForums Tips. Your reply above is barely readable. Focusing on the crash report, it comes from a third-party crash reporter. I don’t trust such reports in general. See Implementing Your Own Crash Reporter for a detailed explanation as to why. And in this specific case it doesn’t contain the information I need. I was hoping to get an Apple crash report, ideally one in JSON format. As to what’s happening here: com.apple.CFNetwork.LoaderQ is the name of the thread on which URLSession runs its core functionality. CFNetwork is calling down to Network framework. Which is, in turn, calling down to the QUIC implementation. That’s crashing for some reason, but it’s hard to offer any insight given the very limited information in this third-party crash report (it has no OS version, no binary image list, no register state, and so on). If you can find an Apple crash report for this, I’d be happy to take another look. Share and Enjoy — Quinn “The Eskimo

[quote='879858022, hasii2021, /thread/818406?answerId=879858022#879858022, /profile/hasii2021'] I set up the file system as APFS case-sensitive. [/quote] I’ve seen that cause problems in the past. However, I don’t think that’s the case here. I created a case-sensitive APFS disk image, copied your zip archive to that, and repeated my tests there, and everything still worked. But, yeah, a disk image is a great way to test stuff like this. If you managed to figure out what’s causing this, please reply here with the info. I’m super curious. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Do you work in a managed environment? I sometimes see reports like by folks who work in high-security industries, like health or finance. Their network, Mac, or device is locked down in some way that breaks this tooling. It’s hard to offer specific advice in that case, because these setups are very site specific, but I do have a few general hints: If you have a Mac laptop, you can relocate it to a different network. For example, you might run this test at home. Rather than running the proxy on your main work Mac, run it on a ‘victim’ Mac. For example, I often have great success using Mac-on-Mac virtualisation. Test with a victim ‘device’ that’s unmanaged. Or if you test device is managed, try a different device, like your own personal iPhone. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='879813022, wuzihang, /thread/818722?answerId=879813022#879813022, /profile/wuzihang'] FB22081725 [/quote] Thanks for filing that. [quote='879813022, wuzihang, /thread/818722?answerId=879813022#879813022, /profile/wuzihang'] has [this] been routed to the appropriate Swift/Xcode engineering team … ? [/quote] Yes. [quote='879813022, wuzihang, /thread/818722?answerId=879813022#879813022, /profile/wuzihang'] [is] there is any information about which future Xcode version … ? [/quote] Even if there were, I can’t talk about The Future™ here on the forums. See tip 3 in Quinn’s Top Ten DevForums Tips. This lack of visibility is one of the reasons why I encourage folks with Swift compiler bugs to file their bugs via the Swift bug process. However, that’s not really appropriate here because you need an Apple framework, Combine, to reproduce it. But if you can find a way to reproduce the crash without that dependency, a Swift bug would make a lot of sense. ps In future, if you have existing case or feedback number

[quote='879950022, timboudreau, /thread/818192?answerId=879950022#879950022, /profile/timboudreau'] the industry has produced plenty of ways to run untrusted code in-process [/quote] Sure. And if the only issue were the host not being able to trust the guest, such techniques might be feasible. But in this case you have to worry about the guest not trusting the host. [quote='879950022, timboudreau, /thread/818192?answerId=879950022#879950022, /profile/timboudreau'] can using StoreKit in an AUv3 work at all? [/quote] There’s an obvious way to make this work: Have the user run the app. Which uses StoreKit to check for the purchase. And stores the state in an app group, or keychain access group [1]. Which the app extension checks. This requires that the user run the app at least once so that it can achieve, but that’s not particularly onerous. However, the real question is really about whether your app extension can call StoreKit. I don’t know for sure. I’m gonna research this and get back to you. Share and Enjoy

I don’t think so, but lemme double check and get back to you. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[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