Three Ways to Quantify Your Progress Building an App

I’ve been working on ChronoCat for about 10 months now and sometimes it’s fun to stop and quantify that progress. It’s easy to check how many times the app has been downloaded but what about measuring your personal progress and milestones?  Here are a few of the ways I keep track of how far I have come while building ChronoCat:

  1. Lines of code – You can count the lines of code in your own Xcode project by running this snippet I found on StackOverflow in your app’s project folder. ChronoCat is purely Objective-C so I removed the C++ bits from the snippet, here is what it looks like for me:   find . “(” -name “*.m” -or -name “*.h”  “)” -print0 | xargs -0 wc 
  2. Git commits – Git has a handy commit count command built right in: git shortlog -sn
    If you have multiple branches in your git repository add the –all switch to include them. 
  3. How much time has passed – For counting the time I use (drumroll please) ChronoCat! Just make a new event with your product’s creation date and you’re done.

Here are stats for ChronoCat 2.5:

  1. Just over 4000 lines (Version 1.0 weighed in at about 950 lines of code)
  2. 123 commits
  3. Started 258 days ago



How to Mess Up Your First In-App Purchase Submission

When adding an in-app purchase(IAP) to your app for the first time, be sure to follow the instructions provided by Apple closely. Make sure to dot your i’s and cross your… vision over the large warning at the top of the screen that says you must attach your first IAP to a new version of your app. This means it needs to be added after you create a new version in itunesconnect but _before_ you upload the binary for review. 

I thought the pending status on my IAP meant it would just automatically be reviewed with my app during its next update. Wrong! On top of that screwing up your first IAP is not grounds for an expedited review so will have to wait another full review cycle to fix your broken IAP (which was only about 4 days in my case so not a huge issue). In the interim I just threw a bug warning into my app’s “What’s new” section that IAP didn’t work and a fix was on the way. 

Here are some great articles from Apple that include step by step instructions on how to not mess your first IAP up like I did:
1. Adding In-App Purchase to your iOS and OS X Applications
2. Submitting your first in-app purchase product

How to Transition an Existing App to Core Data

The initial structure of my app ChronoCat was super simple: Just one custom class, all objects from that class are thrown into an array, that array is displayed by a table view and is written/read from disk as needed. Here is the basic process I used to migrate the app away from objects-in-an-array to Core Data:

  1. Make a Core Data entity to represent my custom class.
  2. Added all the @propertys from my custom class as attributes to the new entity. (@propertys only at this point, methods come later) .
  3. Make the NSManagedObject Subclass of my new Core Data model.
  4. Make a category for my NSManagedObject Subclass to store any methods I had in my custom class.

Now that the swap from a custom object to Core Data was complete the last step was to create a class to import the user’s existing data into the new Core Data model. Here is what I did for that:

  1. Made a new group in Xcode and added the old custom class used in the initial version of ChronoCat to it. The new version of my app is a complete rewrite so the old class file was not already in the project.
  2. In that same group I added a new class to put all my import code in.
  3. The import process is to check for the old data file in the app’s document folder, if found load the data from binary back into an NSArray, then use a for loop to cycle through the objects in the array and save them as a new NSManagedObjects.
  4. Once that’s done clean up by deleting the old data file.

The whole process was shockingly painless and has been a great way to get my feet wet with Core Data. The new version of ChronoCat that utilizes Core Data is currently in review and will hopefully be approved and available soon.

Great iOS Design Cheat Sheet

Here is a handy design cheat sheet from that includes screen resolutions, PPI, icon sizes, bar sizes (both nav and tab), and more. As someone who constantly forgets the height of the iPhone 5/5S screen and can’t remember icon dimensions to save my life I am very appreciative for cheat sheets like this. 

I went ahead and added this link to my iOS resource list so I can stop Googling for those measurements every 2-3 weeks.


No Identities Were Available Error When Validating an Archive in Xcode

Ran into an incredibly annoying issue the other night when trying to upload an app to the App Store for review. When I would try to validate the archive it would give an error saying “No identities were available” and “An administrator must request identities before they can be downloaded.”

After fiddling around for a bit not making any progress I found a great post from Anthony Tietjen on how to troubleshoot validation issues. After the bundle IDs matched everything ran smoothly, I was able to get the app validated and uploaded without any further issues.