Have a question I couldn’t find any good answers to online, and before I burn a developer relations ticket, I was hoping maybe the community might known an answer. We currently have two apps, one with a subscription, with bundle id com.companyName.app1 and another with a different bundle id, call it .app2 In the future, we are hoping to migrate all users into one app, .app2, as this has way more content and a larger user base than .app1. However, we are not sure what effect this will have on those that have purchased subscriptions in .app1. We know that removing app1 from sale will retain the existing subscriptions and auto-renewals that were in place. But will we be able to restore these subscriptions somehow in app2? My research tends to lead me towards no, due to them having a different bundle id. But we do also keep a record of the user subscription in our cloud, so I’m not sure if we could somehow use that version of the receipt. TIA for any help!

My team has an app that uses BTLE heavily, and has been doing so successfully, including no issues continuing to receive data in the background and updating things in the app (for recording workouts). We have a BTLE write queue that only tries to write when the CBPeripheral.canSendWriteWithoutResponse property is true, or when we get the notification from the system in peripheralIsReady(toSendWriteWithoutResponse:). This is used as a means to rate limit data transfer, as we transfer files, as well as require that packets always arrive in the correct order due to blob encoding. However, we had a new requirement come in to periodically write data out to a connected peripheral. I noticed that as soon as the app was in the background, despite other delegate callbacks coming in, like didRecieveUpdatedValue:, neither the property canSendWriteWithoutResponse nor the delegate callback were called any longer. This meant our write queue didn't think it had permission to write, and packets would just stack up. The failure to deliver these updates didn't occur immediately after backgrounding, but did within 2-5s of backgrounding. If, when in the background, I ignore the changing of that property, and instead just write the data to the peripheral, it works! Can anyone explain why, despite other CBPeripheral callbacks happening when in the background, this one does not?