Why is iPhone Development so hard?

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.

Why Objective-C is the language you want to use for development.

Given that Python requires too much hardware, Objective-C is the best choice for handheld apps. In September of 1991 I wrote the article "Why I need Objective-C". It was published in the Journal of Object Oriented Programming, JOOP now defunct. It described things I could do in Objective-C, but not in Java or C++. I need to update it, and republish it on the web.

FreeBSD

FreeBSD is the basis for the Mac and iPhone OS and runs my servers. Better yet, for a new App server, run Mac OS X Server.

Geographic Search

Click on the map to see where iPhone developer candidates live and work. Or search for Candidates in your region using the options below.

North American Candidates
European Candidates
Indian Candidates
Chinese Candidates
Middle Eastern Candidates
Australia and New Zealand Candidates
Other Candidates

What should you use for your iPhone App Servers? Until Apple resurrects WebObjects Objective-C, my recommendation is Zope.

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.

If you want to build an iPhone peripheral, Techshop has all the equipment you need to build a prototype. They offer many great classes, and the other members have a wealth of relevant expertise.

Here is a clickable screenshot of the TextFaster keyboard.


Here is a screenshot of the iPhone keyboard.

Which do you prefer?

We use Freshbooks to track the time spent on your projects.

Host your iPhone App Servers at RootBSD. I run my servers there.

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 market 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,

Why is iPhone Development so hard?

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 web developer environment as Zope 2. Zope 3 looks even better. Christopher Lozinski

I just finished writing an iPhone application TextFaster. It has big keys to make it easier to type. Writing the application was so much harder than I expected. This article explains why.

Since the iPhone is so easy to use, investors and project managers expect it to be easy to develop for. This is simply not the case. There is a huge disconnect between expectations and reality. This article describes in detail the technological issues that delay iPhone software projects. A better understanding of the issues shows that there are several things that can be done to speed up development. Software architects should be assembling new applications from existing software components. Project managers should outsource as much work as they can. Developers should use a source code control system.

It is important to put "hard" in context. In my opinion, iPhone App development is much easier than development on 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 much harder than Linux based Python development. So what makes it as hard as it is?

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

Apple Sets High Standards.

The iPhone is gorgeous. The iTouch is even nicer. All of the Apple Apps are just brilliant down to the pixel level. Apple just sets really high standards, and that takes a lot of hard work for all of us to keep up.

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 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, everytime 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. I hope this gets fixed.

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 that I cannot do the two downloads simultaneously. This is going to be 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? Seems to work for me. You can't make this stuff up. 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.

Apple made a strategic decision to allow multiple applications all separated by firewalls. This prevented Apps from damaging each other's data, and Apple getting the blame. So there is no shared object database, and it is likely to remain that way.

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. While Core Data does much of the same, ZODB is also a real database with optimistic concurrency control.

So how does one share data across Apps. Right now with cut copy and paste. That has its limitations. Technically it is pretty easy to solve this problem. Run a shared database on the server, and copy updated versioned information to each of the Apps document directory at App start time. If any App updates the database, it gets passed to the server, and then shared among the other Apps. It is easy to write the server. What is harder is to make the business case for this. How does one get all the App's authors to share data?

Degrading Language.

There is 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. In order to manage complexity, the language gods decided to create interface files, which define the interfaces to objects. Zope 3 did the same thing.

What are Interface files? Every object responds to messages. These are defined in the source code. The interface files define the message interfaces to the outside world. It does help manage complexity, but things now have to be changed in two places or there is trouble. In my opinion, 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 split among 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 apis 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.

For ten days I have been sitting on my completed App. I have not been willing to upload it to the App store. And I could not figure out what was bothering me. Then I read this article by Paul Graham Nov 19, 2009. and now I see the problem clearly. The App store severs connections between me and my users. I complete the App, I upload it, and reportedly for a month, my users cannot get a copy of it. Worse yet, suddenly 30 million users can download it, they report problems, and I have to choose between pulling the App, or letting the users get a bad version. Suddenly each iteration takes a month. And I am the guy who worried that a compile link load simulator cycle takes 3 seconds on my Mac Mini. It is just terrible from my perspective.

Apple needs to allow for the developers to have a rapid but phased release cycle. Let me pay Apple $50 to test my App, but please turn it around the next day, or better yet the same day. Allow me to release it to ten users, then hundreds, then a thousand, ramping up at the speed that my systems and servers will support. If I experience trouble I will pull the App, but allow me to pay $50, and get it back in the App store the next day.

I have now adjusted to month long iterations. My App is fine. I have showed it to lots of people. It does not crash. It looks and feels right. But it is not perfect. I have yet to have any hard core users. I do not yet know what it needs to be a brilliant App. And the App store is getting between me and my customers, and delaying the person who will one day send me an email saying that the App is great, but this is what I have to do to make it brilliant.

View Controllers.

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.

Interface builder is great because it allows you to layout complex interfaces graphically. And if you are working in multiple languages, you can lay out the different language versions of the interfaces, all graphically. That is not my situation. I have a text editor view which is a 320x480 subclass of UIView, and I have an array of 35 buttons. In my case, Interface Builder just got in the way. Make it easier for me to ignore Interface Builder, toss out the view controllers, and I would be a very happy man.

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. 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? With Nokia, I can run Python both on the client cell phone and on the server. This is great for the corporate developer. You see the consumer is not the only marketplace. There is also the corporate custom 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. 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 restricted python, I can even 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, there is a business case for using the same language on the client and server.

In contrast, 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. Well I could use the GNU tools on the server, but that has other problems. 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 Apple would get just get rid of that Digital Rights Management stuff, I would have nothing to complain about. Or at least make it easy to use!