January 12, 2016
Yesterday I talked about the higher level layers that need to built in order to make it easier for new iOS programmers to get to the good stuff more quickly.
Someone asked me on Twitter whether Apple's new package manager is the answer. "That way," @salutis tweeted, "there’s no need for Apple to make all that stuff themselves."
He's completely right that it is possible for third party developers to do this important work. I think it's essential that Apple do a big part of this work because Swift and the iOS platform are moving targets.
It is essential that the higher level APIs that iOS programmers need be provided in the standard installation from Apple and that they be rust free.
Believe me, I know what it's like to keep up with a moving target. I wrote A Swift Kickstart a year and a half ago and have updated it a dozen times to keep up with the changes both to Swift and to Playgrounds.
Andy Hunt introduced me to the Dreyfus model of skill acquisition years ago. Someone new to a topic can't handle even the smallest deviation between the instructions and the application. If I tell a new programmer to tap the "Next" button and it has been changed to be the "Finish" button, then the new programmer will look at my instructions and look at their screen and be puzzled of whether my instructions are wrong or if they've missed a step. At this stage, little differences mean a lot.
Here's an example from Swift and Swift playgrounds. Apple has published a Balloons example that shows a continuous engaging scene of canons firing balloons at a fairground. As of today, if I open the playground it fails to run. There are several errors.
I'm an experienced Swift developer and I've worked with playgrounds for quite a while. I quickly move through the errors and correct each one. I know that the way in which you specify that a playground should run indefinitely has changed. I also know that how you specify which view should be displayed has changed. I make these changes in a few minutes and the playground runs perfectly.
A new programmer would be stumped.
Even an experienced programmer, new to playgrounds, might be puzzled by the error messages. They could likely work things out, but would they stay long enough to do so?
Examples and frameworks rust.
"But Daniel," you say, "why should Apple produce these. Isn't the Balloons playground an example of one of their projects that rusted?"
Yes, but by and large, the company that is updating the language, the tools, the other APIs is in the best position to update these higher level APIs.
When iOS 5 shipped, Apple made memory management so much easier by introducing ARC (automatic reference counting).
Many third party frameworks took a great deal of time to adopt this new technology if they ever did. If you were dependent on these frameworks you had to exclude them from using ARC.
This is not a big deal for experienced developers - but for newbies it meant that they were typing in things that they didn't understand.
The other reason I prefer that Apple writes these higher level abstractions is that when I teach or work with someone, I know that they've been installed and that we don't need to do anything special before using them.
I'm not saying anything against third party developers or packaging tools. I'm glad they both exist. They have provided much needed support and have been essential for some of my favorite apps.
But here my interest is in enabling and teaching new friends of iOS and Swift. For these people, I want the technologies to be part of the standard distribution from Apple and I want them to be rust free.