Wednesday, March 9, 2016

Not the Apple of my iPad--or so I wish

The GrammarTrainer project has faced its share of obstacles. There have been coding challenges, challenges finding beta-testers, challenges dealing with school bureaucracies, and challenges finding collaborators and competent coders. We’ve lost time to incompetent coders, we've lost efficacy data to unsupervised graduate students, and we’ve lost collaborators to unfavorable tenure decisions and, tragically, fatal heart conditions. But only a few times has progress has ground to an actual halt, and each time it’s all been all thanks to Apple.

Apple has recently portrayed itself as taking the high road in refusing to write code to unlock the iPhone of the San Bernadino shooter. Apple is “a staunch advocate for our customers’ privacy and personal safety,” CEO Timothy Cook has said. “We do these things because they are the right things to do. Being hard doesn’t scare us.”

I’m not sure what to make of the San Bernadino iPhone controversy, but I’m pretty sure of a few things. Apple’s stance isn’t about what’s right; it’s about what’s profitable. Apple isn’t just “hard” on the FBI; it’s also hard on its users. And Apple’s basis for not being “scared of being hard” isn’t bravery, but near-monopolistic power.

A few years ago, we decided it would be a good idea to create a app version of the GrammarTrainer. Our rationale was that, thanks to Apple’s increasing dominance in the American Edutechnological Industrial Complex, more and more classrooms had iPads; more iPads than any other sort of computational device. But we didn’t realize the obstacles that lay ahead.

The first one was immediate: downloading software onto an iPad is a lot more complicated than downloading software onto a computer. You can’t just go download random stuff off the web. Instead, you need to install special software. Back then, there was an independent testing platform called Testflight that would do the job. All we had to do was install Testflight on all of our devices and then give the developer all of our iPad ID numbers and user names so she could “invite” us to download the program. Every few months, the latest software “build” would expire, and then we had to download a new build.

Just as we were getting used to this, Testflight was purchased by none other than Apple, and Apple, with a few weeks’ warning, proceeded to expire the version of Testflight that all of us had installed on our iPads. Getting the new Testflight installed involved a more complex “invitation” process in which all of us testers had to create iTunes accounts. But the worst part was that the software, which now had to be uploaded to iTunes, was required, even though it was only in testing mode, to go through iTunes’s opaque “approval” process. This took several weeks longer than it had to because of the lack of feedback in the iTunes error messages (error messages that lack feedback are things that coders loathe but can avoid when they’re in control of the coding). As for human feedback—forget it. With a great deal of effort you can eventually figure out a way to make an appointment for telephone support, assuming you’re willing to wait for several days for an appointment time. But (at least in my experience) the human helper doesn’t end up having anything helpful to say.

Finally our app developer figured out the necessary technical modifications to make the program acceptable to iTunes. But as soon as we had modifications to make, new problems arose. The first time our developer tried to upload new videos, the program would no longer load unto our iPads. There was no help to be found anywhere on the iTunes website; only scores of negative reviews for iTunes support. It wasn’t until we reached out in all human directions and eventually found an iTunes savvy friend of a high school friend of my husband’s that we got the necessary help. (Some developers are true angels, more interested in helping than in profit seeking). Now, it seemed, we knew how to upload new builds—something that, with the original Testflight, was trivially easy.

But soon we realized that, whether or not we actually had new builds, our project faced another new obstacle—a recurring one. Unlike the old Testflight, the Apple Testflight would expire our builds every 30 days. Frequently, in the course of those 30 days, Apple would make various “upgrades” to the developer platform and the updating process, such that our developer frequently had to learn new procedures and sometimes had to renew her Apple developer "license" and/or upgrade (or “upgrade”) her entire operating system. The problem was particularly acute if anyone on our team neglected to upload the latest build until after one of the unrelenting expiration dates had passed. Eventually Apple Testflight deigned to double the expiration period to 60 days. But meanwhile it has complicated matters so much that, for reasons that are even more boring to explain than the rest of this is (they relate to the fact that only certain individuals at the school district’s downtown office can receive the emails from iTunes that contain the download link) the classrooms we’re partnering with can no longer get the software onto their iPads.

A near-monopoly on classroom computing; a near-monopoly on testing platforms; a program for autistic kids brought to a standstill. Somehow that sounds like the unintended consequences of profit-seeking rather than of taking the high ground and not being scared of “being hard” on the FBI.

No comments: