Don’t be encumbered by history. Go off and do something wonderful.
The App Store is about to turn 8 years old and everything related to it is still immature. Apps are sold for pittances and mostly developed with the naive hope of a precocious youngster aiming to strike it rich with his combined marble distributor/lemonade stand. (Annoyingly often named following the same lexicon – oh, and backed by some investor’s war chest.) They are still reviewed under the purview of the parodically inconsistent App Review mechanism, renowned for its ability to take issue with minor details that have been there for versions. And they are still restricted to the subjects established by the recent meeting with, and concordant edict from, the True Love Waits club in Kaysville, Utah (nondestructively summarized as “Tits? GTFO!”… where GTFO presumably stands for “God, Thy Father, Obey”).
In short, we’re where we were. Concessions have been made along the way such that people can now build and deploy an application to their own device for free, even with officially sanctioned apparatuses. The mind boggles.
This absurd situation may work itself out in time, but I will spill no more pixels on it here.
The App Store is one half of the New Model, the one that recurring commentator Chucky will shortly refer to derisively as “turning things into consoles”. The other half is the technical restrictions used to uphold this New Model. Sandboxing and isolation. Restrictions out the wazoo. For all we know, ACLs on individual bits of memory.
Sandboxing on the Mac App Store has been an exercise in annoying frustration. By and large, existing apps haven’t been able to cope. Apps have gone into the App Store but had to back out because of all the bugs. I wrote a color picker that stored its preferences in the only place it could, and that broke causing it to ask whether you want to check for updates the first time the color panel’s invoked. This has been a mess from day one.
And yet… I don’t see it as the problem any more. Protected memory and process isolation has been with us for a long time. The problem with these sandbox mechanisms aren’t inherent problems in the idea of sandboxing. Name a security exploit that is not made less severe by inducing isolation around its boundaries. Post-App Store, post-Docker, what is to say that isolation and sandboxing isn’t just treating security with the requisite care that it has deserved for all this time, and that the right thing to do is to keep the goldfish in a bowl instead of a plastic bag?
What is the problem? It is that users haven’t changed. Needs haven’t changed. And too little has been done to make the new solution solve the old problems.
For all the noises made about respecting privacy and integrity, respecting someone’s right to their own data also comes down to the their right to take that data to another app. Yet with sandboxing today, you can’t build an import function from someone else’s app because it’s seen as invasive.
It would be supremely convenient to be able to host other extensions within your own app, or even within your own extension. If Apple wants to so desperately raise their Services revenue, allowing developers to develop more stuff that customers actually want might be worth kicking around.
For better or for worse, we are living in the era of the contained app. It has happened. It may still be happening. What will decide if I will be happy on tomorrow’s OS X/macOS won’t be whether my apps have writing permissions to a path or not, it will be whether I can still do the things I want to do. I don’t want the focus of this discussion to be on whether the locks should exist or not, I want it to be whether there is enough forward motion so that the things that are worth saving can be retained, and for vendors of every closed platform to be pressed on these issues.
(See also: The Tension of Swift.)