iOS Development: Improvement Ideas

Apple has done many things incredibly right with the iPhone family of products, both from the enduser's perspective and the developer's. But it's not perfect. Having written and shipped several iOS apps over the last few years I've accumulated a list of ideas for how they could improve things further, especially for developers.

CLI Everything
Everything a developer needs to do to create, modify and publish an iOS app should be able to be performed in Terminal using CLI tools. Everything. No excuses. Telling it to build and deploy, but also dealing with certificates, the iTunes store, everything. Certain things can be done better with a GUI, such as certain UI layout tasks or debugging scenarios, and for those it's useful to retain the option of using those tools as desired -- but even then it should be a developer's option, not a requirement. A developer should be able to push an update to any of the iOS apps he has published with a single CLI invocation, possibly wrapped up as part of an in-house shell script as part of a larger release process.

No Boilerplate
If it's boilerplate or ritual, it shouldn't exist. Automate away. Abstract away. Be more concise. Use reasonable defaults. If the developer doesn't care about a certain decision/parameter/toggle, then do not make him specify a choice for it. If he does care, give him an optional way to declare his choice. Closely related to the notion of boilerplate is the principle of "do not repeat yourself" or DRY. Do not require a developer to specify the same thing in essentially 4 different locations. Let him specify it in one place, and all other places/uses should be derived, generated or assumed, unless otherwise specified. Two easy examples are header files and class properties. There are other offenders in the XCode project properties and configuration boilerplate as well, and the iTunes store metadata. Say a thing once, in one spot, and well, and then any other needs should be derived intelligently by default.

Single File Source
It should be possible for a developer to have the entire source code for an iOS app completely contained within a single textual file, including UI wiring, configuration, build parameters and storefront metadata. Everything. There are certain cases where it can be advantageous or a net-win to have certain data types be broken out into separate files, and to support those situations the developer has the option of doing that. The most obvious and common example would be graphical images or audio files. But he should never be forced to to keep any logic, config, data, build parameters, project data or storefront/publishing metadata in separate files. One of the core tactics acquired by veteran programmers to achieve rapid prototyping and project bootstrapping is to start a new project by keeping all of the code and data inside a single file, and try to keep it like that for as long as possible. There often comes point where there are benefits to splitting an application's code up between several files, typically to separate logic from configuration from canned data, or to organize by code modules, and so forth. But by minimizing the amount of separate "things" a programmer has to deal with, it allows him to work faster and smarter, and to more easily keep everything in mind's eye, and it helps with troubleshooting as well because there is less esoteric/exotic/boilerplate stuff hidden off in some obscure project file that may later come back to haunt you.

No IDE Required
This is closely related to the above ideas, CLI-centrism and Single File Source, but distinct from it. This basically means it should never be required to fire up an IDE. Especially not an Apple/IOS-specific/controlled IDE. There are alternative ways of developing software, and there is a rich variety of tools already out there, that a developer can choose from, and they are not limited to just iOS development, and not controlled by Apple. Let's not reinvent the wheel. Allow developers to fully use their tool skill set across all projects, and spend as little time as possible on a tool set tied to a single development or deployment platform, or component tier. Also IDE's are strong at some things and worse at others.

Modern Memory Management
In the year 2010 we have dynamic so-called interpreted languages with memory models that don't require doing manual release calls, or reference counting/balancing. The ergonomics of both Python and Java's memory models are much more friendly and easier to understand -- and with less exceptional cases -- than Objective-C and the iOS runtime. I understand the device is less powerful, with a weaker CPU and less memory. On the other hand, properly written code, in any language, and for *typical* applications never has CPU as the bottleneck. Available, interested and affordable human development talent hours is the main bottleneck, with perhaps enduser device interaction delays being the second, then network IO being the third. Optimize more for developer happiness and ergonomics, and less for device efficiency.

Stop the Authoritarian Control Over Publishing
Apple has made big improvements compared to what it was like at it's worst, but it is still pretty bad. The list of things Apple doesn't allow you to do is hilariously long and Orwellian. Frankly, it sticks it's nose into things that should be between the developer and the consumer, and nobody else (or at most, perhaps also the government.) The desire to ensure a minimum quality threshold is not a bad thing, by itself. It's the degreee to which they take it, and the fact that they take it to inappropriate ends, and they apply their standards inconsistently, both across the lifecycle of a single particular app, and across the set of all developer's apps. They also go too far in saying what you can and cannot do in terms of the content of the app. This goes beyond questions of form and function, of UX, of technical implementation details, and it is inappropriate. Disallowing political parodies, unless it's by an "established" journalistic channel, who are you to decide that? Disallowing apps that are too simple or low-brow or ephemeral in nature and yet allowing Fart apps? Disallowing sexual/adult content but making exceptions for large corporate backed apps like Victoria's Secret and Playboy? It stifles both creativity, innovation, free speech and alternative cultural values, and fosters an unfair unlevel playing field, which is unethical. Also, ultimately, the consumer has bought the device. Once they buy it, they own it. It's a tool for them to use as they please. You should not be able to say what they are or are not allowed to put on it. If your real concern is to prevent cases where say an app is released that floods the phone or WiFi networks, a better approach might be to address that at the level of the phone and WiFi networks directly -- surely they must already have mechanisms in place whereby their operators can prevent or mitigate the harm from such cases, because there are lots of other applications and endusers of the network other than iOS-class devices, which are fairly new to the ecosystem. About the only area where Apple can make a strong case for being authoritarian about allowing an app is to try to prevent cases where an app accesses and uses the enduser's data in some obviously malicious manner. Disallowing or restricting what an app can and cannot do with respect to those kinds of things is probably the best justification for Apple acting as a gatekeeper onto the device. But most of what else they try to control or reject is inappropriate or unethical or unwise.