Just last night, I submitted a new version of my BasketBall Stats iPhone App to fix a bug. Not a particularly big bug, but one of those that causes the app to not feel very polished. So, what was this bug? Well, turns out, I had fouls and stats mixed up in a few places. Not a big deal, I know, but I did get a few complaints, so I thought rather than ignore my users, I'd take care of the issue.
So, we'll see how long it takes Apple to approve this version. Hopefully not too long ;)
Friday, January 15, 2010
Thursday, January 7, 2010
BracketMan ready for sale!
As I'm sure you know, I have a few iPhone Apps on the App Store. Last week, I released new versions of a few of those apps, and to my surprise, Apple found a bug in two of them (doesn't surprise me that it was two, as they are largely the same code base). The bug was kind of obscure, and gave me a good case to go look for a crash I'd seen in the field. In fact, this bug was the reason I posted about debugging with crash logs a couple days ago. Well, the bug was easy to fix, but I knew I would go on the back of the queue after resubmitting a binary, which I figured meant another 2 week delay in getting the apps out the door. To my Surprise, yesterday, I got an email from Apple saying Bracket Man and Bracket Man Pro was ready for sale! This is exciting news, as just a month ago, it took over 3 weeks to get an iPhone App approved and up for sale on the App Store. I had reason to believe things would get worse after Christmas, as Apple announced they would shut down iTunes Connect for several days (meaning nobody could submit apps) during that time. Apparently, they used that time to catch up, because the times have become much shorter since the new year.
The big new and exciting feature in these two apps right now are shake to shuffle in both apps, and admob ads to support the Bracket Man.
The big new and exciting feature in these two apps right now are shake to shuffle in both apps, and admob ads to support the Bracket Man.
Tuesday, January 5, 2010
Debugging from crash files
I know this is something no developer ever wants to do, but sometimes it's necessary. You've deployed your iPhone app, and through no fault of your own (we don't code bugs, right? ;) ) some user finds a way to break your app. I mean, who really thought they'd actually click THAT button you put in the middle of the screen and says "CLICK ME!!!!"?
Ok, blame aside, you now have a crash report you need to do something with. Looking at the file, all you see is memory addresses, which, last time I checked, not a lot of developers could take that, and tell you what happened and where it happened. So, what do you do?
Well, fortunately, Apple has given iPhone developers tools to use to map those memory addresses to actual methods and line numbers. The good news is, those tools work really well. the bad news, you need a little more information. The key here lies really in 3 files, that all have to match builds. The first is obvious: the .crash file. The other two, you generated your self, the .app file and a file in the same directory as the .app file, the .dSYM file.
The short version is, the app file is a stripped binary file, meaning all the debugging information has been removed. In iPhone apps, this information lives in the .dSYM file.
To use the .crash file, here's what you're likely going to need to do:
1) Open the .crash file in either console or your favorite text editor (even XCode if you so desire)
2) look for something like "Crashed Thread:" which will tell you which thread caused the problem.
3) in the trace for that thread, which will start with something like "Thread 0 Crashed:" you'll see a bunch of libraries and memory addresses. Look for something from your app. You may see things like libobjc.A.dylib or libstdc++..., Foundation, CoreFoundation, UIKit... In that same area, you'll see something with your apps name.
4) Take, probably the highest, row in the list with your app name, and copy the address, which will start 0x... like 0x00004d42 for example. You'll need this later.
5) In a terminal window, navigate to the directory in which the .app and .dSYM file live. I copy these off to a directory I use for deployed apps, in my case, /Users//Development/distToAppStore//
6) Start gdb with your app. If your apps name is HelloWorld.app, you'd start gdb (from the directory in your terminal like: "gdb HelloWorld.app"
7) now, you have gdb running, type "info line *0x00004d42" where the address is the address you pasted earlier. You'll see something that resembles the line, file and method that crashed, such as
Line 213 of "" starts at address 0x42ca <-[ ]+390> and ends at 0x42d0 <-[ ]+396>
Now you have a great starting point to to find out what happened and fix your app, making your iPhone apps more stable!
Enjoy!
Ok, blame aside, you now have a crash report you need to do something with. Looking at the file, all you see is memory addresses, which, last time I checked, not a lot of developers could take that, and tell you what happened and where it happened. So, what do you do?
Well, fortunately, Apple has given iPhone developers tools to use to map those memory addresses to actual methods and line numbers. The good news is, those tools work really well. the bad news, you need a little more information. The key here lies really in 3 files, that all have to match builds. The first is obvious: the .crash file. The other two, you generated your self, the .app file and a file in the same directory as the .app file, the .dSYM file.
The short version is, the app file is a stripped binary file, meaning all the debugging information has been removed. In iPhone apps, this information lives in the .dSYM file.
To use the .crash file, here's what you're likely going to need to do:
1) Open the .crash file in either console or your favorite text editor (even XCode if you so desire)
2) look for something like "Crashed Thread:" which will tell you which thread caused the problem.
3) in the trace for that thread, which will start with something like "Thread 0 Crashed:" you'll see a bunch of libraries and memory addresses. Look for something from your app. You may see things like libobjc.A.dylib or libstdc++..., Foundation, CoreFoundation, UIKit... In that same area, you'll see something with your apps name.
4) Take, probably the highest, row in the list with your app name, and copy the address, which will start 0x... like 0x00004d42 for example. You'll need this later.
5) In a terminal window, navigate to the directory in which the .app and .dSYM file live. I copy these off to a directory I use for deployed apps, in my case, /Users/
6) Start gdb with your app. If your apps name is HelloWorld.app, you'd start gdb (from the
7) now, you have gdb running, type "info line *0x00004d42" where the address is the address you pasted earlier. You'll see something that resembles the line, file and method that crashed, such as
Line 213 of "
Now you have a great starting point to to find out what happened and fix your app, making your iPhone apps more stable!
Enjoy!
Sunday, January 3, 2010
Updated website, finally
It's been needed for a while now, but I finally got around to updating my website. Funny thing about websites, they don't seem to take the priority they deserve, since we're usually about doing things to make money. However, what we often fail to remember, is we use the web to drive sales. In my case, I use sites to drive people to buy my iPhone apps. I've had little success with this, but that's probably because my sites were, well, horrible ;)
So, after lots of time researching tools, I picked one that I think will do the job quite well, one called RapidWeaver, which I bought from Apple.com, and saved $30 over realmacsoftware.com. The new sites look great, and now have a uniform look and feel throughout the entire site.
So, here's the sites and products they promote:
The first iPhone App is for the iPhone Bracket Manager, a tool I created almost by accident. The funny thing is, I never intended it to have more than about 10 downloads, so I used it to learn Objective-C; basically just hacked together an app, and put it on the store for free. I built it because one of the guys I bowl with was doing brackets by hand, and using playing cards to create pairings for those brackets. As you can imagine, using 8 playing cards (A - 8) to determine a random shuffling of numbers 1 - 8 can be complicated, and as a result, we often had the same people bowling against each other in different brackets. So, I started out to build just a number randomization to do the shuffle, and ended up making a bracket manager. I had over 300 downloads the first week, and about 600 the first month. To date, I've had about 4000 downloads of that first app.
Seeing a potential market, I decided to try to capitalize on the success of the Bracket Manager, but the code wasn't written in a way I could easily extend it. So, I did what any masochistic developer would do. I rewrote it. Completely. Well, not quite completely, but close. I did keep about 15 lines of code. I rewrote it so I could extend it to do other things. The design probably isn't the best yet, but it's good enough, and in development, sometimes good enough is in fact, good enough. The result was a completely redesigned bracket man, and a "Pro" version, the iPhone Bracket Manager Pro. This version took everything I learned while rewriting bracket man, and put it to good use. This time, instead of just a simple single elimination bracket, I also support a double elimination bracket, which was one of the big complaints I've seen in this type of software on phones, lack of double elimination brackets. I figured, as a new iPhone developer, but very experienced developer, it shouldn't be too hard. It wasn't, but the learning curve on more Objective-C did extend my time line a little more than I wanted. The first app took about 6 weeks to get out from scratch. The redesign and pro version, took all of about a month to do both of them, and get them out the door.
The next one, I decided to take on the exciting world of Basketball statistics with the iPhone Basketball Stats Manager. This one, as I've written about before, was a lot bigger than I anticipated, and after a few months of hard work, I finally got it out the door. Sales haven't been stellar by any stretch of the imagination, but they've been OK, about 60 copies in the first month. Not what I'd say is write home about good, but better than I'd expected. I have a couple of updates to get out on this one, one of which is ready and should be submitted to the app store this week. The other will be ready in a few weeks. This should keep it on the "Just Released" section of the app store just a little longer and hopefully increase sales.
That brings us up to date on what's happening in my world, I'll have more posts coming in the next few days with more exciting news from my iPhone development world!
So, after lots of time researching tools, I picked one that I think will do the job quite well, one called RapidWeaver, which I bought from Apple.com, and saved $30 over realmacsoftware.com. The new sites look great, and now have a uniform look and feel throughout the entire site.
So, here's the sites and products they promote:
The first iPhone App is for the iPhone Bracket Manager, a tool I created almost by accident. The funny thing is, I never intended it to have more than about 10 downloads, so I used it to learn Objective-C; basically just hacked together an app, and put it on the store for free. I built it because one of the guys I bowl with was doing brackets by hand, and using playing cards to create pairings for those brackets. As you can imagine, using 8 playing cards (A - 8) to determine a random shuffling of numbers 1 - 8 can be complicated, and as a result, we often had the same people bowling against each other in different brackets. So, I started out to build just a number randomization to do the shuffle, and ended up making a bracket manager. I had over 300 downloads the first week, and about 600 the first month. To date, I've had about 4000 downloads of that first app.
Seeing a potential market, I decided to try to capitalize on the success of the Bracket Manager, but the code wasn't written in a way I could easily extend it. So, I did what any masochistic developer would do. I rewrote it. Completely. Well, not quite completely, but close. I did keep about 15 lines of code. I rewrote it so I could extend it to do other things. The design probably isn't the best yet, but it's good enough, and in development, sometimes good enough is in fact, good enough. The result was a completely redesigned bracket man, and a "Pro" version, the iPhone Bracket Manager Pro. This version took everything I learned while rewriting bracket man, and put it to good use. This time, instead of just a simple single elimination bracket, I also support a double elimination bracket, which was one of the big complaints I've seen in this type of software on phones, lack of double elimination brackets. I figured, as a new iPhone developer, but very experienced developer, it shouldn't be too hard. It wasn't, but the learning curve on more Objective-C did extend my time line a little more than I wanted. The first app took about 6 weeks to get out from scratch. The redesign and pro version, took all of about a month to do both of them, and get them out the door.
The next one, I decided to take on the exciting world of Basketball statistics with the iPhone Basketball Stats Manager. This one, as I've written about before, was a lot bigger than I anticipated, and after a few months of hard work, I finally got it out the door. Sales haven't been stellar by any stretch of the imagination, but they've been OK, about 60 copies in the first month. Not what I'd say is write home about good, but better than I'd expected. I have a couple of updates to get out on this one, one of which is ready and should be submitted to the app store this week. The other will be ready in a few weeks. This should keep it on the "Just Released" section of the app store just a little longer and hopefully increase sales.
That brings us up to date on what's happening in my world, I'll have more posts coming in the next few days with more exciting news from my iPhone development world!
Saturday, January 2, 2010
iPhone Apps Sold Well Last Month
Ok, I don't have official results from Apple yet, but last month my iPhone Apps did pretty well. I sold over 50 of the Bracket Manager, and about the same for Basketball Stats. I know, I didn't exactly get rich, but hey, it took me 3 months to make about $90, and last month alone was over $130, which puts me over the top for a check from Apple!
Now, I'm thinking of doing some rebranding of the Bracket Manager to see if I can get it into some niche markets. I've also added ads to the free version. So, here's the plan:
Have a great new year!
Now, I'm thinking of doing some rebranding of the Bracket Manager to see if I can get it into some niche markets. I've also added ads to the free version. So, here's the plan:
- Ad supported free version Bracket Man
- Non ad supported paid version of the Bracket Man (not yet created)
- Non ad supported version of the Bracket Man Pro
Have a great new year!
Subscribe to:
Posts (Atom)
