At the time I wrote usbmuxd, which implements the sync (not tethering) part of the protocol. I can now say that I had a bit of behind the scenes help from an Apple engineer; his tips helped work out some corner cases that would've been quite hard to track down otherwise. This friend sadly passed away a few years ago.
Unfortunately, Apple has always been (publicly) hostile to third party support for their devices. For example, they insist on "signing" music databases with algorithms based on their FairPlay DRM implementation, to stop non-iTunes software from syncing music to them. I reverse engineered one variant of this (which was based on a white-box AES implementation and a lot of obfuscated junk) but they kept changing the algorithm. This went into libgpod and libimobiledevice.
What I would like Apple to support is fetching the raw h264 stream in a documented fashion, rather than forcing one to use AVFoundation and get pre-processed frames/data. Only allowing decoded video makes it impossible to scale. ( having many devices connected to a single mac all streaming video )
It would also be awesome if they would open up and document all the protocols and operations that the lockdown protocol supports. I doubt that will ever happen though.
They're deliberately opaque and obtuse. If people choose to buy their devices then they should accept the consequences of that choice.
I don't own a personal mac laptop, nor do I use an iPhone. If Apple gave me a macbook pro and an iPhone I wouldn't use either. ( other than to develop software that requires those )
I do though believe in making required technical things easier for others. It is a good feeling making something possible with IOS devices that hasn't been done as open source previously.
Creating and testing IOS apps isn't something that will cease to be just because hardcore developers dislike the closed Apple ecosystem. The people who fund Apple, in my opinion, aren't hardcore geeks. They are the normal folk in the world.
My only request to Apple is to please listen to what the developers want and provide some of the information I need so that I can in turn improve the development experience for the developers that are already paying into their ecosystem.
Sitting on your high horse saying "I don't like the way big companies function" doesn't pay the bills or convince anyone you are a good engineer who will stay professional regardless of your personal feelings.
1. If the work is ultimately for a company you are working for fulltime and getting paid from the start. This is the case with IOS support for DeviceFarmer. I work fulltime for T-Mobile. I am thankful to them for allowing the majority of the resulting software to be open sourced. The reason they allowed it to be that way, and wanted it from the start, is so that we can benefit from users using the software, finding bugs, and reporting them. There have been contributions from the open source community to it as well that have been very helpful.
2. By providing paid support for an open source project. There is a great need right now for someone ( and/or many someones ) to work with companies to get DeviceFarmer setup and working well for their needs. I do this a little bit on the side myself, but it is tricky because I don't have much time remaining after my day job to do so, and I have to be careful not to let it become a conflict of interest.
DeviceFarmer as a entity is a collection of key personnel who have been maintaining OpenSTF. I believe all of them are fulltime employees of various companies that use it internally and contribute to it to address their own needs. I joined the core team as a result of writing IOS support for it ( I say "writing", despite also porting in a large chunk of IOS support from other open source contributors; mrx in specific )
Right now DeviceFarmer isn't a legal entity. There is no company or non-profit currently. It is just a bunch of developers cooperating. We have considered creating a non-profit company for it, but it has not been done yet. The members of the group are spread out internationally.
The original main author(s) of OpenSTF formed the company HeadSpin out of it, and offered it as a commercial project. Very recently the company collapsed as a result of internal corruption, but the project itself lives on. Really they had abandoned OpenSTF 2-years ago anyway. The rebranding to DeviceFarmer instead of OpenSTF is to move the project to being open and no longer restricted by HeadSpin.
HeadSpin themselves refused to ever accept contribution of IOS support into the OpenSTF project, because IOS support was one of the main differences in their commercial offering. They refused to ever open source that portion of OpenSTF. Forking the project was necessary to allow this. Essentially the entire community has moved to the fork and abandoned OpenSTF. The crumbling of HeadSpin sealed the deal and OpenSTF is essentially no more.
They do get triaged just not necessarily actioned depending on priorities etc.
> This server is vulnerable to the Zombie POODLE vulnerability. Grade set to F.
> There is no support for secure renegotiation.
> This server does not support Forward Secrecy with the reference browsers. Grade capped to B.
> This server supports TLS 1.0 and TLS 1.1. Grade capped to B.
What the fuck?
Maybe the domain still uses the gotofail  prone implementation of Apple's SSL library?
After that CVE was disclosed in 2014, I decided to ditch all Apple hardware forever. There is absolutely no security on any Apple device. The bug meant that there was not a single working SSL encryption from Apple's first OS up until (and including) OSX 10.9.2 and iOS 7.0.6 ... which kinda speaks volumes on Q&A or security audits.
Nowadays, due to Apple never using any git or any other version control software for opensourced codes, I could trace it down to Mac OSX 10.4 which was released in 2005. 
With 10.1, there's no libsecurity open sourced, I don't know why, but I'm pretty damn sure that at least 10.2 included the library back then. I don't have my old Powerbook G4 anymore, but I swear I could verify this bug on 10.2 (Jaguar) that was running on it at the time.
Other versions of (maybe patched?) versions of libsecurity-ssl are located on the same server, with a global directory for everything so it's not actually versioned!? 
At least the version of the file that has copyright 2000-2001 still has the same bug in it, so that is very likely the one that was used in the 10.1 public release 
I'm using the wifi hotspot since wired rarely works for me.
$ sudo idevicepair pair
No device found.
I admit I never tried the wired mode on iOS. Maybe it doesn't propagate the link state?
* It disconnects more than once per day, requiring me to enable the wifi hotspot again on the phone
* The phone gets very hot
* It is slower than usb tethering: In my measurements, I get about 4MByte/s over USB and around 2MByte/s with wifi, though I'm not too confident in the results. According to the mobile provider, I should get 10.
EDIT: A fourth one is that the wifi hotspot leaks my first name and phone brand to everyone in the vicinity.
You can use your mobile as a Wifi-to-USB dongle and dont have to care about wireless credentials which is very nice. This is not possible with a wifi hotspot because in Hotspot mode you cannot use your wifi in parallel.
I do use that with a mobile router that supports Android's usb-cdc-ethernet adapter to forward hotel wifis when i only have one code for a single device (mac address). Or when the wifi gadget you want to use doesnt work with the captive portal. Fast and hassle free.
Wired tethering always worked instantly. Well, until now sadly :(. I tried to do this the other day and I just figured something was bugged, but I didn’t realise it is an iOS14 issue. Guess I am stuck with the wifi hotspot for now when I am out and about.
I'm sure WiFi tethering will still work with it, but it's nice to remove one potentially flaky connection from the equation.
Online Store and iTunes Store used to both run on it.
These days I imagine everything does since they use Kubernetes for Siri, Maps etc.
It is a lot easier to hire people to work on tools there are used widely across the industry.