restore purchases

As per the Suggestion, Created CLBackgroundActivitySession and CLServiceSession in foreground to keep Core Location active. Recreated those sessions on background launch/APNS. Persisted and restored fence definitions so CLMonitor can re‑register fences after background launch. But the restore only re‑registers fences that were already created before. If a fence is first created while the app is terminated and only launched in background, CLMonitor did not deliver the initial “enter” until a foreground session exists. Comparision with old CLLocationManager region monitoring: Old API (CLLocationManager region monitoring) is system‑managed. The OS keeps monitoring even when your app is terminated, and it can accept new region registrations in background because that API was designed around long‑standing background delivery. New API (CLMonitor with CLBackgroundActivitySession/CLServiceSession) is session‑based. Apple expects the session to be created in foreground and then restored in b

I am experiencing the same issue described here. If I bring up the AccessorySetupKit picker for ~10 seconds, the BluetoothCentral goes to disconnected. All peripherals also disconnect but I do not get notified (checking peripheral state will show disconnected) There is no recovery without restarting my app. This still reproduces on iOS 26.2 and iOS 26.3. I am ONLY using ASK paired accessories. No bluetooth scanning. With that said, I have a workaround. Disconnect all peripherals AND clear all references to BluetoothCentral before bringing up ASK picker Do not attempt to connect to newly added peripheral while ASK picker is on screen (that is don't use .accessoryAdded as a chance to connect because you don't want to create the central with ASK in use) After ASK is dismissed, recreate BluetoothCentral WITHOUT state restoration Go through all accessories (new and old) and get new references to peripherals + set new delegates etc. This seems to work reliably, but it seems really surprising that to use AS

Hello - As a next step, please try resubmitting the app update that supports the In-App Purchase functionality. In the submission notes, provide details about the related IAP products that were previously submitted (including specifying the Product IDs, etc.) - to make it clear to App Review that you need the app update and the previously submitted IAP products to be reviewed together, as part of your initial release of IAP support in the app. Please let us know if you need any further assistance. Thank you.

There have been some behavioral changes on N1 chip devices; especially in areas where the BT spec has not had a single way of interpreting things. We have been observing these changes and changing them back if appropriate and are considered regressions. So, the first thing you should do is to test all this in the latest iOS 26.3 and see if anything has changed from your earlier observations. Also, there would have been some changes on patterns of use that were never meant to work, but just happened to work, and those would have been corrected. For example, scanning without services is not supposed to work, and was never expected to work in the background. If you are scanning in the background without services, and whatever the Flutter library may have been doing to work around that limitation (if anything), and that has stopped working, you can consider that a bug that has been fixed. Similarly, advertising packets in the background have always been on a best effort basis. Also, it has always been possible th

IHello App Review Team, Thank you for your help. I can confirm the in-app purchase is now available and working correctly in the app, and the upgrade/restore flow functions as expected. I appreciate your time and assistance. Best regards, Magnus

We used to get this error, cause our products are set up in Monetization/In-App Purchase section, specifically non-consumable. We then switched to set up products in Monetization/non-