Why is iPhone Development so

 

hard?

By Chris Lozinksi – Specialty Job Markets, Copyright, November 2009, Reprinted with permission from http://article.iphone.specialtyjobmarkets.com/ 

 

I see 600 iPhone jobs posted on oDesk, just for the month of October 2009. If each job takes six months, we need 3600 experienced Objective-C developers. How many iPhone developers are there? oDesk reports that they have 1,857 iPhone developers, but that probably includes people who just mention that they own an iPhone. How many of those have focused on the iPhone marketm and have taken the time to learn the platform? oDesk reports that they have 765 candidates who have the word iPhone in their title. That sounds like a more believable number, and consistent with what I know. I remember reading somewhere that oDesk only fills 25% of their iPhone jobs. Which is consistent with the 765 number. I record 658 candidates in my iPhone database accumulated over 10 years.

 

We just don't have enough experienced Objective-C developers out there to fill the demand. Something needs to change. Sure newbies can get the apps to run, but we need to make big changes to how this industry is structured. I hope that the experienced developers will share their experience by publishing reusable components. In so doing they allow the other developers to accomplish a lot more, and will distinguish themselves from the newbies.

 

“Compared to all of the other embedded systems I've developed for, the iPhone is a veritable utopia of developer goodness.” Micheal Ellis

I have never seen as productive a single developer environment, as the now deprecated ZClasses running on Zope, ZODB, and Python.

 

On March 16th of this year, I started writing an iPhone application TextFaster. It has big keys to make it easier to type. It is now 8 months later, and I am only now uploading the app to the iphone store. Since the iPhone is so easy to use, hiring managers expect it to be easy to develop for. This is simply not the case. The disconnect between expectations and reality angers some developers. It confused me, and led me to write this article. A better understanding of the issues made me realize that there are several things we can all do to speed up development. In the future, I will be assembling new applications from existing software components.

Let me start by saying that iPhone App development is way easier than any embedded or cell phone system I know of, with the possible exception of Python on the Nokia Maemo platform. And of course iPhone development is way harder than Linux based Python development. Understand that it is all relative, which is important in putting this article in context.

 

 

Which keyboard do you prefer?

 

I think that it is no one thing that makes iPhone app development so hard, rather it is multiple things. Part of it is related to history. Part of it is related to the hardware. And part of it are things that I hope Apple will fix in the future. So I have organized this article into three parts; First I write about why fundamentally it is hard to write for the iPhone, then I talk about specific problems that Apple can fix, and finally I talk about issues that are outside of Apple's control.

 

Fundamental Issues

 

Multi-Touch Interface

 

I built these multi-touch interfaces. Mostly they work. You can slide your fingers around, when you slide on, the key is pressed. When you slide off, it is released. It is only when you raise the finger, that the button is acted on. I still occasionally get a button that stays highlighted when the user lets go. I have no idea why. I am not even sure how to debug it. This processing of multi-touch events is not at all the sequential type of algorithm that I am used to. It is just hard. It is one thing that adds to the level of difficulty.

 

The #%&@? screen tilts

 

I had all the code working in landscape mode, and the users say they want portrait mode. The number of buttons are different. The positioning of the buttons are different. Some code can be shared, others has to be modified. Data has to be saved across the different tilts, even though the view controllers are being released and recreated. And when you tilt, not only are buttons stretched, but some have to be moved to fit. I have never seen anything like this.

 

Memory Management

 

There is limited memory on the iPhone. So we have to manage it carefully. Memory management on the iPhone is not that hard, but it is a little tricky. It is a big accounting problem. You have to remember to release all the things you freed, but not before they are being done being used. Frankly I think some code generation tools could do this all for me.

 

Missing Garbage Collection

 

In Python, Smalltalk, and even the mainstream release of Objective-C, garbage collection is supported. When I am done with an object, I forget about it, the garbage collector cleans it up for me. In contrast, on the small-memory-footprint iPhone, there is (wisely) no garbage collection. I have to do it all myself. Not a huge issues, just one more thing slowing down development.

 

