good morning, I decided to reset my dev environment as I have developing for several years and never reset it, this cured many ills, I had many stale share zones and lots of errors from those zones. Once I reset the environment everything worked as designed. thanks again for the support

thank you I am working on getting the sysdiagnose now thanks again

thank you very much for this guidance

looks like all three are now approved, thank you

I just noticed that before I started to upload a new version that two of the subscriptions are now approved (I have not taken any action yet) the last one monthly still says developer action needed. I can see the paywall on my app in the app store for the two that are approved as well, I will start to upload a new version anyways

Thank you very much I will start on this tonight, much appreciated

Update: Still unable to locate the Purchases section under version 1.0.1 to attach the subscription. If anyone has a screenshot of where this appears in App Store Connect UI, that would be incredibly helpful. I dont know how to "attach" my subscriptions to the binary the UI element is not seen, thanks again

I cant find the menu item to attach them and I think I am in somekinda of edge case, I am starting to create a 1.0.1 and cant find the attach button for the subscriptions in there as well. thanks in advance I am certain this is all me, just need a little help thanks all

the message is Notes from App Review Guideline 2.1(b) - Performance - App Completeness Issue Description We have returned your In-App Purchase products to you as the required binary was not submitted. When you are ready to submit the binary, please resubmit the In-App Purchase products with the binary. Next Steps Learn more about offering In-App Purchases in App Store Connect Help. Resources Learn more about app completeness requirements in guideline 2.1.

I think My subscription is stuck in Developer Action Needed after being rejected for no binary, and I can’t attach it to my new version.

thank you and yes it was a kind reply, its my first rodeo, I appreciate the effort apple puts in, I think I understand now thank you for your reply

that info update seem to have done it thank you

thank you for your rapid response, when sharing a app object using CKShare between two devices in my beta in testflight I get that message when the second device tries to open the share (cant find the app in the appstore which is true sinces its not in the appstore yet)- beta is "prod" in testflight I wonder if that is confusing for ckshare?

thanks again that is very helpful, your other article was very helpful as well thanks

Thanks so much, @tbartelmess1—this is super helpful, and really appreciated a bit more context from our app: App context (what we store) The blobs we persist will be user-generated cruise photos, we would downsize those to more manageable size as iphone format photos can be quite big, but they would still be in the 1-3 mb after downsizing Realistic volume per active user: a few hundred images/year; heavy users could reach low thousands over time. Decision: use Core Data Binary Data + “Allows External Storage” We’ll keep originals as Binary Data (Allows External Storage) so Core Data handles externalization transparently, my philosophy has always been to offload as much work to the system services as possible. We’ll keep thumbnails as well inline in coredata (let coredata decide but likely will be inline (blob)). CloudKit mirroring We’ll rely on NSPersistentCloudKitContainer mirroring; we understand CloudKit decides when an attribute becomes a CKAsset independently of Core Data’s externalization threshold. That’s fine for us. Practical assumption: for us, the full binary will still transfer when needed as part of the asset, so our bandwidth/latency plan is to (a) compress originals to HEIC/JPEG on-save, (b) show thumbnails first, (c) lazy-load the full image only on demand. Low-disk behavior We’ll provide a user-visible “Free up space” control that: Safely deletes locally cached display sizes if space is low (thumbnails kept). Leaves Core Data records intact so we can re-hydrate from CloudKit when needed. For memory, we’ll downsample on decode and avoid loading multiple full-res images simultaneously. Why not manual URLs again? We originally tried manual file URLs to keep the SQLite file tiny, but post-update brittleness and sync edge cases crept in (missing files, path changes, race conditions). Using Core Data + CloudKit’s native path feels safer. Thanks again for the clear pointers and links. Your note about memory and disk-pressure tradeoffs was a missing piece—splitting thumbnails/originals and letting Core Data + CloudKit do their thing looks like the right balance for us. — Paul