Want to start developing iOS apps?

Here is an interesting Quick Startup Guide from Apple: Start Developing iOS Apps Today. A must read if you are just starting your endeavour.

Building an iPhone app is simple? Think again.

Here is an interesting article from Kent Nguyen on what it takes to make or build an iPhone app. Not an easy task.

About making rounded rectangles

Today I want to share this really interesting and well done blog post from Mike Rungle about making nice looking rounded rectangles in your iOS application interfaces: Making Round Rectangle Look Great. Mike's works is very impressive and I love everything he does graphically speaking. I wish I could be as good as this guy!

Small GitHub crash course from Cocoanetics

I just read the Cocoanetics crash course on GitHub's Fork, Pull requests. For beginners, if you want to get an idea what GitHub is all about, head to Cocoanetics blog post.

No, we're not millionaires!

Being an indie iOS developer means a lot. Some could say we are our own boss and this is great. Others would say that we get all the benefits for our app sales (minus 30% for Apple). I would say that being an indie means everything is hard work, nothing is a given. Some others think the same. See You Guys Are Millionaires Right?

Custom UI Components Database

Looming to kick start your iOS development project with ready made components? Maybe you could look at Cocoa Controls. You'll find quite a few iOS custom controls that you can use for your own apps.

How to start building an app: from the end

How often do you get this question: I have an idea for creating an iOS application but I don't know where to start. Easy: from the end. Here is an excellent small article on starting to build an application. http://mur.mu.rs/?p=327

Learning the hard way

Here is a little story I want to share with you. This is my story. A story about learning the hard way as an indie iOS developer. As you may already know, I am the developer of an iOS app called "Ultimate Password Manager" (UPM for short). This was my first iOS app that came out on june, 9th of 2009.

Last year I wanted to speed up the application startup sequence. On an iPhone 3GS, ten seconds was required to start, initialize internal data structures and be ready for use. I thought it was too slow. So I went ahead and looked on the web for possible solutions. Multi-threading was one of them. UPM was loading the password database on the main thread. The obvious solution to me was to do stuff on a separate thread using NSOperation calls. A good read on the subject is Jeff Lamarche's book "Beginning iPhone 3 Development: Exploring the iPhone SDK". I read on the subject and started to use NSOperation calls in UPM release 2.3. After analyzing my code I found out the only things that could be done on a second thread was the loading of the password safe database (a simple NSMutableArray of dictionaries).  I decided that saving the databases using the same NSOperation was a good idea too.

After many weeks of testing on my own development devices and via the good service TestFlightApp, I made the move and submitted my new release to the App Store for review. After release, users of UPM were getting a 30% application launch time improvement. In return, I got a nightmare.

A few users upgrading to UPM 2.3 started to send me reports of losing their passwords. The problem was critical: starting the application after the upgrade could corrupt the password database. What makes the matter worst for me is the fact that a vast majority of my users continue to enjoy the application after the upgrade but at some point can face the same issue. So the problem could not be in the upgrade code but somewhere else.

For an application like this, this was the worst thing that could happen. Users can spend quite some time entering data into the application, passwords and related informations like web site, description, etc. Losing all of this was bad. On top of all this, I can only imagine how a user feels when he needs to get a password for a rarely used web site only to find out that the application lost all the data.

Before getting bad user reviews in the App Store, I started to analyze crash reports. I found out that for some reasons, on some devices, the application safe's UIViewController was presented before the safe database was loaded into memory. At this point, the user saw an empty safe. After the initial shock, the next thing the user was doing was to quit the app then re open it to see if the data was there. The thing is, when UPM quits, it must save the database. As you can expect, when the initialization wasn't done properly, upon being quit or put in background, an empty database (nil) was being saved. First lesson here: I should have put initialization check in my code like: is the database logically and correctly loaded into memory? If yes, then this is ok and continue.

Some users who bought the application were also having a problem: after the first application use, when creating a new entry, it wasn't saved. For the same reason: timing issue during application initialization. The database was read from disk before being formatted. In this situation, adding an object to a uninitialized array would return nil. Hence the user saying the created password wasn't being saved. For those users who reported this issue after buying the app, the solution was simple: remove the app from the device and re-install it. The was a weird situation for the user. Most of the time, it did the trick as the timing issue between formatting the database and loading into memory wasn't occurring too often.

Now the question is: was this endeavor to optimize application launch time really worth it? Is 7 seconds really better than 10 seconds? In retrospect, the answer is no because potential buyers of the application looking at the users' review, won't trust my app.

In the next few weeks following this disaster, I was able to remove the use of NSOperation calls for the database loading. But the problem wasn't really fixed from a user point of view. The reason is very simple: many users who upgraded to the later version which includes the fix will experience the database corruption issue. Why? Remember that if the database isn't loaded correctly, what is being saved while the application quits is corrupted. What if the user won't use the app for months and a new release comes out? The upgrade, open the app to try out some of the new features only to find out that the password safe is empty!! When this user in this scenario contacts me for support he will think the new application release made him lose all of its passwords! For the user, the effect is the same, whatever version he used, he lost confidence in the app. But for me, the developer, this becomes a long lasting issue that will generate confusion and frustration in the application's reviews for quite a few versions ahead. This is a long lasting nightmare from which I can't get out simply by waking up.

In its current form, UPM 3.1 now doesn't load the database while starting up but only after the user authenticate with the application by entering a master password. This way, my app starts faster while being more secure.

My lessons to all this are:

1. Only invest time in new features that really make a difference to the user (don't sacrifice trust for user experience). This is particularly relevant if no users ever complains about slow startup time!
2. Only use APIs that you really understand well : multithreading is a complex matter in computer software and requires quite some time to master
3. When dealing with users with critical issues with your apps, be honest, admit your fault and promise that you will keep improving your app without compromising their trust again
4. Users don't read instructions provided inside an application or via a support section on the application's web site. In case of a critical issue, writing blog posts doesn't really help as users are angry and rush out to put bad reviews on the App Store instead of asking for help.
5. People who enlist their devices on TestFlightApp to test your apps don't always test a lot.  A minority will spend a lot of time, the others are simply peeking around and that is it. People are busy with their own things. So my bugs didn't get caught.

Hope this helps others.

Hey beginners, something for you

Here is an important subject for iOS developers who are starting their endeavor. What hardware should you use for developing and testing?

Read the complete answer on this excellent blog post by @cocoanetics

http://www.cocoanetics.com/2011/08/hardware-for-developing-and-testing/

How to add a tag in a subversion repository

So you just submitted your app to the Apple's review team. Before starting work on the next release of your app, you should create a tag in your subversion repository to keep a marker of the sources for the submitted release. Simple to do:

svn copy file:///Users/username/Subversion/UPM/trunk/uPasswords file:///Users/username/Subversion/UPM/tags/3.1.0.357 -m "tagging UPM Version 3.1.0.357"

That is all. Now, in Xcode's Organizer, click the Repository tab then expand the tags node. You'll get all the tags you defined.