Not knowing what we are building

 

I asked people, and they said that they needed a keyboard with bigger keys on the iPhone. Made sense to me, so I first I build a chord keyboard. Then everyone asked me to build a one-touch keyboard. So I did. Then they asked for a portrait mode keyboard. So I did. Then they asked me for a Qwerty keyboard. I will do that next. And then I expect them to ask for a chord keyboard. I am joking. My mentor says users don't know what they want.

 

In the meantime it turns out that the blind users just love my keyboards. I never expected it. Their needs are significantly different than I ever planned on. And so it is with the iPhone. You do not know where it is going. You jump off the cliff, some of us lone wolf entrepreneurs take a running jump off the cliff. We do not know where we are going to land, but by landing there before anyone else, we get to stake our claims. So it is really hard to plan on how long it will take to build something, when you do not know the end thing that you are building. Sure I had clear vision and plans and specs. Until all of that changed. Because really on such a new platform, people do not know what they want. I spent several weeks at TechShop, a do-it-yourself workshop in Silicon Valley, just showing the application to multiple people. Really no one person gave me a clear vision. It was only by integrating feedback from lots of different users that I was able to figure out what is needed.

 

Design Methodologies

 

There is a huge difference between the software visions of pure OO developers using the Smalltalk, Delphi, Objective-C or most Python developers and the mind set of those who do functional decomposition on database applications or C/C++ languages, or Visual Basic. Even for the message-passing purists like me, it took me a little while to grok the various messages being sent to my app from the iPhone world. For those not used to this way of thinking, it may be quite a nightmare. While I really can't speak for those people, I did need to mention this point.

 

It is embedded development

 

Traditionally embedded development has been very hard. Apple has made it so easy. Push one button and the application compiles, downloads, and starts running. Just brilliant. But it is still embedded development. The application has to be pushed through that usb cable, and when I have a lot of files to download each time, one for the sound of every letter in every language, it just takes time. Sure I can disable the sound downloads for development purposes but it still just takes time. And worse yet, every time I try to run it, it asks me if I want to save the file, then it asks me if I want to stop the running application. Give me a break. You can be sure Apple will fix it very soon.

 

Issues within Apple's Control

 

Getting the software license

 

My legal address is in Hollywood, but the software registration thinks that 90029 zip code is in Los Angeles, so my application for a license to develop on the iPhone took about 3 months to get. At least that is how long it felt like. I met another person who had similar problems. It is not just my credit card, my entire family tried to get me a license, eventually my mentor got it for me. And eventually Apple did fix the problem, but it certainly wasted some of my time, and caused me intense stress.

 

Broken Development Tools

 

I hate to say it, but there are bugs in Xcode. It has crashed on me a number of times. Just yesterday two of my sound files disappeared. I know not the cause, but Xcode is getting the blame. I have had to reload things into Xcode multiple times. This appears to be standard practice within the support groups. I load in new software files, and it puts them in the root directory, rather than in the Classes directory. I still do not know how to move Files in Xcode, once they have been loaded in. I am not saying it is impossible, just that I am not smart enough to figure it out. The good news is that it looks like Apple is hiring someone to fix this problem.

 

Complex development tools

 

There was a web page that showed why Google and Apple were successful, but not you nor I. Does anyone know the link? Google has a simple home page with one field and two buttons. The iPods have 4 buttons. Then your or my web app has a million fields and buttons. That is how Xcode feels to me. Just way too complex. Steve, please turn your attention to this problem. You know how to make a great user interface for developers. Please do it.

 

The simulator does not support BlueTooth

 

I expect my next application will use BlueTooth. Since the iPhone simulator does not support BlueTooth, everytime I want to recompile, link and test my app I have to download it to my device. Worse yet, I have to download it to two devices. Or maybe even three devices. I fear I cannot do them simultaneously. This is going to be so painfully slow.

 

