iPhone Development and teams

Since I've been self employed again, I've been working on 3 iPhone development projects. On 2 of the projects, I'm the lone developer (at the moment), with a QA resource and a project manager. On the 3rd project, at its peak, we had 5 developers, 7 or 8 QA folks, and a project manager. This last project has made it painfully obvious to me (more so than the other 2), that Apple has designed iPhone development around the loan developer that has no formal QA.

Why do I say this? Well, for a number of reasons. First off, the whole provisioning thing is quite problematic for a team. The concept that only the team agent can do AdHoc and AppStore provisioning is not realistic. The Team Agent has typically been someone that is the CTO of a company or someone else that is not involved in the project on a day to day basis. We have to pass around the agent credentials in order to do provisioning (admin privileges are not enough).

Second, Xcode's Build and Archive is not maintainable for a team. If one person does the build, another person on the team may have to examine the crash logs and therefore need the dSYM file in the archive that is built. The archive needs to be checked into source control, but Xcode hides it somewhere else.

Third, with Build and Archive in preparation for deploying as either AdHoc or AppStore, the developer is building the app from his local source tree. Almost all projects that I work on are built using a build script so that the builds are done from source control in order to have a reproducible build. Building an app from the local source tree is quite dangerous as a developer may have forgotten to check in a file and then the next person comes along may not be able to build the app.

Fourth, Xcode's managed provisioning isn't all that helpful. It generates a completely wildcard provisioning file which I'm not really sure how it affects different apps when there are different app IDs. In addition, most of the devices that are provisioned aren't on developer machines, but are QA devices and other devices.

Fifth, the 100 device limit for AdHoc provisioning may sound like a lot, but if you have a team with 5 developers, each with 3 or 4 devices (iPhone 4, iPhone 3GS running 3.1.3, and iPad), and then have 7-8 QA folks with 3 devices each, you can see that the devices get eaten up quite quickly. This isn't even considering all the devices a client may want to use for testing. I understand that Apple doesn't want people using AdHoc provisioning to get around the AppStore, but here is a case where we're doing the right thing and could run into issues.

Sixth, Xcode's ability to deploy an application to the AppStore is another area where it is problematic for the team. This requires that one of the developers does the submission. In theory, QA should do the upload once the build has been approved. The way around this, of course, is to use the Application Loader to handle it. However, the Application Loader application is half baked and very much geared to only working on one project. You have to go back through the setup wizard to change accounts (I've done uploads for 3 different projects).

While it is true that probably 95% of iPhone development is done by single developers, some of the top applications are done in teams and I think the teams are still trying to figure out the best way to handle development.

In my next post, I'll outline some of my ideas/practices for effectively working in teams on iPhone development.

Abstract Photo

My son loves playing with our camera and takes lots of pictures. Most of the pictures are blurry and we delete them. However, sometimes he takes a picture that looks pretty good. He was playing in my office a few months ago and took a picture of the mouse pad (a funky HP one; it was the largest one I could find with a smooth surface).

Click on the picture on the left to see a larger version.

Open source is not always the answer

I've been a huge fan of open source software for years and have contributed back to a few projects including the Palm OS Emulator and pilot-link. I've used a number of open source projects in my own applications and, of course, follow the license for attribution (I don't touch GPL code). Years ago when I was a lot greener, I used open source thinking that it must be perfect and treated the code at black boxes. This bit me on at least one project where we had to fix the code for years due to assumptions by the developer.

Now that I have more years under my belt and have done some of my own open source, I take a different view of open source. When I incorporate open source into my projects (with a few exceptions such as Sparkle that has been thoroughly tested), I closely examine the code and make sure I understand it. This takes time, but makes it less likely that I'll get bitten. I've seen a number of projects where developers find open source, shove it in an app, and call it a day without understanding what it does. I found one piece of code that completely went against what Apple has said to do in determining if a feature exists on a device; in another application, I found extremely complex networking code that may have been unnecessary (networking code is hard and the more complex it is, the harder it is to debug).

The main thing to realize with open source is that it was written by humans that can make mistakes and do! I have a large collection of open source code on my machine for reference (someday I'll catalog all that I've found) and use it to save time. I'm not saying that developers should reinvent the wheel for every piece of code, but they should be cautious when shoving code in their applications.

XPAL Power and the MacBook Pro

Last year I wrote about hooking up my XPAL Power XP 18000 to my MacBook Pro. My method was a bit wacky, but worked fine. As I was surfing the web the other day, I found that XPAL now offered a connector to the MacBook Pro. Very interesting, I thought, so I looked at it. As Apple has a patent on the MagSafe connector, no company has been able to create a knock off cable. What did Energizer do? Well, they created a cable that connected the battery to a female connector that you then use the Apple airline adapter with MagSafe connector. Very clever, but an added expense.

In my case, I already had the adapter, so I used my free tips for life and for $4, I got the connector. The connector works fine and is a bit cleaner than my solution. However, there is a slight difference between my cable and the XPAL Power solution. The Apple airline adapter doesn't charge the computer when connected (the MagSafe connector has electronics in it to indicate if it should charge the computer). The cables that I used were regular charger cables, so they charge the computer when the battery is connected. In my case, the battery heated up quickly as it was charging the computer. With the XPAL Power solution, my computer didn't charge, but the battery stayed cool.

So, having said all that, I think that the XPAL Power solution is better than my solution as I'm seeing better battery life. As I compile code a lot, my main battery only lasts about 90 minutes, so if I can get another 1.5-2 hours out of the external battery, I'm quite happy. I believe that the XPAL Power is now going to give me that (before I maybe got an extra 1 hour to 1.25 hours.