You can use BGTaskScheduler, especially BGProcessingTask to perform long running actions, including CoreBluetooth data transfer, but you can't have defined schedules for background tasks. They will be run by the system whenever it is appropriate to do so, and not being run is also a possibility.
You may want to read about iOS Background Execution Limits before deciding to depend on background tasks.
In any case, I am not sure how this will help. With Bluetooth state restoration, and for being woken up from suspended state there is indeed a ~10 second time limit, but that is per Bluetooth event, not for the whole task you are trying to do.
If you need a minute to download the whole set of data from the device, you would not be doing that all at once anyways. The device will be writing the data in pieces, and as long as the subsequent writes to a notifying characteristic happens within the ~10 second limit, your app's time will be topped up. So, as long as you take less than 10 seconds to process each packet, and the device sends each packet without delay, you will be able to continue running until the data is completely downloaded - packet by packet.
Then your app will be suspended (and perhaps terminated), and when there is new data to be downloaded, the process will start over.
Just that, once suspended or terminated, your app will depend on the device to take an action to be relaunched or woken up.
Background tasks will (may) launch your app on its own where you can try to download from the app, but unless the device is ready or in range, there isn't much to be done. So, controlling all this from the device is the easiest.
All of the above assumes your app is Central and the device is the Peripheral in this pair. If it is the other way around, I suggest to switch that around, as the app as peripheral will not be able to do much on its own.
Argun Tekant /
WWDR Engineering /
Core Technologies
