[a Weblog by Aaron Griffith]

I originally made “My Hoop Champ” as an app to track my own kids basketball games and share them with family and friends.  I couldn’t find an existing app on the app store that did everything I wanted with a nice, relatively simple UI.  I came up with a couple of prototypes and finally settled on something I liked.  I worked on the app in my spare time over an 8 month period.  I was constantly using the app at my daughter’s basketball games as I developed it.

I didn’t expect to make much money on the app, so I decided to make the app free with donations in the form of IAP’s in denominations of $0.99, $1.99, $4.99 and $9.99.  In the few months that the app has been available, I’ve probably made about $50.

The only real revenue goal I had with the app, was too make enough money to be able to sponsor one of my daughter’s teams.  I went ahead and sponsored her team anyway, even though I was well short of that goal and current projections indicate it would take three years to pay for a single $250 team sponsorship.  I wanted to do it because I was excited about the idea and the kids thought it was awesome and got a sense of pride from wearing the uniform sponsored by the app their dad made.  While it would be nice to be one of the App Store lottery winners, I have no problem with how the app has done and there are a couple of reasons for that:

1. I built the app to track my kids’ basketball games.  It does that and brings me great joy and delight.
2. According to the analytics, people are using the app, and based on reviews and email feedback, they appear to find it useful.
3. Real developers ship, and I’m proud of that.

There was another benefit from creating this app that I only discovered in the last month and has turned out to be a personal gold rush for me.  Through most of the development of the app my kids were playing in basketball games while I tracked them.  Recently, my family has been going to watch some of the men’s and women’s basketball games from our local college.  During these games we have been using “My Hoop Champ” as a family, together, to track our favorite players.  We even started to bring an iPad to the games so we could track two different players and compare them after the game.  It has been the best benefit from developing the app and though it is a different kind of gold rush, it is well underway for me.

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring new posts every day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.

I recently released a utility app for iOS that I use to track my kids basketball games.  I used a iterative process to come up with a minimum viable app I could put on the app store.  I purposely published it with quite a few things left incomplete.  One of those things was iPhone 5 optimization for the larger screen.  I came up with what I think is a clever way to use the extra screen space until I finally get around to optimizing for iPhone 5.

I decided that some A/B testing would be the perfect way to use the extra screen space on the iPhone 5 until I was ready to the full optimization I had in mind.  The app I released is free and has In App Purchases in the form of donations.  You can donate in amounts of $1, $2, $5, and $10.  The app has been out a couple of weeks now and has not made a cent.  I suspect the IAP strategy for a utility app is probably not the way to go, but that’s a blog for a different day.

The IAP purchases get displayed toward the end of the use flow and can be navigated to from the main screen with two gestures.  On the iPhone 5 there is a big gap at the bottom of the main screen, as you would expect for an app not optimized for the larger screen size.  I decided to use that space to display a button that goes directly to the IAP view.  This puts the IAP just one gesture away.  More importantly it is on the main view of the app where most users spend about 95% of their time using the app.

Here are two screenshots showing what the apps look like on an iPhone 5 and an iPhone 3GS.

Right now the IAPs are accessed through the “information” button seen above in both screenshots.  It’s a pretty small button, and maybe not that obvious.  That “$” button is huge though and maybe even obscene.  The more obvious IAP button is present on the iPhone 3GS, of course, it just appears off screen and is unable to be touched.

If I start getting IAPs on the iPhone 5 then that will be a good indicator that I might want to make the IAP button easier to find.  I suspect the IAPs will still be low and that the real solution will be to make it a paid app or come up with more viable IAPs.

I have no idea what the results will be, but once the update is approved, and I get a few metrics, I’ll report back on what I discover.

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring new posts every day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.

I really like iOS development.  Ideally, I’d like to have a full time job developing games for iOS.  But really, I just want more experience doing iOS development.  I want to get better, find a mentor or a coding buddy.  With that in mind, I recently started applying and interviewing for junior level positions.  I even asked a couple of local game developers if I could work for them for free in exchange for mentoring.  It didn’t really go as I had hoped.

