When total submission is a huge triumph

At last -- PasswordRN is submitted!

I have spent all day, literally, working on getting the first version of  PasswordRN submitted for app review in iTunes Connect (the developer’s side of the iTunes marketplace).  Sheesh.  Talk about  a process that is TOO HARD!

The morning wasn’t bad.  I wanted to re-organize the initial master password screen.  I thought it would be friendlier to have both password text boxes high enough that you could type in both with the same keyboard instance and not have to hit done after the first entry and bring up the keyboard again before you could type the confirming version.  So I did that and also added a bit more instruction text.  Nothing is easy for me on a Mac, but I knew what I was after and the design environment is just enough like Visual Studio that I could git’er done.

I used that exercise as a way to work through my version numbering scheme and be sure that updating the app didn’t destroy the old password list (kind of important).  At least as sure as anyone can be given that you can only test via ad hoc provisioning and not via the iTunes store.  I HATE that you can’t really test what you are going to release or test installing/updating what customers are going to install/update.  How totally contrary to all good software development practice.

But, the updating worked fine and, in the course of testing it, I found what seems to be a real defect.  I had already changed the default user settings for the app to be a 1 minute timeout for the password entries and a 1 hour timeout for the master password.  Jacob had them both set for 0, which effectively turns both timeouts off.  My basic rule, developed over many years, is shipped with features turned ON.  Users will identify the ones they don’t like or that get in their way and turn them off.  But they never seem to find the cool features you shipped turned off.

But when I installed the app and ran it, the timeouts weren’t working.  I fired up the debugger and determined that, when we tried to get the values from the settings database, they were returned as NULL.  But if I went over to the settings app and touched them — not even changing the value, just touching it — then came back to PasswordRN, they came back as valid values.  So it looked like an initialization issue.  Long story short, I found a way to fix it but I’m not completely satisfied — we’ll go back to that code some day when we are iOS smarter!

So by lunch time, I had the app just right, built and tested.  Then began my travail with iConnect.  This included a run down to the office for bank info.  I HAD gathered it all together in advance, I just didn’t have it with me on the day I needed it.  (But that was ok.  Daughter Becky needed cheese for the good dinner she’s about to serve us, so I included a quick stop at the store.)

But my professionally designed 512×512 icon had ROUND CORNERS.  Horrors.  And the obvious screens shot tool makes screenshots that are 320×480 instead of 320×460.  Unacceptable.  And just, well . . . details, details, details.  The one good thing I can say about the iConnect interface is that, although it won’t let you save your partially filled-out form, it seems to have just about an infinite timeout period.  I’d go away and work on graphics for half-an-hour and then come back and it would still be there waiting.

Finally, got through the form and had my meta data set up, for good or ill, and then it took me about five iterations to get the executable built right.  App identifiers, entitlements, code signing — I screwed each one up at least once.  All I know now is that iConnect thinks my executable is acceptable, not that it will work right for my users.   So I’ll say it again.  Any process that requires that you test one build and submit another does a disservice to both developers and end-users. It just can’t be a good idea.

Leave a Reply

Your email address will not be published. Required fields are marked *