Digital Rights Management

 

No developer wants Apple to have a stranglehold control on execute permissions. But we all secretly admire Steve Jobs for having accomplished that. But please make it easier. I was a student of Ron Rivest, the MIT professor who patented the RSA algorithms. While I do not know the details of the complex math, they are easy to understand. There is a public and private key. I hold the private key, everyone else gets the public key. One can encrypt with either key, and only the person holding the other key can decrypt it. Really easy to understand.

 

Now compare that to the Apple DRM. I have a developer profile, a distribution profile, and a release profile. When I add a device, first I have to add the device, then i have to tell each profile to use the device. Well at least I tell the development and beta profiles, but not the release profile. And when I update the profile, I get a new profile, but it has the same name as the old profile, but if I use the old profile, which has the same name it will not work. And when I download the new profile, I have to tell XCode about the new profile, even though it has the same name as the old profile. And if one of my files has a bad name, it will tell me unzip needs a password, but it will go ahead and install, but not run. Did I get it right? You can't make this stuff up. Seems to work for me. My app works, and can be installed. But I still do not really understand the Apple DRM. The man who invented the 4-button ipod can certainly make this simpler.

 

Oh, and when I run my Beta Tests over at iBetaTest.com, I have to ask them about their devices, and I get a file with all the devices, but if go back to the Apple store, and I register an old device along with the new devices, it throws out all the new devices. And even it it accepts them, I have to go back to iBetaTest.com and register the new profiles. Simple right. And that is just DRM. Please fix this Apple. You are better than that.

 

Broken Libraries

 

There are a few libraries in the iPhone SDK that I would like to use, but that are broken, so I had to write my own. Rounded Rectangle Button is one of them. If you want to use it, it is a hidden library. There is no interface file available. The interface file is missing, so you have to download a manually generated interface file, and update it the next time the software is updated. Even if you do that you try to subclass it but you can't. You think you did, but you did not. It is quite tricky to debug. The alloc method returns a rounded rectangle button, rather than an instance of your subclass. And the PoseAs: method is deprecated so you are not allowed to fix the problem, let alone address the need for additional instance variables. But the Broken Libraries problem is really a very small issue.

 

Missing Libraries

 

This is a much bigger issue. Both the iPhone calculator and my application allow one to slide the finger across the app to highlight different keys. Only on releasing the key is it pressed. In my case, for the blind users, I speak the name of the key, so that they can find the right key to release. Processing all those touches is a bit complex, and uses the same software, but I had to write all of that myself, I was not able to reuse the existing iphone libraries. More libraries are needed on the iPhone. The good news is that it looks like Apple is hiring someone to fix this problem.

 

Missing Persistent Object Database

 

Core data looks pretty good for making the objects in an App persistent. A single App can store its state to Core Data, access individual objects as needed and flush them from memory when no longer needed. Since there is not much memory available, and there is this Flash RAM sitting right there, it just makes sense to include an object-oriented database, and a cache of objects or object store in the Flash RAM. Core data provides all of that.

 

But the data is limited to my App. Only addresses and groups are shared across Apps. We are in the twenty-first century, with no hard drive in sight, why do we still just have a file system on the iPhone, and no persistent object-store. The Newton had a persistent object store. Was that 15 years ago? The iPhone needs a persistent language-specific object database shared across Apps. Which requires a good security model, and a schema shared across multiple developers.

 

Python has the brilliant ZODB, written by Jim Fulton of the Zope Development Corporation. It is the basis for the under appreciated Zope platform. I can store a persistent tree of python objects on the file system. A little known feature of the database is that it can also act as a network of objects. There is nothing like this in the Objective-C world. It is not that hard to do. Give me a call if you want some advice on how to do it.

 

Degrading Language

 

Many years ago, and still today, there was a brilliant language called Smalltalk. But it was and is a bit slow. Brad Cox at Stepstone took the core ideas, moved them to the C language, and thus Objective-C was born. A bit more complex, but worth it for the speed. Since then things have been going downhill. For reasons I still do not agree with, they decided to create interface files. Zope 3 did the same thing. What are Interface files? Every object responds to messages. These are defined in the source code. But some one decided to create two copies of each message definition, one in the source code, and one in the interface file. So things have to be changed in two places or there is trouble. That was the first degradation from the Smalltalk model.

 

Next Inc. moved the software to the GNU C compiler. Which is a great idea. Then they made things worse. Now when I define a variable, I have to define it in three places.

 

id myVariable; //Defines the Variable.

@synthesize myVariable ;

@property (nonatomic, retain) id myVariable;

So now when I change the variable I have to change it in 3 places. That is 3 places in two different files.

 

And things are continuing to get even worse. There used to be a function called PoseAs. My Portrait View Controller could Pose As a Landscape View Controller, and all was well. I had to be a bit careful with memory allocation, and overwriting variables, but these were reasonable restrictions. Now it is being deprecated. So I have to store all those variables somewhere and read them in again. Ouch.

 

I fear that the problem is deeper than just redundant definitions, and the app is being deprecated. I fear that the software team at Apple does not share the Smalltalk vision of networks of objects sending messages to each other. What is the evidence for this? They certainly like the C language API's. And most methods return void rather than an Object ID. And performance is a huge issue for them. But who knows for sure what their software philosophy is. The challenge is to support both visions at the same time.

 

App Store Approval Process

 

When I build my websites, I would just throw them up on the web. People would complain about bugs, and I would fix them; very fast and efficient from the developers’ point of view. With the App store, it reportedly takes them 2 weeks to approve a release. I am terrified that they will reject it, and label me a poor developer, and ignore future releases. I am terrified I will do something they do not like, and get blacklisted. And all of that slows me down, and slows down development. It would be better if the App Store had a Beta Testing section. These are apps or prereleased versions that have not yet been approved. Use at your own risk. That would so simplify my life!

 

Rigid Design Models

 

I am a heretic. I do not believe in the model view controller methodology. I believe there is a network of objects sending messages to each other, and we get to peak at it. But I have not much choice with the Apple tools. The Apple interfaces are based on MVC with user interface delegates which are view controllers. I do not quite buy into this methodology. I would like to just subclass views. But I am locked into the Apple way of doing things. Such is life. This is not that big a problem in small apps.

 

Interface Builder Demos

 

One of the brilliant things Steven Jobs did is to make these fantastic demos with Interface Builder. They look just great, but as a developer, I still do not quite understand what Interface Builder is doing. Mostly it gets in the way. Toss it and the view controllers out, and I would be a very happy man. Sure arguing against the model view controller paradigm is heresy, but in the internet era, allow us each our own religions.

 

Issues outside of Apple's Control

 

C language and Objective-C language characters and strings

 

There are two models of characters and strings floating around in this world, the C language model, and the Objective-C model, and sometimes we operate with one model, and sometimes with the other, and then we have to switch back and forth. If you are new to this, or if it has been a while since you have touched all of this stuff it can be quite confusing.

 

Windows Operating System

 

Why does the Windows operating system still cause me trouble? I am developing on Mac OS X, and installing on the iPhone OS. But sadly many of my customers are installing from Windows XP, and so that affects me. And iTunes unzips the files onto the Windows operating system. So files like *.wav, ~.wav, @.wav just cause trouble.

 

UNIX Operating System

 

Mac OS X is basically Unix, and there are some things that Unix does not like. Reportedly Unix supports mixed case file names. But that is not true. Create a file called a.wav, then create a file called A.wav and look at the two files. There is only one file. I have no idea where the other one went, or why it disappeared.

 

Conclusion

 

Impact on the market

 

