I am working on a project that some of the apps require bluetooth permission and some of them do not. The ones do not require bluetoth started asking for the permissions in iOS 13. I disabled the configs that are asking for bluetooth, but still, something triggers the bluetooth and iOS 13 shows the bluetooth prompt. Is there anyone experiencing the same problem? What are the solutions to fix this problem?
Solution:
So I realized that I was initializing the bluetooth in a main thread all the time. Instead of doing this, I did lazy initialization and fixed the problem.
If the projects are sharing a single code-base or have shared frameworks, that may be the source, in particular, the dependencies are a good place to look as Andy states above.
I know you stated that you disabled configs asking for Bluetooth, but I'd double-check the two Bluetooth LE options (Uses Bluetooth LE accessories or Acts as a Bluetooth LE accessory) in Background Modes under Capabilities. I'd also check the Info.plist file for Privacy - Bluetooth Peripheral Usage Description and Privacy - Bluetooth Always Usage Description but these shouldn't trigger the prompt, only add information when the prompt appears.
After checking configuration, I would search for import CoreBluetooth to see if there are any files that are using Bluetooth that you might not be aware of. Checking for the import narrows down the scope, then I'd look for CBCentralManager or CBPeripheralManager.
Related
I'm trying to set up a hobby project and I'm wondering - if my device uses Bluetooth Low Energy module, will this device show under the list of Bluetooth Devices under Settings for iOS? Or will my app have to search for this device specifically before connecting? If it doesn't show in the Settings, what type of Bluetooth module would I need for that?
No, you will not see your LE devices under Settings for iOS.
See LE best practices - your app should search for the LE device.
You only see the BT classic devices in that settings. However, only few protocols could be used without a required MFi chip, which is out of your scope for your Hobby project.
Use The CoreBluetooth on the iOS side for your app.
UPDATE per #Brejuro request in the comment below:
MFi coprocessor is required to be in your custom HW, which wants to communicate using the majority of profiles/protocols defined for Bluetooth Classic (not LE), e.g the pure RFCOMM. Coprocessor is used for the initial authentication - then, iOS knows that your custom HW is certified and allows to use it.
However, Apple will ask you for big money and your device needs to pass through Apple certification - that's why I told that this is out of the scope for any hobby project. You will also need to sign very restrictive NDA. However, you will get very very good documentation describing many details.
Built-in Bluetooth panel in iOS Settings app is actually a merge of two different things:
a list of known (paired) devices whatever the profile they use (so that you have a central place to unpair them),
a tool for discovering nearby devices to pair to.
Unpaired devices will only show in discovery list if they actually implement at least one profile that is recognized by core bluetooth services of iOS. Other devices are masked (user would not be able to do anything useful with them anyway).
If you hobby project is to do something related to built-in supported devices, like HID (keyboard, mouse, remote control, etc.), you will actually see them during discovery from Settings app.
If you create a device with a custom service, with your own Service Type UUID, it will not show in built-in panel, and your app will have to look for it for pairing. Once paired, device will show in settings.
Out of core services, you can also make compatible devices without being MFi. For instance, MIDI over BLE profile is such thing that gets recognized transparently by garageband and other music apps.
Using BLE and not BR/EDR, Authentication chip is only required for very specific profiles, like HomeKit.
An app we're working on was originally going to have Bluetooth enabled. After experimenting, we determined Bluetooth was not reliable enough for how we wanted to use it.
The settings in the app project were removed: Bluetooth background modes, and removed and deleted Bluetooth frameworks from the project. Deleted the app from the test device, cleaned and rebuilt. But the app is still showing up under Bluetooth sharing. This is under Settings, then Privacy, then Bluetooth Sharing. Also if the app is opened in Settings, Bluetooth appears as one of the options to "allow App to access".
My experience with the app reviewers is that any kind of inconsistency like this will raise flags during the review process.
Has anyone seen this before and fixed it?
I'm new to Bluetooth, but searching the web, I've found the following description of Bluetooth profiles:
"A Bluetooth profile is a specification regarding an aspect of Bluetooth-based wireless communication between devices. In order to use Bluetooth technology, a device must be compatible with the subset of Bluetooth profiles necessary to use the desired services. A Bluetooth profile resides on top of the Bluetooth Core Specification and (optionally) additional protocols. While the profile may use certain features of the core specification, specific versions of profiles are rarely tied to specific versions of the core specification. For example, there are Hands-Free Profile (HFP) 1.5 implementations using both Bluetooth 2.0 and Bluetooth 1.2 core specifications."
So, I have an MSP430 board with the CC256X Bluetooth module on it, and I want to transfer data between that device and my iOS device. Does that device always have to communicate with my iOS device using a Bluetooth profile? If so, could you please shed some light as to what the simplest profile to make this happen is? As far as my design constraints, all I want to do is press a button on my iOS application, and have that turn an LED on my board. Thus, I just need the board to react to a simple characteristic change.
Please check
profiles/SimpleProfile/simpleGATTProfile.c
and
profiles/SimpleProfile/simpleGATTProfile.h
That's as simple as it ever gets. Once you write a profile with service and characteristics, you just have to include it in your code and use them just like any other service and characteristic.
Coming to your requirement, you need to have a characteristic with write permission in your profile. When you press the button in iOS application, write a value 1 to this characteristic. This will trigger writeCB to your embedded application code. You can use
HalLedSet( HAL_LED_2, HAL_LED_MODE_ON );
to turn on the LED in this callback.
In reference to Dennis Mathews answer how do you specify Bluetooth Classic instead of LE on iOS? Is there a different api from Core Bluetooth Framework?
Joels there is a very clear way to use Bluetooth classic on iOS. It is with the External Accessory framework (it also includes direct hardware connections in addition to Bluetooth classic however).
You need to add the ExternalAccessory.framework and specify "App communicates with an accessory" in the required background modes inside your plist to get started. It should be noted however that with Bluetooth classic, the user must add your Bluetooth device from the System Bluetooth settings. It is only with Bluetooth LE that we are able to add devices from the app side.
Check out the docs on the External Accessory Framework
In response to your question regarding the MFi program, this should clarify:
I want to develop an iOS app that communicates with an MFi accessory. Do I need to join the MFi Program?
No. iOS app developers do not need to join the MFi Program. Everything app developers need is in the External Accessory Framework,
which is provided in the iOS SDK. To access the iOS SDK, please join
the iOS Developer Program: https://developer.apple.com/programs/ios/.
If you'd like to learn more, consult the MFi FAQ
If your external accessory doesn't need high bandwidth in the connection to iOS, and you wish to use (or must use) 2.x/classic BT, (instead of 4.x/LE/Smart, which is very low bandwidth but requires no MFi dancing) you may be able to communicate by emulating a BT HID keyboard in your accessory.
It's hardly optimal, especially since the HID reverse channel is pretty limited (I think to things like lighting the caps lock key in the basic keyboard configuration (HID page 7 mapping, if I recall correctly.) OTOH, if your primary task is to push data to the iOS device, sending the data as keystrokes would not be too awful. (and might even be seen as virtue during testing :)
HID devices can declare additional capabilities in table defined keymaps, but I'm not sure if an iOS app can get at those alternate mappings with sanctioned APIs.
I'm trying to help produce a location-specific iOS app that needs an external trigger to start audio playback when it approaches a given location within the building. (no GPS access)
Has anyone had experience doing something similar? One thought I had was to lay out some bluetooth "transmitters" (like an xbee+arduino) around the building, and if the iPhone's bluetooth was close enough to identify it, it would trigger the audio.
I've never worked with bluetooth or an application of this sort before, so any advice would be much appreciated.
Bluetooth would certainly work, although other methods might, too. The only downside to Bluetooth is that you would either need to work within the APple MFi program for standard Bluetooth or restrict the devices used to the iPhone 4s or later or the iPad 3rd Generation or later so you could use Bluetooth LE (Bluetooth 4.0).
Assuming you can use Bluetooth LE, it's not only possible, Apple demoed one such technology. Once you're signed up as a developer, check out Session 705, Advanced Core Bluetooth, from WWDC 2012. The ending demo is exactly what you're looking for, and the session describes how to do it and provides source code.