those other threads are locked, so this is my success story here:i also got that infamous 1048 error today. in my case there were several apple-id in Xcode's preferences. the "relevant" apple-id (the one related to the app in question) was associated with the single company only (it was an account holder FTM) and didn't have any pending contracts to accept (neither in developer.apple.com/account nor in appstoreconnect). it did have (and still does) a pending "paid apps" contract to accept - i didn't have to do anything about it at the end of the day, it is still pending.there were other "irrelevant" apple-id accounts in Xcode preferences. some dormant. one notable account was active and it was associated with multiple companies. among the companies was the company of the above "relevant" apple-id, and some other companies, which might had pending contracts to accept (didn't check those).my solution was - remove all apple-id from Xcode preferences -- but one that is actually used for the app in question. in my case there were two such apple-ids - the first one that was the account holder (and that didn't have other associated companies) and the second one (that had many associated companies). to not give it a chance i decided to use the first one. it helped and after that the app was notarized without errors. looks like xcode bug.

partially answering myself: i had to specify -fcoroutines-ts in other C++ flags, after that the following test worked:https://wandbox.org/permlink/Dth1IO5q8Oe31ew2ftm, i also specified C++17 and libc++ in compiler settingsanyone has a woring example that uses co_await in Xcode?

>> ImportantiPad apps running in macOS cannot use the AVFoundation Capture classes. These apps should instead use UIImagePickerController for photo and video capture. <<REALLY?!AVFoundation works in normal mac apps.AVFoundation works in normal iOS apps.but it doesn't work in maccatalyst?is this a current limitation that is going to be addressed soon or what?can i somehow compile, say, a separate macOS library and use it in maccatalyst app to overcome this limitation?in our case that is a show stopper... we do a skype type messanger. i do not think it is realistic (or sane) to rebase our AV camera code on UIImagePickerController... the app is otherwise ok on mac (we were actually surprised by the speed of bringing it to mac, and overall quality was acceptable, so quality / time ratio was awesome), but inability to do video calls is definitely a dead end for us... our options:- maccatalyst (but no video calls) 😟- a separate mac app using swiftUI (and later backport it to iOS when time allows). it feels raw at the moment but we shall give it a try 😕- a separate mac app using traditional Cocoasad

what is the right Apple forum for a question: "what is the maximum number of open sockets on macOS?"

>This whole discussion assumes that every network connection requires a socket. This isn’t the case on most Apple platforms, which have a user-space networking stack that you can access via the Network frameworkQuinn, thanks, that's interesting.Then maybe it is possible to create an alternative implementation of user-space socket API on top of Network framework, so that the socket API and apps that use it also benefit?Obviusly i had macOS in mind, hard to imagine C10k server running on iPhone or apple watch 🙂

crossplatform to unix based systems is preferred, although if i have to use mac specific code i can stomach that.ideally i want my internal api (based on aio or whatever else) to be exposed in the following form (pseudo code):void myopen(file, callback)void myread(ref, callback)void mywrite(ref, callback)void myclose(ref, callback)void mydelete(file, callback)void myrename(file, newName, callback)... etcthis is for files only (not sockets).the calls shall not block the current thread and callback shall be called eventually (ideally on the same thread) once the operation is completed.in case of "myopen" i want it to asynchronously call the callback when the file is opened. for example if another part of my app or a different app opened the file with write permission and i call "myopen" on this file, i expect the callback to be called only after that other file reference is closed. on macOS open call may lead to "do you want the app to access that file" dialog, nanurally callback shall be called only after user has granted/or rejected that permission.

maybe that's a huge undertaking... but calls like "select" can be wrapped as well, i believe. normally user apps do not care (or even know) whether they are talking to a system version of read/select, etc or some wrapper library - provided the API exposed is the same.

thank you,good point about thread explosion, very easy to miss. last i tried i was able creating a few thousand, but i had to reduce the stack size and probably creating 10K threads is not a good idea anyway.i am not rulling out dispatch_io... however, if i use aio_read / write can I use signals as a means to be notified about operation completion? what thread are those signals getting called on, if you know?

> This whole discussion assumes that every network connection requires a socket. This isn’t the case on most Apple platforms, which have a user-space networking stack that you can access via the Network framework [1].what are the underlying kernel/system primitives/APIs Network framework using? i assume the Network framework itself is not open source, is the underlying layer opensource?

> why would you want to [use aio with signals]i am enumerating available options. so far found these:- blocking read in a thread plus a thread pool- blocking read in a dispatch queue (similar to the above, apple onlyish)- dispatch_read (uses blocking "read" internally on a thread, apple onlyish)- PBReadAsync (obsolete, calls completion on a thread, apple only)- aio_read plus signal (signals are hard to use)- aio_read plus polling (poling feels bad)

this is unfortunate for us (and seems like a resource waste for Apple) when we want to do a bug fix or few during step (5) - in order to do that we have to wait for TF approval despite of the fact that the version just passed AppStore approval, which is a more thorough check.

filed as FB7875053 interestingly changing: var snapshot = self.dataSource.snapshot() to:var snapshot = originalSnapshot fixes the issue. all in all this looks like a "value-typeness" bug in NSDiffableDataSourceSnapshot.

example of behaviour that doesn't take identity into account (remove spaces): shorturl . at / ltNQ5 corrected version that takes identity into account (remove spaces): shorturl . at / bovzT

it would be simpler on the usage side is diffable data source relied on explicit item identities (like SwiftUI does). then it would be able to figure out that the two different (as per isEqual) items are indeed the same item (same ID) with a changed content and thus issue the relevant "reload" of that snapshot item (*) without me having to do that manually/explicitly. (*) this is more obvious when the item in question is also moved, in which case the resulting animation shall be move + change, rather than "teleport" as in the first video above. in regards to changing cell heights: i figured that calling beginUpdates + endUpdates is enough for UITableView to notice the change in height of a particular cell i am modifying without reloading that cell. is that correct approach?

I believe this enhancement can be done in a pure additive manner, so the old clients would still work as they are now and the new clients who opt-in into that feature (e.g. by marking the model items identifiable) would benefit from it. see the round numbered FB7973000 which has an example of a possible implementation.