So how do these issues impact the market? Well, Apple has won the battle for the cell phone market. Walk into a bar in the US and just see how many iPhones people have. Walk into any iPhone store and see how fast new units are being sold. And the customers are using them, not just leaving them on the table. Every Independent Software Vendor wants to target the iPhone. And every consumer wants the iPhone, because of all the apps. As Wozniak said: "Game over." Steve Jobs won.

 

What about the Google Android phones? They support a Java development environment. The joke goes: Say you have a software problem to solve. And you choose Java. Now you have two problems. And yes, that is a flippant analysis, for a more serious analysis go and read, "Why I need Objective-C", Journal Of Object-Oriented Programming. Christopher Lozinski September 1991 - http://www.tenon.com/products/codebuilder/Objective-C.shtml. Still the best article on this topic. I need to update it and publish the new version on the web.

 

What about the Nokia Maemo environment? Now this is much more interesting. With Nokia, I can run Python applications on the client cell phone. You see the consumer is not the only marketplace. There is also the corporate custom apps market.

 

Certainly it is smaller, but it is still significant. If you are a corporate developer, and by training I am, then you have to look at the software tools on the client and on the server. Apple no longer supports Objective-C WebObjects on the server, so if I run Objective-C on the client iPhone, then I have to run a different language on the server, and I cannot move my code back and forth between client and server. In contrast, if I am a corporate developer using the Nokia platform, I can run python on both client and server, I can move my code back and forth, and better yet, I can move the code back and forth at run-time. With the python-based Zope application servers, I even get restricted python, meaning that I can safely move someone else's code onto my client or server at run-time. That is a developer's dream. And while there is no business case for doing that, to be competitive, Apple has to offer Objective-C WebObjects on the server. Which is great, because then my database of iPhone developers, which include 10 years of data on WebObjects developers, will once again be a very valuable Internet resource.

 

Apple gets it. Literally as I was writing the last paragraph, (on November 9th, 2009) I received an email from Apple, inviting me to the "Apple Snow Leopard Server tour." They understand the importance of the server for the corporate market. And even if they are not planning on resurrecting Objective-C WebObjects, their customers will tell them it is needed. And Apple listens. Now if they could just throw in a nice Objective-C Object Database, I would be a very happy man.

 

And if Apple would get rid of that Digital Rights Management stuff, I would have nothing to complain about. Or at least make it easy to use!

 

Sidebar

iPhone Object Libraries

The second biggest risk to the iPhone App investor is that someone else will beat them to market. The investor can double the number of developers, but that will only decrease the time to market by a third, and it will increase the management complexity and cost. Really the only way to make iPhone App development easier and faster is to reuse existing Object Libraries. Since the days of Brad Cox, people have been dreaming of reusing Object Libraries, now the time has come. I started a directory of iPhone software components. If you have libraries, or need libraries, please send me an email.

 

So how does this work? We start with your application specification. Then we plug in the libraries needed to build it. Realistically the libraries will need some customization for your application, so we also hire the developer to fix and maintain the libraries for you. He then reports to your developer/system integrator, who reports to you. There is a nice clean management structure, and time to market is significantly reduced. Emotionally it is so much easier than trying to build it all yourself.

 

What is the impact? Well I was just burnt out from writing software for the iPhone! It is just too slow and painful. I asked myself what can I do differently? Now I am happily shopping for libraries, and polishing my libraries to give to other developers. This is much more fun.

 

Furthermore, it has freed me from the low-level grunt work of building the software required to make my app, and allows me to focus on the higher level issues involved in building a Content Management Framework for the iPhone. I am happily back at work on software development.

 

About the author

 

Chris Lozinski went to MIT, and U.C. Berkeley He started being an Objective-C developer more than 20 years ago. Then when the whole world jumped on the C++ fad, he stayed with Objective-C, and later upgraded to Python. He is now an iPhone developer, a Python developer and a recruiter. He runs both the iphone developer resume database, and the python and zope resume database. He is the author of the text faster keyboard for the iphone. He is available to help you with your problems. His company has a lot of experience with outsourcing.

 

http://www.freerecruiting.com/