But I didn’t give up.  I sat down and started writing an email to Ian Marsh of NimbleBit, inquiring about employment opportunities and offering to work for free in the mornings and afternoons a couple of days a week in exchange for mentoring.  Blah, blah, blah.  All stuff I had written or said before.  It occurred to me that emails were not really getting me very far and I’m just not very good at communicating my enthusiasm and passion for iOS and games.  That’s when I got the idea to do do something big and different.  It had to be an attention grabber that conveyed my determination.  I got set on the idea of a custom app that would somehow incorporate my resume.

It sounded good, in theory, but the reality was they probably receive tons of emails from people smarter and more qualified than me asking for a wide range of things.  I also imagined if I had received an email from someone I didn’t know very well asking to install or TestFlight some random app, that I would be skeptical.  Besides, a single app wouldn’t really be able to showcase all the apps and prototypes I had done.  It was at this point I got the idea to mail them my entire iPad2 with all the apps on which I had worked.  I could put my resume on there and even write a custom app to sell myself.  It seemed like an OK idea, but there were things to consider.

Would my iPad be safe?  Didn’t think much about this one, I figured if I insured it, I’d be covered.  How do I get my iPad back?  This required a little more thought.  I didn’t really think the NimbleBit guys would keep it.  I mean, they are iOS developers, they should have plenty of devices on hand, right?  And they did donate a bunch of iPads to a school.  I didn’t want them to feel obligated to talk to me if they didn’t want to, so I had to come up with an easy way for them to opt out.  But there was one more question.

What if they think I’m insane?  I had quite a few reservations about this one.  I didn’t want to cross the line from enthusiastic fanboy over into the area of creepy stalker.  I also  started to wonder if this was considered a “leave behind”.  I spoke to a friend of mine about this, and he reminded me about the crazy guy who camped out at the Blizzard HQ.  The thing that my my buddy pointed out, besides the fact that this guy didn’t get a job with Blizzard was that the Internet made fun of him.  I took pause, but it didn’t take long to come to the conclusion that if the crazy Blizzard guy didn’t at least try then there was no way he would even have a chance to accomplish his goal.  I suppose the Internet may still make fun of me, that remains to be seen, but I had to try.  Besides, at this point I had already finished the app and was pretty proud of what I had learned and accomplished.

I went home put a hand written note to the Marsh brothers on my iPad explaining why they were getting an iPad in the mail and giving them an easy out to return it if they weren’t interested.  I boxed it all up and it was ready to go.  The next morning I stopped by the post office on my wake to work and it was off.  Whew!

I didn’t expect to get a response for at least a couple of days, if at all.  To my surprise, by that evening I saw this on Twitter.  Followed shortly, by this tweet.  I was encouraged!

What was on the iPad?

I completely reset my iPad.  I put all the default apps into a single group and moved that group to the second page of the device.  On the first page, I made several other groups that included contract apps I had done, protoypes I had created, apps I had done individually, and as part of a team.  I also had an app on the first page that was simply a PDF of my resume that used a picture of myself as the app icon.  I removed everything from the dock except the single custom app I had created for NimbleBit to showcase my skills and enthusiasm for iOS Development.  I made the background image on the iPad a custom image.  The custom image was basically a default iPad image where I pasted a game studio floor from Tiny Tower.  I named the studio NimbleBit.  I then created a Bitizen that looked like me and  put it on the floor.  I wrote a little note about how NimbleBit was my dream job and directions to start with my custom app.  It looked like this:

How did I create the custom app?

I was very fortunate as I developed this app that almost all of the resources I needed were available from the NimbleBit Bitizen Builder or the Tiny Tower Wiki.  Since I was going with a Tiny Tower theme, this was perfect.  I think every single image, sound, and music I used in the app, except maybe two, came directly from those resources or a screenshot directly from the game.

The app had two components.  The first component was a sort of intro page that answered a few questions about why I created the app, who I was, my contact info and what I had to offer.  While creating this app, I also found two bugs in the Bitizen Builder.  I reported the bugs here and explained that I was already helping them before they had even hired me.  Here’s a peek:

The second component of the app was a memory style game that consisted of randomly created Bitizens.  I had already coded the memory game using crude art, as exercise in clean code for myself, so I had a nice starting point.  It was a fully functional game with high scores and times.  The icon for the app was nearly identical to the Tiny Tower icon, except that instead of a Bitizen construction worker I used my own Bitizen.  The navigation between the two components used a vertical UIScrollBar to create the vertical look and feel that you see in several of the NimbleBit games like Tiny Tower, Scoops, and Sky Burger.  Here’s what it looked like:

What went wrong?

Not much really went wrong, but the one thing that did go wrong was kind of big and I’m still beating myself up over it.  At some point, after I had loaded all my apps to the iPad, my provisioning profile had expired.  I renewed the profile, but there was some weirdness going on, so unfortunately some of my apps didn’t even launch.  The custom app did work and that was the most important one.

What went right?

I learned!

I completely reversed engineered the creation of Bitizens.  Not just an image of a bitizen.  Bitizens with random hair colors, skin colors, clothing colors, hair, facial hair, hats, ties, earrings, costumes…the whole deal.

I learned how to do color overlays on a single image, preserving transparency and allowing for the randomization of skin color, hair color, and clothing color.

arcrandom() % 0 doesn’t just return zero. Many head explosions over this one. ☺

I figured out a better way to programmatically animate a UIScrollBar.

I learned about adding and implementing a custom ttf font.

I was able to apply a real-world implementation of recursion.

I created an observer and actually understood how and why I did it.

I used Instruments for the first time to track down a memory management crashing bug.

I proved to myself that I can make a game of my own if I put my mind to it.  I’m pretty sure I already knew this, but it was a nice confidence booster.

I didn’t get a job.  This may seem odd for a what went right, but by the time I was done, I was just so proud that I had done it and I learned so much that I knew it wouldn’t bother me too much if I didn’t get much of a response from NimbleBit.

The NimbleBit guys bought me lunch and gave me a tour of their sweet studio.  David, Ian, and Tim took time out of their busy schedule to meet with me and shoot the breeze about iOS, games, and just every day stuff.  Very cool, though I’m still not not sure that they don’t think I’m insane.  At least they haven’t made fun of me on the Internet…yet.  ☺

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring new posts every day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.

I made this blog post almost exactly one year ago.  At the time, I thought it was kind of a big deal.  Today, I discovered that it was not that big of a deal at all.

I was working on a project that required that code.  After I implemented it, I noticed that the the scrolling was kind of jerky and not nearly as smooth as it should be.  It was very subtle, but it bothered me enough to do some Googling.

That’s when I found this post on stackoverflow.  I was skeptical this would solve my problem, but I gave it a try anyway.  It worked perfectly, and it made my other solution seem ham-fisted.

So I ended up going from this:

- (void) animateScroll:(NSTimer *)timerParam
{
    const NSTimeInterval duration = 10.2;
 
    NSTimeInterval timeRunning = -[startTime timeIntervalSinceNow];
 
    if (timeRunning >= duration)
    {
        [scrollView setContentOffset:destinationOffset animated:YES];
        [timer invalidate];
        timer = nil;
        return;
    }
	CGPoint offset = [scrollView contentOffset];
	offset.y = startOffset.y + (destinationOffset.y - startOffset.y) * timeRunning / duration;
	[scrollView setContentOffset:offset animated:YES];
}
 
- (void) doAnimatedScrollTo:(CGPoint)offset
{
    self.startTime = [NSDate date];
    startOffset = scrollView.contentOffset;
    destinationOffset = offset;
 
    if (!timer)
    {
        self.timer =
		[NSTimer scheduledTimerWithTimeInterval:0.01
				target:self
				selector:@selector(animateScroll:)
				userInfo:nil
				repeats:YES];
    }
}

To this:

- (void) doAnimatedScrollTo:(CGPoint)offset
{
    [UIScrollView beginAnimations:@"scrollAnimation" context:nil];
    [UIScrollView setAnimationDuration:1.5];
    [scrollView setContentOffset:offset];
    [UIScrollView commitAnimations];
}

So much slicker and much more elegant.  I lol’ed at myself.

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring new posts every day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.

A couple of weeks ago, I did a post on refactoring.  This post is sort of the inspiration behind what motivated me to start the refactoring project I discussed previously.  It isn’t a terribly exciting story, but it had an impact on me and the way I think about coding and life in general.

