Apple, Make Programming Easy Again!

My first experience with programming was decades ago with an HP41C.

The experience of learn, back then, was a joy. HP41C had superb manuals, in fact beautiful state-of-the-art manuals written in a way that inspired learning. It was a joy to learn stuff reading that manuals. Simple and clear language, beautifully written.

Months passed and I had contact with my first personal computer, through an uncle: a Commodore VIC-20 computer.

A few weeks later, seeing the interest I had on that computer, I was hired by my uncle to develop a program for his company. That was my first experience using a serious programming language: BASIC.

Again, the experience was amazing. VIC-20 had great manuals, superbly written. The experience of learning was inspiring, a real joy. Learning was fast.

After an year using that VIC-20, my uncle decided to invest on better computers. He proceeded to purchase an Apple ][+ and then an IBM-XT. One more time, the experience of learning new stuff was amazing. I was learning by reading manuals created by software companies that cared about creating documentation. Programming was easy, not a lot of APIs, clear and amazing documentation.

After that experience of about 5 years programming for my uncle’s company I started to change gears and directed my professional to another area of interest: computer graphics and visual effects and programming became a secondary activity on my daily life, acting as a support to get my job done.

Fast forward to 2007, Apple announced the iPhone and months later, the first SDK, so third parties could develop for the iPhone.

That was an opportunity to good to pass and I immediately joined the band-wagon and started trying how to create apps for that little beautiful device. That was my opportunity to return to programming as my main activity after years working on another areas. What I did not know is that I was opening the gates of hell!



After years of being an Apple customer and used to expect the top notch quality from them, I was in shock by how bad the whole process of creating apps was.

Used to learn on high quality documentation and being a technical writer myself who always try to explain things on a easy way, inspired by the kind of manuals I was used to read, I was soon in a land of poorly written documentation. Poorly written in all senses with a lot of bad explained stuff to missing and vague information.

The whole process was and is a mess.



As computers got more sophisticated, the number of APIs and frameworks increased exponentially. As computers were getting easier for users, programmers paid the price, as it got more complicated to create software, as explained by Steve Jobs on this interview.

On that interview, Steve Jobs identifies the problem and explains what was the tool NeXT was releasing to “make programming easy again”.

What do I have to say about that? Simple: we need another tool or way to create programs that is easy and reduce the time we spend fighting poor documentations and “gigabazillions” of APIs. APIs that are dumped by the trucks every second because companies have to compete with others and need to launch a lot of stuff, so they will not be seen as being behind. So they prefer to launch quantity instead of quality and most of the stuff is half-cooked. This is not just Apple‘s fault. This is simply Apple doing the same of other companies like Microsoft and Google, and joining the band-wagon of half-assed APIs.

The first time I posted a comment on a forum on the lines of this article someone said: “if you think the process of creating apps for iOS is a mess you should try Android“. I don’t argue with that. What I am saying is that as an Apple user I expect to see high quality stuff for programmers and I am far from seeing that.



On the following video, Steve Jobs demonstrates how easy is to create programs with Xcode.

I ask: what the hell happened to Xcode? Why is Xcode today this obnoxious crashing tool?



I am in the process of finalizing a camera application I have created for iOS. Creating that camera was a nightmare. 60% of the developing time was used to fight AVFoundation, its APIs and their poor documentation. AVFoundation is, without doubt, the worst framework I ever worked with.

To demonstrate how complex dealing with AVFoundation is, that camera app I am finishing now faced a bug so hard to detect, months ago, that I was forced to open a technical incident and ask Apple for help. Their best engineers took two months to discover the problem. Think about it. If the top engineers took two months to discover a simple problem something is wrong with the whole process.



Following the idea seen on the previous video, this is how creating an app should be. In the example, I will show how a camera app with filters should be created.

All starts with packaged objects with full functionality. The first object that would be dragged to  a diagram (you can call storyboard if you want) would be the CAMERA object. That object would have 4 main connections, as seen on the following image:



OVERLAY – used to allow the user to apply an overlay over the preview or output image;

PREVIEW IMAGE – that will provide a preview image that is compatible with the size of the preview view and is rotated properly (Apple, developers should not be responsible for rotating the preview image because the camera sensor is in landscape).

HIGH RESOLUTION IMAGE – that will provide a full resolution image being captured.

START/END FADERS – that will provide a connection to an array of FADERs, that is another object I would create, that once connected to a CAMERA object will provide means of creating fade in/out for video/audio. In other words, one could define that once the camera starts to record to file, it should fade in from some color to video and fade out to another color as well as fading in and out audio. Much more sophisticated than AVFoundation with zero lines of code.

The second object to add to the project in question would be the FILTER object.



That object could come with four main connections:

INPUT IMAGE – where the full resolution image should be connected.

OUTPUT IMAGE – to deliver a full resolution image with the filter applied.

FILTER CHAIN – an array of filters that should be processed in order.

AVAILABLE FILTERS LIST – a list of filters provided by the object.

SELECTED INDEX – a way to get a filter inside the filter chain.


Connecting the whole thing we should have something like this:


What do we have here? We have the camera delivering an output image for the PREVIEW object and a full resolution image to FILTERS. FILTERS is connected to a TABLE is filled with the list of filters and outputs an index that could change parameters of a given filter. That would be the whole process of creating a camera app. The CAMERA object could be connected to a FILE OUTPUT object, providing ways to save the file to disk and to a SHARE object, providing ways to share the final movie to Facebook, Instagram or whatever.

Following this idea, it is clear to see how easy would creating apps be. As As Steve Jobs said on the previous video: the line of code that never breaks for the user is the line of code the developer never had to write.  said on the previous video: “the line of code that never breaks for the user is the line of code the developer never had to write”.

I am a huge fan of the ideas of the former Apple employee, Bret Victor, about how simple code creation should be.

I don’t have the pretension of knowing everything. This is just how I think software development should be.

Come on Apple, bring Steve Jobs ideas back and make programming easy again.


Post navigation