i did find this clear purchase history for true sandbox accounts (which doesnt seem to work sandbox purchases made with a real apple id by the way... something not obvious, or maybe of course operator error which is probable). and while clear purchase history does seem to initially clear the purchases, they seem to be cached somehow and so when you purchase, you get all sorts of old purchase data back, and then your app is in some odd state with respect to subscriptions. testing subscriptions seems to be one of the worst issues in app development these days. a tester needs to be able to clear everything reliably and re-start from a reliable un-purchased state with no garbage. it seems to involve deleting the app and re-installing from test flight, but a lot of times, old cached stuff seems to get pulled in to the app even if you do that. seeing that subscriptions is one of the main ways for app developers to make money, it should be the easiest and smoothest process to add the code for them and test them. redirect all that UI open glass effort or whatever it is called to purchases. we didnt need open glass. we need super reliable purchase flows and testing.

FYI, i i think found the option in iphone settings, but since i was using a real apple ID for test flight testing, that real apple ID doesnt show up as way to clear test flight purchases. it only shows me an old sandbox id i had used for old work.

problem was app being signed with a dev profile under a different account even tho bundle id was correct.

seems to be working again (6/28/2023)

apple Really needs to improve its in-app purchase system from the developer side, especially anything involving subscriptions. it is far too complicated. there is no reason for it to be so complicated. ordinary developers have to deal with the most obscure APIs... this is how to make money in apps! subscriptions! it should be the smoooothest part of development! they spent a ton of money making Swift and SwiftUI to make things easier and better, yet ObjC and UIKit isnt that bad once you learn it. however, IAP...holy guacamole it's bad.

wow that is great info! this will be great to win some friendly wagers among my math pals, haha.

FYI i deleted the app container and re-launched and it worked (this is mac catalyst) i suspect some mac window settings like position etc are stored in there and may have gotten trashed due to repeated launching & killing of the app when in the debugger e.g. look for the directory ~/Library/Containers/yourappbundleid get rid of it make sure first there is no data you need in there :)

seeing the same message in debugger for mac catalyst app: Application violated contract by causing UIApplicationMain() to return. This incident will be reported. any resolution on your side>

FYI as a temp patch we added some script lines to copy *.h files to where the build wants to look for them based on analyzing the build output Compile steps that were failing. and there was one case where we added a couple of extra header paths manually to the RNSVG module Xcode proj file. unfortunately, with the yarn package manager and the cocoapods package manager working simultaneously, it is not obvious where the header paths need to be modified. this, coupled with module maintainers sometimes changing project folder structures in a breaking manner = trouble. we havent figured out why the new build system would not respect the same header path rules as the old build system. that is also non obvious.

Non optimized workaround to above thread serialization problem w/ concurrent thread uses of drand48. The key is the __thread keyword. If you just make these __thread variable static or global, you see similar slowdowns. My code does not depend so much on pure random numbers so this is good enough to get rolling. There may be a better solution. #if 1 const int s_nrandoms = 10000; __thread double s_someRandoms[s_nrandoms]; __thread int s_init = 0; __thread int s_lastRandomIndex = 0; double drand48x() { if (!s_init) { for (int i = 0; i < s_nrandoms; i++) { s_someRandoms[i] = drand48(); } s_init = 1; } s_lastRandomIndex++; if (s_lastRandomIndex > s_nrandoms-1) s_lastRandomIndex = 0; return s_someRandoms[s_lastRandomIndex]; } #define drand48 drand48x #endif

i think i have traced the problem to drand48() system call random number generator which i use extensively it seems like when you use the drand48 function a lot in the block sent to dispatch, the various threads that run the block get serialized or otherwise jammed up because of this function, so your code doesnt speed up the the expected amount when you dispatch concurrent blocks and just runs the same speed or slower as on 1 thread (slower due to the extra overhead of other threads, dispatch, thread syncing, etc) the thing i found is that this slow down doesnt seem to show up in the Instruments app. it shows a little bit of drand48 taking up CPU as expected, but not huge.... since it is not using CPU power and is just waiting for other threads to handle memory access, i would guess. such waiting may show up in some portion of instruments i didnt look at. this post seems to get into the details of why this is occurring: https://stackoverflow.com/questions/22660535/pthreads-and-drand48-concurrency-performance will post a workaround. tentatively working on pre-generating some randoms in per-thread arrays or a global array using a per thread index. if you use a global index to pull from the pre generated randoms, it shows a similar slowdown as drand48

I guess another question would be, if we set networkAccessAllowed to NO would we get a reduced size (local to device) media or would we get nothing or error? (E.g. in our original requestContentEditingInputWithOptions call)  PHContentEditingInputRequestOptions * options = [[PHContentEditingInputRequestOptions alloc] init];                    options.networkAccessAllowed = YES; doc doesnt mention this issue: https://developer.apple.com/documentation/photokit/phcontenteditinginputrequestoptions?language=objc

another question has arisen on this issue. the PHImageManager seems to only return a UIImage. however, the noted API above requestContentEditingInputWithOptions works for live photos and videos also (and our code is using it for that) is there is there a similar fast replacement we can use for live photos and videos? e.g. to avoid the long download from icloud and just use local editions of these other media types? thanks again!

if anyone has this issue, this seemed to be our problem: the iMessage switch in message settings has to be On for both devices when sending. if one device has iMsg off, live photos come thru as regular photos. if any one has any other ideas how to transfer live photos between users, that would be helpful.

Added note: in the Settings for iCloud under Optimize storage, it mentions: "If your phone is low on space, full resolution photos and videos are automatically replaced with smaller, device size versions. We want the smaller device size versions." Anyone know how to get these from photo kit to avoid the big icloud download delay?