Every now and again I end up helping a developer with a Wi-Fi issue. These fall into two groups:
- User-level Wi-Fi issues
- Development Wi-Fi issues
A user-level Wi-Fi issue is one where the developer hasn’t created any of the products involved. An example of this is when you’re developing an app for an accessory and iOS is having problems connecting to that accessory but you don’t control the accessory’s firmware. In general, I recommend that you escalate such issues to the accessory vendor. They can then run their own investigation and, if necessary, file their own bug report.
A development Wi-Fi issue is one that directly affects one of your products. For example, you’re developing a Wi-Fi accessory and iOS is having problems connecting to it. In that case, the onus is on you [1] to investigate why things are failing. If your conclusion is that iOS is behaving incorrectly, file a bug about that.
IMPORTANT If you do file a bug in the context of some forums thread, please post your bug number to the thread, just for the record.
When filing this sort of bug report it’s important to provide:
- Solid evidence that the problem is on the Apple side of the fence
- Enough information for Apple’s engineers to investigate it effectively
Let’s start with that second point. If you can reproduce the problem reliably, install the Wi-Fi debug profile on your device, reproduce the problem, noting down a rough timestamp, and include the resulting logs and that timestamp in your bug report.
Also, consider attaching a packet trace. There are three options here:
- Record a packet trace from the perspective of the Apple device. On iOS, use an RVI packet trace for this.
- Record a packet trace from the perspective of your accessory.
- Record a Wi-Fi level packet trace. You can do this from your Mac (see Recording a Wi-Fi Packet Trace) but it might be easier to do this with the infrastructure you used during the bring up of your accessory.
It’s fine to include all three (-:
Also include any relevant context about the issue. For example:
- If the issue is tied to a specific device model (In that case, it’d be good to include the above information for both the successful and failing cases.)
- If the problem shows up when joining from Settings > Wi-Fi, or whether it’s tied to a specific API, like
NEHotspotConfigurationManager
Finally, make sure to include an explanation of why you think this is an Apple bug, referencing specific items in the logs and packet traces that you attached.
Of course, it’s only possible to do all of this if you can reproduce the problem. Investigating an intermittent issue based on reports coming in from users is much harder. It’s OK to file a bug about such issues, but your bug might not be actionable. At a minimum you should aim to include a sysdiagnose log with your bug.
IMPORTANT This log has to be taken shortly after reproducing the problem. Don’t just attach any old log.
One option is to request such a log from your users. I talk more about this in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem.
You can also ask your users to file their own bugs using the Feedback Assistant app. It should automatically capture and attach a sysdiagnose log.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Well, your organisation. It’s rare to find a team where the same engineer works on both the iOS app and the accessory firmware. But if that’s you, good job!