A few months ago, my wife and I were working on our kids bunk bed.  It is one of those configurable types you can change with a few tools and some heavy lifting.  We had been working on it for a couple of hours and my wife declared, “We’re about to have a difference of opinion”.  She then went on to explain to me that she was going to do major cleaning and vacuuming of the entire area underneath the bunk bed since the bed was already apart and access was easy.  I tried to convince here that we should just pick up the few toys there and save the vacuuming for once the bed was done.  I did this knowing that there would be no way to vacuum under the bed once it was re-assembled and just because I wanted to get on with completing the task at hand.

My wife moved on with getting the vacuum and the monumental task of cleaning under a child’s bed.  I decided to go do some yard work until I was needed to help with the bed again.  I was grumbling in my head about the vacuuming under the bed and how the bed could be done by now if she hadn’t vacuumed.  Eventually, I sort of reasoned with myself that it was probably a good idea to do the vacuuming.  I made a further realization, that the vacuuming under the bed wasn’t unlike refactoring or cleaning up code as you were working on it.  I even had the thought, “damn that’s why my code sucks, I never clean as I go, because I’m so excited to just get it working.”  I don’t think this was something I didn’t already know, but seeing the analogy first hand made me make take notice.  Shortly after that I decided I need some kind of project to get me excited about just writing readable code, independent of the app or any functionality.

Sometimes, I find it amazing when simple, mundane, day to day tasks run parallel with the task of coding, marketing an app, or trying to make a living do something you love.

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring new posts every day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.

This post will be kind of short since I am at 360iDev this week.  Today is the second day and this is my second time attending.  It is always a mixed bag for me.  When I leave part of me feels like I gained a large amount of knowledge and motivation, but part of me feels scolded like a child and wonders why I’m even doing this.

Matt Drance did the keynote.  One of the the things he said was that your app is a self portrait, it tells people about you.  Not sure I like what I see, but the good news is that I’m allowed to update my self portrait.  Mike Lee also spoke.  He gives great talks and I always look forward to hearing him speak and reading what he has to say.  He said all my ideas are terrible.  I already knew that.  Harsh words meant to motivate and stimulate introspection.

Last year, when I went, there was one moment when all the expenses of the trip were justified.   It was in Nathan Eror’s session on UIGestures.  It was great, because it was something that was new for me and I could apply immediately to the Color Dog project I was working on at the time.  I haven’t had that moment yet, but there are still two days to go and I am optimistic that it will happen.

If it’s not clear by my post, I think 360iDev is a great conference and would recommend it for both new and veteran iOS enthusiasts, whether you are a developer, designer, artist or something in between.

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring new posts every day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.

I have a bad habit of not refactoring my code.  I do this for a couple of reasons.  None of them are good excuses.  My current projects is kind of mundane, but that was by design to help me become better at refactoring.  The lessons have been great and more importantly, I’m having fun with it.

There are a couple of reasons why I haven’t been very good or diligent about refactoring.  The biggest reason is because I’m impatient.  Once I get something working, I usually don’t care how it looks or how it works.  I just want to move on to the next task.  And on a bigger scale, I just want have a finished product and get it on the app store so that I can start counting my millions of dollars.

The second reason is excitement.  I’m just so excited my code is working that I don’t want to mess with it any more.  Working on something new is always more exciting for me that cleaning up old code that I know already works.

The final reason for not refactoring is fear.  Sometimes, I’m just afraid that if I change my code it will stop working.  Some people call that fragile code, but I think the code is probably not too bad, and I’m the one who is fragile.

So for my current project I decided to do something with the primary goal of ending up with a nice working app, that was readable, clean, and easy to maintain.  Code that I could show other developers or during interviews without being embarrassed.  It really sucks not wanting to provide a code sample because your code is such a mess that you are embarrassed by it.  I ended up going with an idea I had for awhile, for a simple memory type matching game.  Nothing exciting, flashy, or innovative.  Kind of boring actually.

I picked boring for a reason.  I wanted to be more excited about learning about refactoring and clean code that I was about the actual application.  My thinking goes that if I was overly excited about the app and not the learning process, it would be too easy to relapse into bad habits.   A matching game would be just challenging enough to keep me interested but boring enough to keep me focused on writing some nice, well organized code.

It has has worked out great so far.  I’ve been reading some books on the subject and working with mentors to apply what I’ve learned.  I cannot describe the sense of joy and relief I had when I noticed my viewDidLoad method had just a handful of method calls instead of being like a sardine can packed full of a ridiculous amount of logic and chunks of unrelated functionality.  I’ve even been able to gain a better understanding and use of objects, which had always kind of scared me.

