Week 3 – App #1 Revamp (Nearly) Complete
As I mentioned the first week, Pinball Mini 2.0 was to be the first app to get polished up for my indie adventure. My plan was to take about two weeks to do this. If sales didn't improve (see week two's post for current sales numbers), I didn't waste a ton of time on it, but if they did improve, it was well worth the effort. I'm happy to report that the 2.0 update is nearly ready to be submitted to Apple for review...but it was quite a long week to get to this point.
Adding In-App Purchase to Pinball Mini
I ended up spending about 2 days and around 1000 lines of code adding a store to Pinball Mini. Chris and I talked about it and initially we had decided we'd release a board or two every couple of weeks (with the new board being free). Shortly after that though, Apple changed the policy where app updates didn't let the app show in the "new" lists anymore...so that kinda defeated the point of making frequent binary updates. Due to this (and due to the, lets just say, underwhelming sales at launch), we put Pinball Mini on hold. The thing is, Chris loves drawing (and he's excellent at it...just look at the game and you'll see). Plus, I've been wanting to try out in-app purchase for a while now, so it seemed like the right time to give it a go.
Urban Airship
My first inclination was to go with Urban Airship. They had the whole in-app purchase backend ready to go and had a reference client, so I thought it would be pretty pain free. It turns out - I was right...until we loaded up the sample storefront and started trying to *use* the backend. At first, things seemed fine. I could upload a binary to the website, it would show up in the store. Then I noticed, it apparently wouldn't take my description text nor the picture to show in the store. I tried uploading a few different times and I never got an error, but it never saved anything I typed. I decided I'd come back to that after I had the code integrated with PM. Well, the integration was about as simple as can be. You just implement a few delegate methods, include the library in your project, and call a few functions and you're good to go. The problem is the client UI. It's pretty bad. Yeah, it looks like a basic storefront, but the way it transitions and loads items just looks unfinished. The updates tab never seemed to work...I tried uploading a handful of versions to the website and it recorded the version number correctly, but I never saw the updates show in the correct tab. The good thing about the client is that it's open source - so you can change whatever you'd like and the backend service has an API that can be used without the iPhone client. Chris whipped up a quick version of the storefront UI just to compare with the UA client. After seeing it, there was no way I could like the UA client in...it was custom in-app purchase all the way.
Going 100% Custom IAP
I looked over the docs for StoreKit and read up on Noel's IAP series - nothing looked all that bad. Boy, I didn't realize what a mess of code I was going to need to handle those handful of StoreKit delegate methods. Sure - you only really need to implement a couple of StoreKit methods to get IAP up and running. The trick though, is just as Noel pointed out in his series...*everything* happens asynchronously. It may not sound like a big deal, but it is...even if you force the user to make one purchase at a time, you still have the possibility that they will restore old transactions, in which case they all flood in at once. Anyway, the actual UI code for the storefront is maybe a couple of hundred lines long, if that. But the code that provides data to that UI and that manages the IAP process is nearly 1000. I had no idea it would take that much code for something so seemingly simple. I did add the ability for the store to "update" products - so if we wanted to tweak an existing product based on feedback, we can do that now. We can also "sell" free products in the store - something Apple doesn't support at all. In the end, I'm really happy with the decision to build a custom store...I learned a ton and got into some parts of the SDK I've been wanting to play with. I may end up making a blog post about how the Pinball Mini store is designed, but for now, I'll have to leave it at that.
This Week
Chris is still working on finishing the first in-app purchase board pack. We have one level ready, but we're shooting for 4 boards per pack. After the last three boards are ready to go, we'll pack those up and get them all tested. Once everything is ready to go, we'll ship everything off to Apple for review. All of this will take maybe another 5-8 hours this week. For the remainder of the week, I'm going to finish up some tax work (I need to file the annual report for the LLC...Tennessee requires it even for single member LLCs), pay a couple of taxes, and work on the marketing for Pinball Mini 2.0. I've read quite a few blog posts about people having bad (or at least not good) luck with online ads for indie games. I still want to give Facebook a quick go as well as a little AdWords (I have a coupon from Google, so might as well use a bit of that). I'm also going to submit Pinball Mini to some review sites...I'm not sure how that will go since it's more of a casual/chill out kind of game, but it seems like it's worth a short. Once I have all of that stuff out of the way, I'm going to start planning for the next product/revamp. I'm still thinking Budgee 2.0 (specifically for iPad, but also for iPhone/iPod touch) is where I should focus next. We'll see though - there are quite a few ideas queued up...I just haven't decided which one will help get this indie journey started the best.




