I am working on an mbed powered Bluetooth Low Energy project. I have been developing various GATT services, however, I have now found my project has got "stuck" on a previous service. What ever program I download onto the device, a Service is broadcast with the name "HRM_SEC". I have repeatedly changed the name from this.
I have installed known working examples of default Heart Rate Monitor Example. I have installed blank programs without bluetooth service definition etc.
However, the name of this prior service is persisting.
I have reinstalled my ios app - LightBlue - incase it was a casheing thing. By reinstalled I mean deleted and then downloaded from app store.
I can't connect to these services. New programs are being installed, as I am getting the expected serial feedback.
Why is this happening and What can I do?
I have just tried using the LightBlue app on a different iPhone and I am getting the expected behaviour. How can I purge the stored data from the LightBlue app. I have tried deleting it, then doing a reset (holing lock and home button), then when it has rebooted I re-downloaded the app from the app store. What else can I do to clear which ever info is being stored by LightBlue?
This seems to be an underlying iOS issue, as my other apps are also now using this legacy name. I have tried disabling and then enabling Bluetooth, but this hasn't worked. Any other ideas?
I have submitted an iOS bug report. This is really annoying, as I cannot use my iPhone to test an app I am working on. Any ideas for workarounds?
Related
I ask because I installed to a device (by selecting the device from the simulator menu) and everything was working as expected.
However, after a few weeks it stopped working (immediate crash upon opening).
I tried connecting to the internet and running it again.. and that seemed to make it start working again. However the app itself doesn't use any internet connectivity.
Is there some type of expiry Apple sets when installing to a device using this method?
Or could it be related to the Unity framework needing to touch base?
A app submitted recently to app store failed in review, one problem was an odd bug which I would describe as an edge use case scenario.
The specific bug was described as
"We discovered one or more bugs in your app when reviewed on iPad running iOS 10.3.3 on Wi-Fi connected to an IPv6 network."
The screen shot provided saying they could not find a file called data.js
This file is part of the app and supplied within the IPA. If it was not all other devices would fail testing aswell. Also the app does not make any external api call's at all unless someone is making an IAP.
How can I simulate this environment with xcode, the simulator doesn't give me an option to define network type?
How is the best way to respond to this with apple? Im cautions of just resubmitting the IPA as they say my developer account can be terminated for failure to fix things previously highlighted review.
I feel like this is a very small use case of users, I would prefer just not to support iPad but unfortunately cocoon.io doesn't support setting a device target when building the app.
I'm currently working on a mobile app for a HomeKit compliant accessory. I am using the HMCatalog app and the HomeKit Accessory Simulator for testing purposes.
The issue I'm seeing involves my mobile app and the HMCatalog app. I was under the impression that HomeKit syncs through a user's iCloud account. When I am signed in with my iCloud account on one phone (Phone A), any Homes/Rooms/Accessories that I add on in the Catalog on Phone A will show up in my mobile app on Phone A.
However, when I use Phone B, and sign into the same iCloud account, I don't see the same data in Phone B that was in Phone A. The information appearing in HM Catalog appears it is staying on the individual device and not being stored in iCloud.
Has anyone else seen this? Is this an issue with HomeKit? With the Catalog app?
I found that with HomeKit there are some propagation issues. Sometimes it depends on the network you are in (some block _hap services).
Best way to test it is with a local USB dongle and put the accessories in the dongle network. This should limit the propagation issues.
Hope it helps.
I faced the same issue and was pulling my hair on this one. It's an iOS issue, and after a lot of agonizing hours, this worked for me:
Ensure the device has iOS version > 8.1
Log out and log back in iCloud.
See the following thread. It should be fixed in iOS > 8.1 however, may appear intermittently.
https://devforums.apple.com/message/1054540#1054540
I have created an iOS app that interacts with a bootloader on some custom hardware/firmware to update the application on the hardware. In order to accomplish this, the hardware/firmware has a bootloader application and a regular application. First, I connect my iOS app to the bootloader application and update the regular application. At which point the regular application starts to run and I would like to connect to it with my iOS app.
If I search for peripherals with an Android application it correctly sees my hardware broadcasting as the bootloader application and then switch to broadcasting as the regular application after the update has been completed. However, for some reason, the equivalent iOS app only sees it being broadcast as the bootloader application. I have found that if I restart the iOS device or if I turn the iOS device's bluetooth off and back on after a few seconds it will finally recognize that the regular application is broadcasting.
It seems as though the iOS device is caching the peripheral information. Does anyone know if there is a way to clear the cache or refresh to get the current/valid status of the device?
I have exactly the same issue here, unfortunately this is indeed due to iOS. There are a lot of other threads about this topic but after looking for a while I would recommend this answer :
https://stackoverflow.com/a/25930825
Best of luck, I haven't finished yet and this won't be easy...
My app uses BLE (Bluetooth 4) to connect to a physical peripheral.
My users and I have repeatedly encountered a bug where, at some point, the app stops connecting to the peripheral - you can see an indication that the BLE peripheral is discovered and the connection was established, but then few seconds after, the connection is dropped.
Things go back to normal only after restarting the iDevice.
I’ve done a very long work on checking it and researched this issue thoroughly, until I got to the conclusion that this must be a bug in iOS (tested with 7.1, but probably occurs on 8.0 as well).
My tests and findings:
Occurs with every BLE supporting iDevice.
Occurs with both my own BLE peripheral and with other 3rd party BLE products, both known to work perfectly in normal cases.
It can sometimes work well for even 50 launches, but then eventually it’ll fail.
Network & factory settings reset did not help.
Tested and occurred with various applications: ##
My own app.
Clean new Xcode project that’s only scanning for peripherals and trying to connect to the first and only discovered peripheral.
Apple’s BLE example app: Health Thermometer (with relevant modifications since I don’t have this particular peripheral).
3rd party apps, including the generic LightBlue.
Important note: Every one of the options above worked perfectly for a while (multiple launches), at some point suddenly stopped and then worked again after a restart of the device.
The connection procedure seems to fail when trying to discover the peripheral’s services - i.e. it gets discovered and connected normally, but when initiating discovery of services, it stops responding (didDiscoverServices isn't called).
I have of course tried many approaches found online with no luck.
Can anyone shed some light on this problem?
Is it a known issue?
Was it fixed in a recent iOS update?
Is it going to be fixed?
You can imagine the negative affect such an issue has on my users’ experience, as BLE connection is essential to the product.
I'll appreciate your advice and suggestions on how to solve it.
Thanks!
Update:
Apple responded to my tech support request:
Bottom line(s):
They said they had fixed some BLE related bugs in iOS 8 and urging us to test if it still happens in iOS 8.
They said to start with that and if not, try to diagnose the problem with a utility app they provide.
So far for me it didn't happen with iOS 8, but on the other hand I can see posts about other Bluetooth issues, that are not necessarily related but who knows.
Full answer:
I’m responding to your finding that you and your customers find that
after some point of use, iOS BLE fails to maintain a connection. You
indicate that the problem was identified with iOS 7.1. There have been
issue regarding iOS BLE which have been reported and have been fixed
with iOS 8.0. To best determine whether your issue has been addressed,
of course the simplest means would be to install iOS 8 and to see if
the issue can be replicated. However, as you report that you can
replicate the problem on your deivce with iOS 7.1 the first thing
would be to obtain the Bluetooth Server profile, install it to your
deivce, replicate the problem, then obtain a BLE Server log when the
problem occurs. The profile will have the BLE server report additional
logging details which can help to report issues that the server
encounters. We can see if the issue is one which has been reported
previously. Something to consider is that for all new bug report
issues, Core Bluetooth engineering is requesting that all issues be
regressed with the currently shipping version of iOS - that is 8.0.
For customers with iOS 7.x, there will be no more iOS 7 updates - all
software fixes and bug fixes will be with iOS 8. For this reason, only
issues which are reported with iOS 8 will be investigated. You can
obtain the BLE server profile from the Apple Developer bug report web
page https://developer.apple.com/bug-reporting/ios/bluetooth/. The
instructions for installing the profile and capturing the log, are
presented on the web page. If you capture a log with iOS 7.x, you can
send it to me for review. However, this will be somewhat of an
academic exercise - to know if iOS solves the issue, or whether it
persists, we will need to see if the issue occurs under iOS 8.
Something to keep in mind, once you update a device to iOS 8, you will
not be able to restore it to a previous version. I’m happy to
review your results. If however, the problem persists under iOS 8,
it’s best to submit a bug report to get Core Bluetooth engineering’s
attention on this matter. You can submit a bug report using the Apple
Developer bug report web page. - http://bugreport.apple.com
So it looks like the problem is solved with recent iOS update (either 8.0 or 8.1).