Apple's official legal response to the ongoing encryption dustup between it and the US government was released earlier today, and in it Apple makes many of the same arguments it has made since CEO Tim Cook posted his first letter to customers on the matter last week. But it goes into greater detail on several points, and it includes a section on the specific resources Apple would need to devote to writing the so-called "Government OS" update that would allow investigators to unlock the iPhone 5C in the San Bernardino case.

To recap, Apple says the court order is asking it to do three things: to disable the optional iOS feature that will erase a device after 10 incorrect passcode attempts; to allow passcodes to be entered rapidly and electronically so that investigators can unlock the device via brute force; and to remove the software-imposed time delays between incorrect passcode attempts. This software "simply does not exist today," and Apple says that creating it would "require that Apple write new code" rather than simply disabling features that are already there.

For starters, Apple estimates it would take between six and ten Apple engineers between two and four weeks to design, code, validate, and deploy the software update. "Members of the team would include engineers from Apple’s core operating system group, a quality assurance engineer, a project manager, and either a document writer or a tool writer," according to Apple's motion.

Anyone familiar with software development will recognize the debugging process Apple outlines. The software would need to be tested and validated on several different devices, and any bugs encountered would require Apple to go back to the drawing board to code a new fix and then begin the testing process anew. In particular, Apple would need to make sure that the update didn't overwrite or erase any user data, which would render the entire request moot.

Apple then says that it would either need to provide investigators with documentation that would allow them to create the software to brute-force the phone or that Apple would need to develop that software itself. And if the brute-force tool was to be used anywhere other than "a secure Apple facility," the company would also need to find a way to "encrypt, validate, and input into the device communications from the FBI."

Finally, Apple's motion assumes that setting a precedent in the San Bernardino case would mean that other law enforcement agencies would begin contacting Apple with the same type of request for other phones. If Apple destroyed the software update for the San Bernardino phone (as the government has apparently suggested) it would need to start the process from scratch every time it was asked to unlock a new phone. If the company were to keep the software around to reduce that development burden, the company would then need to expend effort to "unfailingly [secure] against disclosure or misappropriation the development and testing environments, equipment, codebase, documentation, and any other materials relating to the compromised operating system."

"Given the millions of iPhones in use and the value of the data on them," the motion continues, "criminals, terrorists, and hackers will no doubt view the code as a major prize and can be expected to go to considerable lengths to steal it, risking the security, safety, and privacy of customers whose lives are chronicled on their phones."

Apple's main argument here is that it should not be forced to comply with the court's order to give "reasonable technical assistance" to investigators because of the high degree of effort involved. Apple was given "no opportunity to weigh in on whether such assistance was 'reasonable,'" and the company believes that the government's request doesn't fit that definition. It also gives us some insight into the effort needed to add any given feature or to fix any given bug in iOS, given the complexity of the software and the other Apple software (including OS X, WatchOS, and tvOS) that iDevices need to interface with.

The entire motion to vacate is available here in PDF form; the relevant sections cited here are II.E and section 2b of section III.A, but the entire thing is worth a read if you want to familiarize yourself with the rest of Apple's arguments.