The cool part about the objects, was that in the past because my code was such a mess I never knew where to even begin with creating my objects, so I would just rationalize it by knowing that the app worked and moved on to the next thing.

I still have quite a bit to learn, but I already feel better about refactoring.  I’ve gained a great understanding of why it is so important to spend the extra time cleaning as you go to save so much time later on when you are troubleshooting an issue, adding new functionality, or doing maintenance.  The best part is that it is actually fun and makes coding that much more fun.  Stoked!

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring new posts every day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.

I’ve been busy the past couple of weeks working on a non-iOS project that I hope to reveal on my next and last iDevBlogADay post.  The only real iOS stuff I have been doing is playing games.  Mostly Velocispider and Tiny Tower.

I have found Tiny Tower very addictive.  I’m not a big fan of microtransactions, so when I first started playing I only gave it about five minutes to figure out what was going on.  After that, I tuned it off and planned to forget about it.  But, I couldn’t.  I picked it back-up a couple of hours later and found it was still holding my interest.

I think the reason it has held my interest is because the microtransactions don’t slap in you the face and tell you that you suck.  The game is very playable without using any of  the IAP.  For a casual player like me the pace feels just right without spending a thing.  I’ll probably end up doing a single IAP purchase just because I feel like I’m ripping off the NimbleBit guys since the game is free.

Yes, this is a short post.  You can blame Tiny Tower.

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring two posts per day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.

I’m trying to figure out how to be a better coder.  I’m looking for suggestions.

I have a couple of apps on the app store.  Some I did solo, some as part of a team, some as contract work.  Even when working on a team, I did my portion of the work by myself.  Occasionally another guy from the team would review the code, but if it worked there wasn’t really much concern.  I have a few books that I refer to and browse the topics where I am weak.  I read lots of tutorials in blogs and watch videos.  I attend developer meet-ups from time to time.  I went to 360iDev last year and plan to attend this year.

All that stuff is great and very helpful and I have learned quite a bit, but I know my code is still shit.  Other people know it too.  I was looking at doing a contract last week and I didn’t think the first interview went well from a technical perspective.  As far as a culture fit, I felt pretty good and we had some good conversations about what makes the app store difficult, marketing, and just general iOS banter.  I didn’t expect a call back, based on the technical portion of the interview, and was surprised when I received one.  They were interested in having me do some work but wanted to see a code sample.  I sent a code sample and never heard from them again.  Before seeing my code:  interested.  After seeing my code:  not interested.  Ugh, pretty telling.

At this point, I’m trying to figure out what to do next.  I know that with practice and experience comes expertise.  Doing development in my spare time outside of my day job makes that difficult and presents something of a Catch-22 situation.

I’m curious what others do for self-improvement?

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring two posts per day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.

With all the patent talk about Lodsys, I thought I would share my iOS patent infringement story.

I am one of three developers who created Baby Activity Logger.  We released it back in 2008.  About or year or so after that we received a letter from Apple that they had been contacted by the holder of patent #5691932 for a “Care giver data collection and reminder system” and that we were infringing on their patent.  If we did not contact the patent holder our app would be removed.  Every other baby tracking application also received the same letter from Apple.  Some of those apps actually ended up getting removed by Apple.

We contacted the patent holder who initially wanted a $5000 per quarter licensing fee in addition to 15% of sales.  After we explained to them we were three hobby guys doing this in our spare time and the app didn’t even make enough to cover the licensing fee they agreed on a flat 6% of revenue.  We thought we could win a challenge to the patent, but we didn’t have the money to hire a patent attorney, it just wasn’t worth it.

That went on for a few months and then we received a letter from the original patent holder who informed us the patent had been transferred and the new patent holder would contact us shortly with contact information and details.  This was back in 2010.

Today we received another letter from the new patent holder that we owe royalties back through 2010.

So here are my questions:

1.  Does this patent for a hardware device really even apply to software?

2.  Are there any options for a little guy to fight this without going broke in the process?

3.  Why would Apple remove an app instead of standing up for their developers, especially in cases were it is not clear that there is in fact patent infringement?

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring two posts per day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.