does anyone has a working implementation with accessoryDidUpdateReachability unter iOS8 / XCode 6.3?
playing around with HomeKit shows me very unstable change state of accessory reachability.
Status mostly only changes after restarting the app.
Reachability appears to be mostly broken in iOS 8.x. You can stimulate it by attempting to read, but I think that's frowned upon by apple. Even when reads report some value, the reachability value doesn't appear to update.
The good news is that it seems to work much better in iOS 9.
Related
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).
First of all sorry for my English. I have searched but I didn't see nothing similar.
I have a problem and I don't know really how to make it.
I need to sync data between two or more iOS devices. This data could be a JSON or something similar.
Example:
Two iOS devices uses the same app, they are near each other(In the same place or room). There is a form and if I change a value in one of the devices the change should be shown in the other device automatically.
Thank you very much.
I think you need to use the Multipeer Connectivity Framework which is part of iOS 7.0.
Apple's Multipeer docs
I have read CLLocationManager kCLErrorDomain Codes? as well as Apple Docs
I check to make sure ranging is available before calling startRangingBeaconsInRegion: and I am also checking if ranging is available while in the locationManager:rangingBeaconsDidFailForRegion:withError: method. Returns true both times.
When I get the set of monitoredRegions, my beacon is in the set (so registering for monitoring is working).
I have read that error 16 can mean ranging is unavailable, bluetooth could be off, location services could be off, airplane mode could be on, I have checked them all and all are available and running (obviously not in airplane mode).
What could be causing the ranging to fail, every time I run the app?
It seems that I started to face this issue after I updated my device to iOS 7.1 (iPhone 5S). rangingBeaconsDidFailForRegion: gets called with error.domain equal to #"kCLErrorDomain" and with error.code as kCLErrorRangingUnavailable (16) (even though Airplane mode is not on and Bluetooth is up and running).
I followed davidgyoung's advice to just boot (I did a hard boot pressing Home + Power until the device shuts down and displays the Apple logo, but also a normal boot works) the device, and now it seems to work correctly.
This appears to be a bug in iOS 7.1 and iOS 7.1.1, see here https://stackoverflow.com/a/22949187/1461050. The only workaround - for now - is to reboot the device.
Apple has now released iOS 7.1.2, which should fix this problem (awaiting for confirmation).
Just to eliminate any possibility that it could be something in your code, try a reference app like my Locate for iBeacon. If it also does not work, you probably have an OS or hardware problem.
To troubleshoot this, first reboot your phone and try again. Then try pairing to a regular Bluetooth device (headphones, Mac, etc). If regular Bluetooth pairing works, it may be a Bluetooth LE issue.
Your iOS device must be either an iPhone 4s+ or an iPad 3+ (needed for BLE).
The problem is closely related to the CoreBluetooth Unknown Error 1309.
In some circumstance, seems that the CoreBluetooth Stack become corrupted and the only solution is to reboot the device.
There're plenty of users that are reporting such behaviour. We've fired a bug to Apple Radar and we're waiting for response.
You can also report the problem to Apple Radar so that they will notice this bug.
I'm trying to build an app that communicates with an external accessory (over bluetooth). To ensure the app is user-friendly I'd like him not to go to the settings to connect with the accessory but to show the Accessory picker that iOS 6.0 includes.
To achieve that, a simple call to :
[[EAAccessoryManager sharedAccessoryManager] showBluetoothAccessoryPickerWithNameFilter:nil completion:nil];
For now, I'm not using the filter and the completion (both can be nil according to the iOS Class Reference) - even if I tried using them too.
Now the problem is that my accessory appears for 2 to 10 seconds and then disappears from the list until I cancel the popup and show it again. Another problem is that sometimes it doesn't appear at all. I also made sure the device was already paired but not connected.
I tried using another accessory (one that I didn't make myself) and with different devices (iPhone 4, 4S, 5 - iPad - iPod Touch) with no success.
Does anyone has a similar issue? If yes how did you solve it? Is it an iOS bug? Is it an accessory bug?
Thanks for any reply.
I can confirm that iOS 7 BETA 4 has fixed this issue. If you are using the RN 42 APL bluetooth chip (which you must be as its the only one available on the MFI program)
The only thing you need to be aware of is that the firmware on the RN 42 module needs to be 5.36 and above (as it fully supports the iAP protocol)
I have updated my App (that talks to a custom build accessory) and the accessory picker dialog works a charm.... just thought I'd let you guys know!
Just got the answer from Apple to these questions.
Apple said that it's a bug and they are going to fix it with the future release of ios.
Not sure when this will happen. But do not waste time for this as it's bug.
until new fix, work around is pair the devices on the bluetooth setting screen and then use it in App.
I can confirm the bug is still present in iOS 6.1.3
We have designed a custom piece of hardware that uses the RN42 APL module (we are part of the MFI program). We have spoken to Roving Networks (now Microchip) and they have assured us the firmware on their module matches apples requirements... Microchip are still looking into the problem, but we are looking at the possibility that it is a bug with iOS 6.x
I will download iOS 7.0 and try it out... will report back guys
Cheers
Will
I have had the exact same problem and have been unable to solve it for the past week.
I'm using a Roving Networks RN-42-APL-X module, and I changed the Inquiry Scan Window and Page Scan Window of the module I was using to 100%, but still no luck.
showBluetootAccessoryPickerWithNameFilter will sometimes NOT find my device, and when it does, it loses the device anywhere between .5 seconds to 6 seconds after finding it...
2013-03-13 00:45:22.006 EADemo[356:907] BTM: found device "myDevice" 00:08:36:4B:A4:49
2013-03-13 00:45:22.631 EADemo[356:907] BTM: lost device "myDevice" 00:08:36:4B:A4:49
It seems like all large downloads timeout on iOS6 using ASIHTTPRequest.
Does anybody know of any forks that have updated this library for iOS6. I love this library and really do not want to have to switch.
EDIT:
This issue is not specific to ASIHTTPRequest. Upon testing FSNetwork, MKNetwork, AFNetwork, and NSURLConnection they all fail.
A sample project can be downloaded from here:
https://github.com/BLamy/NetworkTest
It must be built to an actual device running iOS6 (I used an iPad2 unsure if that makes a difference).
I was having the issue with uploading. The solution I found was to set the cachePolicy of the urlRequest to NSURLRequestReloadIgnoringLocalAndRemoteCacheData. (There were a few other networking bugs I encountered too which only occurred on iPhone 5.)
Are you getting the timeouts on apps that are build against iOS SDK 5.x running on iOS 6 (ie your old builds. If you don't have access to an old build, how about the one you have existing on the App Store?).
Or are your symptoms ONLY occurring for new builds with Xcode 4.5 against iOS SDK 6.0? If the latter, and you really don't want to give ASI up, (and you don't want to implement any of the new iOS functionality), then you could consider building against iOS SDK 5.x instead of 6.0. See my answer here for instructions.
If you need to implement new iOS 6 features, or iOS 6 actually broke your implementation of ASIHTTP (built against iOS SDK 5.x), then you should consider other networking options. It's been over a year since Ben advised developers to seek other options, with good reason.
iOS6 has serious problem related to Wi-Fi. We use ASIHTTPREQUEST. We find small file downloads work fine, in some case large file(10MB above) downloads too, but after the download, we keep the device idle for a minute, again you try to add operation to the queue. The app crashes.
Initially, we got many Network unavailable alerts, though the internet was available. Later, we changed the Wi-Fi setting security mode WAP to NONE. Then for sometime we did not find the network unavailable error, as well downloads were ok..
However, when the server itself becomes loaded, the connectivity and download becomes to halt at mid of the progress. I have noticed this behavior, even in native SDK facebook app.
The simulators work very fine, even the devices like iPad1, iO5.0, iPhone 4 with iOS5.0, the never crash.
I sum up..Apple half baked the iOS6.0, may be the iOS6.0 is suitable only for iPhone 5,the new antenna structure. Unless Apple fix the iOS6.0 issue may not be solved.