I'd like to start this post with a simple seasons greetings. While I realize many around the world don't celebrate Christmas, I do, so Merry Christmas! For those of other faiths with holidays around this time of the year, I hope your holiday season was full of peace and joy.
Ok, now that that's been taken care of, I have some iPhone app news. As you know, I've been trying to sell copies of a couple of iphone apps on the Apple App Store, one of which, Basketball Stats, I've been trying to actively market myself through the web. One of my methods, was to use a service called Link Share which is how Apple setup their affiliate program for iTunes. Basically, you get an additional 5% on every sale you generate, meaning you can bring your profits from 70% to 75% on sales you bring in. I have some good news! I just noticed I got my first two sales, both on 12/14! I'm not saying that this is the best sales anyone has ever done, but, for a beginner in the internet marketing realm, it's a start.
Saturday, December 26, 2009
Monday, December 21, 2009
Another way to monetize iPhone Apps?
It's been a few days since my last post, but that doesn't mean I've been sitting around doing nothing. Instead, while trying to get ready for Christmas, I decided to take a brake a couple of days ago and start looking for other ways to monetize my iphone apps. Well, I found one that looks promising. It's called admob and basically, it's pay per click ads for the iphone. It was a breeze to setup, and now I'm just finishing some testing on my free app before putting it on the app store. One thing to note, I have to get it finished TONIGHT, because Apple is shutting down iTunes Connect from the 23rd through the 28th, so no chance to update during that time. Hopefully, they will be using that time to clear out some back log of apps pending approval, but I doubt it. Instead, I'm sure some lucky group of apps will sit there on the what's new lists for 5 or 6 days with lots of free exposure. Let's hope for the best, and have a Merry Christmas!
Thursday, December 17, 2009
The new app, the first week
It's been about a week since my latest app, Basketball Stats, went live on the App Store. I thought I'd do a quick entry just to recap how it did the first week, and how it's done this week so far. Basically, I would say it's done better than I had expected, but not as well as I had hoped. I took quite a bit of time and put some time into marketing this one. I wrote articles, pointed them back to the web site, of course, blogged about the iphone app, made sure I had good keywords on my page, wrote a press release, and even a classified ad. All these measures did in fact get me noticed by the search engines, but I have yet to make any sales through the basketball stats iPhone App web site. How do I know this? Apple has an affiliate program, where if you sign up, you get 5% of every sale through your site, and as of now, I've had none. Of course, Basketball Stats has sold about 40 copies as of now, which, given it's been out for a week, I'm calling that a small win for a small developer building iPhone apps and putting them on the app store. Hopefully it continues selling at this rate, and I make some money with it while I start building then next iPhone app ;)
Saturday, December 12, 2009
The new app is finally on the store
So the basketball stats app is now on the App Store. I took some extra time on this one trying to setup the website and sales copy. Better than my previous efforts, I think. Previously, I just threw together a bunch of text on a page, and didn't really do anything to format them.
However, this time, I thought about what I wanted to say in my sales copy, had my wife review it, revised it, and finally submitted it to apple. The process took a couple of extra days, but I think it was worth it. Despite a provider spamming the sports section, (400 VERY similar apps on the same day my app was approved, and another 100+ the next day) I've had some sales already. in about 2 days, I've had 16 sales, or more success than I had with BracketMan Pro in the first week.
However, this time, I thought about what I wanted to say in my sales copy, had my wife review it, revised it, and finally submitted it to apple. The process took a couple of extra days, but I think it was worth it. Despite a provider spamming the sports section, (400 VERY similar apps on the same day my app was approved, and another 100+ the next day) I've had some sales already. in about 2 days, I've had 16 sales, or more success than I had with BracketMan Pro in the first week.
Friday, November 27, 2009
Status on the new app...
So it's been a couple of weeks since my last post, I thought I'd bring you up to speed on the latest iphone app's status. I submitted it to the app store almost 2 weeks ago, and it's STILL in review. Apple has changed the status from waiting for review to in review, but as of now, it is still in review (6 days now) and has not been approved for sale in the app store.
I'll post again when the app goes live.
I'll post again when the app goes live.
Saturday, November 14, 2009
The app is ready, now, the website....
Ok, as you know, I'm building yet another "top secret" application for the iPhone to be deployed in the Apple App Store. Of course, this won't be top secret for much longer. I hope to get it submitted to the app store this weekend. I've decided to take a much more interactive marketing strategy this time, one I didn't take with the bracket manager. First, I've actually thought about the sales copy and website design before submission. The web design isn't the best, but certainly isn't the worst either. I'm using some CSS to format it better, and putting pictures throughout the site rather than all in a row like my first apps pages. I will be going back and retrofitting the other sites as well, but that can wait a few weeks until I get new releases ready for the app store. I'll post again when the current app has been submitted to the iPhone App Store. Hopefully that will be sometime this weekend!
Monday, November 9, 2009
The next app is close
I'm getting really close to submitting my next iPhone app to the App Store. How close? Well, let's just say I'm now working on documentation and a website more than the app itself. I did a quick look through the store, and only found two apps doing something close to what I'm doing. One is $.99 and does very little compared to mine, and the other is quite expensive and does about what mine does, but with a prettier interface. I figure marketing at a reasonable price should make mine sell quite well.
So, given it's so close to going out, I figure now is the time to really go over some lessons learned in this app, some technical, others more project management.
First, technical lessons learned.
It's Really Bad to Return alloc'd Objects
This sounds like a no brainer, but, if you need to return an object, make sure you didn't alloc the memory for it yourself. These objects are easy to leak, and if you try to clean them up yourself, you can end up releasing objects not retained anywhere, resulting in a crash.
Instead, if you return objects (Like a list for example) instead of using "alloc" to create it, use other options. Instead of:
use this:
The resulting object is safe to pass from method to method, and you don't have to worry about cleaning them up.
The Analyze tool is your friend
The build menu has a "build and analyze" option. At first, I thought this was nice, although not very handy. I was wrong. This is probably the most useful tool in XCode's build menu. Using this, before fixing my methods, I saw 30 or 40 potential issues. I ignored them, because upon looking at them, I was releasing the objects later in the code (again, BAD idea). Using this feature, I fixed all those pesky memory leaks in one swoop, in about 30 minutes, instead of hours it would have taken to run leaks to find the leaks in the first place.
Instance variables need to be referenced with "self"
This is another one of those "duh" moments. In Java, you have the "this" keyword, which references an instance variable. It's not required in Java, but can make your code easier to read, especially in areas where you're assigning an instance variable from a local variable, or visa versa, like in this method:
It's far clearer to use this instead:
and later try to use that array like:
you'll crash, or at least I did.
instead, both those examples should use the self keyword, like...
or
Now, the Project Management lessons learned:
Watch Out for Creep
No, I don't mean that crazy guy down the street who...
I mean scope creep. We all know what scope creep is, but in small projects, in a platform so easy to code in, it's really easy to expand beyond what you were thinking. My original thought was a small app, perhaps two or three views, and within a couple of days, that had exploded to five or six screens and a lot more functionality. Today, as I get ready to release, it's over 15 views, and does a lot more than I wanted originally. Will it make it sell better? Probably. Was it worth the extra time? Don't know, but I'd guess probably not. The only way to know that for sure, would be to go back and build my original idea, and put it out at the same time. But, given that my original time frame was three weeks to get it onto the store, and it's been about six weeks already, with probably another two before going live, I overspent on my time. Had I thought about what I wanted to do a little more, this might have not happened. I may have planned to make this much larger from the start, and I could have budgeted more time (since this is a side project, money is only opportunity lost rather than real dollars).
Find Help if You Need it
As I just stated, this app turned out to be much larger than expected. A little planning on my part, and I might have found some friends to help me bang out some code early on, making this happen quicker. The downside to that, is I would have had to either pay them, or share my profits. Of course, if the first app is any indication, there probably won't be a lot of profit in this one, but my luck, I'd give someone 1/2 my profits on a real winner of an app.
This was really just some of my findings and lessons learned in this project. I'll post about this app again once I get it into the approval process in a couple of days, and again when it goes live. I'll say what it is at that point (I don't want to give anyone a chance at catching up to me ;) )
So, given it's so close to going out, I figure now is the time to really go over some lessons learned in this app, some technical, others more project management.
First, technical lessons learned.
It's Really Bad to Return alloc'd Objects
This sounds like a no brainer, but, if you need to return an object, make sure you didn't alloc the memory for it yourself. These objects are easy to leak, and if you try to clean them up yourself, you can end up releasing objects not retained anywhere, resulting in a crash.
Instead, if you return objects (Like a list for example) instead of using "alloc" to create it, use other options. Instead of:
NSArray *array = [[NSArray alloc] init...]; //bad idea
use this:
NSArray *array = [[NSArray array] init...]; //bad idea
The resulting object is safe to pass from method to method, and you don't have to worry about cleaning them up.
The Analyze tool is your friend
The build menu has a "build and analyze" option. At first, I thought this was nice, although not very handy. I was wrong. This is probably the most useful tool in XCode's build menu. Using this, before fixing my methods, I saw 30 or 40 potential issues. I ignored them, because upon looking at them, I was releasing the objects later in the code (again, BAD idea). Using this feature, I fixed all those pesky memory leaks in one swoop, in about 30 minutes, instead of hours it would have taken to run leaks to find the leaks in the first place.
Instance variables need to be referenced with "self"
This is another one of those "duh" moments. In Java, you have the "this" keyword, which references an instance variable. It's not required in Java, but can make your code easier to read, especially in areas where you're assigning an instance variable from a local variable, or visa versa, like in this method:
String str; //instance variable
public void setStr(String str){
str = str; // which "str" are you setting?
}
It's far clearer to use this instead:
String str; //instance variable
public void setStr(String str){
this.str = str;
}
@synthesize array;
array = [[NSArray alloc]... //retain count not incremented.
and later try to use that array like:
[array objectAtIndex:...];
you'll crash, or at least I did.
instead, both those examples should use the self keyword, like...
@synthesize array;
self.array = [[NSArray alloc]...];
...
[self.array objectAtIndex:...];
or
@synthesize array;
[self setArray:[[NSArray alloc]...]];
...
[[self array] objectAtIndex:...];
Now, the Project Management lessons learned:
Watch Out for Creep
No, I don't mean that crazy guy down the street who...
I mean scope creep. We all know what scope creep is, but in small projects, in a platform so easy to code in, it's really easy to expand beyond what you were thinking. My original thought was a small app, perhaps two or three views, and within a couple of days, that had exploded to five or six screens and a lot more functionality. Today, as I get ready to release, it's over 15 views, and does a lot more than I wanted originally. Will it make it sell better? Probably. Was it worth the extra time? Don't know, but I'd guess probably not. The only way to know that for sure, would be to go back and build my original idea, and put it out at the same time. But, given that my original time frame was three weeks to get it onto the store, and it's been about six weeks already, with probably another two before going live, I overspent on my time. Had I thought about what I wanted to do a little more, this might have not happened. I may have planned to make this much larger from the start, and I could have budgeted more time (since this is a side project, money is only opportunity lost rather than real dollars).
Find Help if You Need it
As I just stated, this app turned out to be much larger than expected. A little planning on my part, and I might have found some friends to help me bang out some code early on, making this happen quicker. The downside to that, is I would have had to either pay them, or share my profits. Of course, if the first app is any indication, there probably won't be a lot of profit in this one, but my luck, I'd give someone 1/2 my profits on a real winner of an app.
This was really just some of my findings and lessons learned in this project. I'll post about this app again once I get it into the approval process in a couple of days, and again when it goes live. I'll say what it is at that point (I don't want to give anyone a chance at catching up to me ;) )
Saturday, November 7, 2009
A quick thought on memory management
So, the iPhone, with as great of a platform as it is for developers, isn't without its flaws. As I've mentioned before, my "day" job, is software development, with about 99.99999% of that, in Java. I won't go into why Java is better than Objective-C, because quite honestly, I think both are exceptional object oriented languages. One thing Java has, however, that Objective-C (well, on the iPhone anyways) does not, is garbage collection. For those who aren't programmers, garbage collection is a memory management system, where objects that are no longer used automatically release the memory they're holding onto. While garbage collection doesn't guarantee you will never have a memory leak, it certainly goes a long way into ensuring you don't have them. Apple, in their infinite wisdom, decided on the iPhone to not have garbage collection. The reasons for this were sited as it takes too much processing, it slows things down and is heavy. All of which, I firmly believe to be correct.
Because of this, I suspect many apps on the app store have not been properly profiled, or written by their developers, perhaps causing some unnecessary headaches for users.
Here are just some quick ways developers can prevent leaks in their code.
1) Any time you create a new object (retain, copy, or alloc), release it. Best practice is to release it in the same method that created it, otherwise you risk releasing an object that is no longer referenced (VERY bad idea)
2) Make sure your dealloc method contains a release for every property in the header file.
3) Use Build => Build and Analyze to determine if you have any potential memory leaks as you code. If it finds any issues, they're probably legitimate issues that should be addressed.
Because of this, I suspect many apps on the app store have not been properly profiled, or written by their developers, perhaps causing some unnecessary headaches for users.
Here are just some quick ways developers can prevent leaks in their code.
1) Any time you create a new object (retain, copy, or alloc), release it. Best practice is to release it in the same method that created it, otherwise you risk releasing an object that is no longer referenced (VERY bad idea)
2) Make sure your dealloc method contains a release for every property in the header file.
3) Use Build => Build and Analyze to determine if you have any potential memory leaks as you code. If it finds any issues, they're probably legitimate issues that should be addressed.
Monday, October 26, 2009
Interesting thing about iPhone apps
Today, I started looking at some of my older download reports from Apple. The number of people who have downloaded my free Bracket Man from the app store is amazing. Just a quick estimate would put the number at somewhere around 2,000 or so, since July, with NO advertising at all. However, that success hasn't translated into sales of Bracket Man Pro. I'm not sure exactly why this is yet, but I've started looking into this more. Looking at my server logs, I'm getting hits on my website for the pro version, looks like about 5 a day or so. However, This doesn't seem to be translating into sales. I'm also ranked top 5 on Google when searching for an iPhone Bracket Manager. So, now, the problem can't be Search Engine Optimization, since I'm ranked so highly (well, I suppose it could be, based on keywords used), but I suspect it's more on the look and feel of that website. So, over the next few days, I'm going to start looking at ways to tweak the website, perhaps adding a blog to it, and news to keep potential buyers up to date with what's keeping me busy on the bracket manager. I also intend to use this blog, and perhaps one on my iPhone homepage to announce new iPhone products as they go out. Hopefully those two steps will also help increase sales.
On the new apps front, I didn't work on the new "black ops" app too much today. I just had too many other things going on, but tomorrow looks promising that I'll be able to get some stuff done on it. It looks like there's only another week or so left of development on it, but if the bracket managers proved anything with Objective-C and iPhone Apps, at least in my world, that is probably pretty optimistic. I think I still have another 3 or 4 views to write, as well as wire in all the database stuff (Database CRUD code has been completed, but the views don't all write to, or read from the database, yet).
On the new apps front, I didn't work on the new "black ops" app too much today. I just had too many other things going on, but tomorrow looks promising that I'll be able to get some stuff done on it. It looks like there's only another week or so left of development on it, but if the bracket managers proved anything with Objective-C and iPhone Apps, at least in my world, that is probably pretty optimistic. I think I still have another 3 or 4 views to write, as well as wire in all the database stuff (Database CRUD code has been completed, but the views don't all write to, or read from the database, yet).
Saturday, October 24, 2009
The next iphone app
I'm several weeks into my second iPhone app, one I'm not yet ready to share with the world. I will, however, say this about it. Currently, I don't see any competition for it in the iPhone App Store. That either tells me that there's no demand for it, OR, and I personally like to think this is the case, nobody's seen this niche yet, and it's been completely ignored ;)
However, this post isn't just about me telling you I'm working on a new app that I can't tell you about yet, but more importantly, it's me describing something I consider to be important when building any app, not just iPhone Apps, scope creep, feature creep and lack of accurate sizing.
Any developer can tell you what any of these can do to a project. As you start building, you start seeing all the "cool things" or things you didn't think about when you started that would make a product better. So, you start adding the new features, and pretty soon, your 2 or 3 week (or month) project takes 3 times as long to complete, and in that time frame, you've not built anything you can sell. I'm not an advocate of releasing broken software, and in fact, on the App Store, you can't release broken software, or at least there's a good chance it will get rejected by Apple before it gets to the store. What I am suggesting, is think out your projects before starting. If you have to, draw out all your screens, on something like notepods for an iPhone, or just simple wire frame drawings for other apps (web, mobile device and desktop). This will help you not only set some direction for your project, but also help you scope it out. Is it too big for one person to build in a reasonable length of time? Are you going to need help? Is it within your skill set and expertise? Can you build part of it, get it out and monetize it while continuing development?
All of these questions I think are relevant and crucial to answer before starting a new project.
Ok, now back to my current project, the one I can't tell you much about yet. I fell into this trap on this project. No, I haven't had any scope creep, or feature creep, although I do have a feature list of enhancements for future releases, thanks to a couple of friends who have seen the project. Where I think I failed on this one, is, thinking it was a smaller project than it really was. I figured this particular iPhone app was about 5 screens, all pretty simple, with 1 custom table cell view. Well, as I drew it out, and it made some sense, so I started coding. Unfortunately, I didn't do any kind of work flow management, how you go from screen one to screen "n". Therein lies the problem. Those 5 screens are currently about 10, with at least 4 more to go, with nearly all of those also having heavy development in table cells. If my full time job was iPhone development, I might say this still has 2 weeks of development left, but since it's not my full time job, this could be another 4 or 5 weeks. Looking back, I should have found someone to partner with on this app, and given them parts of it to build, which would have saved me a lot of time and headaches in the meantime.
Of course, now I'll have a framework for the next app like this, so I'm sure when I start the next one, I'll probably fall into the same trap again, given I have such a big base now, but time will tell. ;)
However, this post isn't just about me telling you I'm working on a new app that I can't tell you about yet, but more importantly, it's me describing something I consider to be important when building any app, not just iPhone Apps, scope creep, feature creep and lack of accurate sizing.
Any developer can tell you what any of these can do to a project. As you start building, you start seeing all the "cool things" or things you didn't think about when you started that would make a product better. So, you start adding the new features, and pretty soon, your 2 or 3 week (or month) project takes 3 times as long to complete, and in that time frame, you've not built anything you can sell. I'm not an advocate of releasing broken software, and in fact, on the App Store, you can't release broken software, or at least there's a good chance it will get rejected by Apple before it gets to the store. What I am suggesting, is think out your projects before starting. If you have to, draw out all your screens, on something like notepods for an iPhone, or just simple wire frame drawings for other apps (web, mobile device and desktop). This will help you not only set some direction for your project, but also help you scope it out. Is it too big for one person to build in a reasonable length of time? Are you going to need help? Is it within your skill set and expertise? Can you build part of it, get it out and monetize it while continuing development?
All of these questions I think are relevant and crucial to answer before starting a new project.
Ok, now back to my current project, the one I can't tell you much about yet. I fell into this trap on this project. No, I haven't had any scope creep, or feature creep, although I do have a feature list of enhancements for future releases, thanks to a couple of friends who have seen the project. Where I think I failed on this one, is, thinking it was a smaller project than it really was. I figured this particular iPhone app was about 5 screens, all pretty simple, with 1 custom table cell view. Well, as I drew it out, and it made some sense, so I started coding. Unfortunately, I didn't do any kind of work flow management, how you go from screen one to screen "n". Therein lies the problem. Those 5 screens are currently about 10, with at least 4 more to go, with nearly all of those also having heavy development in table cells. If my full time job was iPhone development, I might say this still has 2 weeks of development left, but since it's not my full time job, this could be another 4 or 5 weeks. Looking back, I should have found someone to partner with on this app, and given them parts of it to build, which would have saved me a lot of time and headaches in the meantime.
Of course, now I'll have a framework for the next app like this, so I'm sure when I start the next one, I'll probably fall into the same trap again, given I have such a big base now, but time will tell. ;)
Wednesday, October 21, 2009
Just when I thought they were never going to do it...
Apple finally released the new version of my Bracket Man "lite". Last night, I got the email from apple saying bracket man was now available on the app store. Of course, looking at the profile, I noticed the pictures are all messed up now, missing several pictures, so I'll have to update some of the apps pictures, but at least Apple did finally approve it for the App Store!
Tuesday, October 20, 2009
Still in review...
As you may remember from a previous post, Apple rejected my update to Bracket Man "lite" because it wasn't "Fully functional" as they put it, and it was upselling to Bracket Man Pro by not allowing double elimination brackets, and instead popping up a message telling the user to buy the pro version. Well, amazingly enough, that was close to two weeks ago, and I'm still waiting for the iPhone App Store approval on the new version. Hopefully it will get approved soon, and I'll be able to get this new version out soon, it fixed a lot of bugs.
Saturday, October 17, 2009
Lesson learned...
A few weeks ago, I released version 2 of Bracket Man, the free version of the bracket manger. I did this because after the huge success I had, over 1500 iPhone app downloads in the first 6 weeks, I realized I could do so much more with this iPhone app. So, when I embarked on creating a paid version of the iPhone App, Bracket Man Pro, I decided to make some changes to the free version as well, giving it a facelift to look like the pro version. Since the pro version has double elimination, I figured it best to make the free version single elimination only, but wanted to get exposure to pro by capitalizing on the success of the free version. To do this, I opted to have the same views, on both versions, with one difference. The free version, instead of creating a double elimination bracket, would simply give the user a message telling them double elimination brackets were only available in the Pro version. First time through the approval process, it went perfectly. No issues. Fast forward 2 weeks, when I tried to get version 2.1 out. Bracket Man Pro, the paid iPhone App, went through without a hitch. However, the "lite" version got rejected. Why? Because, it turns out, Apple doesn't like "upselling" in the products, and viewed that message as somehow breaking the app. So, to fix this, I quickly (within 8 hours) removed the bracket type switch from the lite version, and resubmitted it. That was well over 10 days ago, and I'm still waiting for approval. How long will it take? Your guess is as good as mine ;)
Friday, October 16, 2009
The Marketing Continues
Good Afternoon. Today, I thought I'd talk about a different topic regarding iPhone Apps, and the App Store. While Apple does a good job of helping you get your app out there, it's not the only way to market iPhone apps.
Here are some ways to get more exposure for your apps.
A web page is a great start, but if you look at my page, it kinda stinks. Why? After all, I'm a programmer, I should have the coolest site of all! Not quite. While I can build back ends, web pages are definitely not my strong point. It is optimized for Google, and in fact, using google to search for an iphone bracket manager, I'm 4th or 5th on the list.
Many review sites will index the app store, and publish results on their own pages. AppStoreHQ is an example of one of those sites. Only problem is, they don't always refresh when new versions are release. I'm not sure how often they refresh, but they do at some point.
Anyone have any great ideas how to market iphone apps? Anyone making money with their apps yet?
Here are some ways to get more exposure for your apps.
A web page is a great start, but if you look at my page, it kinda stinks. Why? After all, I'm a programmer, I should have the coolest site of all! Not quite. While I can build back ends, web pages are definitely not my strong point. It is optimized for Google, and in fact, using google to search for an iphone bracket manager, I'm 4th or 5th on the list.
Many review sites will index the app store, and publish results on their own pages. AppStoreHQ is an example of one of those sites. Only problem is, they don't always refresh when new versions are release. I'm not sure how often they refresh, but they do at some point.
Anyone have any great ideas how to market iphone apps? Anyone making money with their apps yet?
Thursday, October 15, 2009
Hello
Hello, and welcome to my iPhone App blog. As you probably already know, if you just stumbled onto this blog, the iPhone is a big thing. Tens of millions of units sold. The iPhone App Store has over 75,000 applications on it. You probably know most, if not all of the capabilities of this amazing phone if you're reading this.
So, why am I writing this blog? The short answer, is I'm an iPhone enthusiast. The more complete answer is, not only am I an enthusiast, but I'm also a developer. An iPhone App developer. Well, not just iPhone Apps, I also do Java, and Enterprise Java solutions, along with a little PHP here and there. Right now, Java pays the bills (Usually. Yes, there's story there too, I may get into it later, I may not, it's not really important, at least not yet.)
If Java pays the bill, you may be wondering why I'm building iPhone Apps. Quite simply, because I enjoy it. I find playing with new and exciting technologies fun. I'd never done mobile device work in the past, never worked with a Mac, and wanted to try both. I thought about Android and Blackberry development, but neither of those really excited me. They didn't seem to have the cult application following the iPhone has, nor did the user base seem to be as app hungry as the iPhone users. So, I got a book on Objective-C and iPhone development, bought a MacBook, and jumped in with both feet. I intend to document how my apps are doing on the store, as well as anything I learn about getting them into the app store, and marketing those apps.
Enough introduction already! Let's get on to the fun stuff. The first app I wrote, was a simple tournament bracket manager. I called it, creatively enough, "Bracket Man". Bracket Man was only really intended to allow the guy in my bowling league who managed brackets to shuffle his paper brackets without cards (works great for that). It must have worked great for others too, because in 2 months, with NO marketing, I had around 1500 downloads. You may be wondering why that's important. Well, because, like a fool, I gave it away. I thought I'd only have 4 or 5 downloads because I didn't market it at all. After seeing over 500 downloads the first week, I figured I better figure out how to monetize this iPhone App. So, out of this, "Bracket Man Pro" (I know, real creative again) was born. Of course, just having a snappy name isn't enough to do anything, so I thought I might need some more features. Where do you look for features on an app for the app store? Reviews. My own reviews weren't much help. In fact, they were raving reviews. People loved it. At least the 8 or 9 who decided to take the time to talk about it loved it. So, I had an app that from my own reviews, looked great. So I looked for other bracket manager apps on the app store. With all those tens of thousands of apps, you'd think there would be a hundred of them. Wrong. There was one more (now I think there's just two or three besides mine). So, I looked at THAT apps reviews. The big thing people seemed to want was Double Elimination brackets. I thought, great, there's no way I can do that with how I wrote Bracket Man, so I'm going to have to rewrite the whole thing.
About six weeks later, Bracket Man became "Bracket Man Lite" and Bracket Man Pro was born.
The interface was 100% reworked, as was the way data was stored, and even how the brackets were drawn. Without getting into boring details, I changed everything but about 10 lines of code. After re-releasing the app, I was curious as to how I would be received by the paying public. The bottom line, I was received OK, but not like I hoped. The new version was released mid September, so it's been out about a month. In that time, it's sold a few copies, but not like the free version did the first time. The free version, now "lite" has had a couple hundred downloads, but the paid version I think is only at around 60. I guess that's not too bad, but I think I can do better.
So, now, I have Bracket Man Lite and Bracket Man Pro, both on the App Store
So, why am I writing this blog? The short answer, is I'm an iPhone enthusiast. The more complete answer is, not only am I an enthusiast, but I'm also a developer. An iPhone App developer. Well, not just iPhone Apps, I also do Java, and Enterprise Java solutions, along with a little PHP here and there. Right now, Java pays the bills (Usually. Yes, there's story there too, I may get into it later, I may not, it's not really important, at least not yet.)
If Java pays the bill, you may be wondering why I'm building iPhone Apps. Quite simply, because I enjoy it. I find playing with new and exciting technologies fun. I'd never done mobile device work in the past, never worked with a Mac, and wanted to try both. I thought about Android and Blackberry development, but neither of those really excited me. They didn't seem to have the cult application following the iPhone has, nor did the user base seem to be as app hungry as the iPhone users. So, I got a book on Objective-C and iPhone development, bought a MacBook, and jumped in with both feet. I intend to document how my apps are doing on the store, as well as anything I learn about getting them into the app store, and marketing those apps.
Enough introduction already! Let's get on to the fun stuff. The first app I wrote, was a simple tournament bracket manager. I called it, creatively enough, "Bracket Man". Bracket Man was only really intended to allow the guy in my bowling league who managed brackets to shuffle his paper brackets without cards (works great for that). It must have worked great for others too, because in 2 months, with NO marketing, I had around 1500 downloads. You may be wondering why that's important. Well, because, like a fool, I gave it away. I thought I'd only have 4 or 5 downloads because I didn't market it at all. After seeing over 500 downloads the first week, I figured I better figure out how to monetize this iPhone App. So, out of this, "Bracket Man Pro" (I know, real creative again) was born. Of course, just having a snappy name isn't enough to do anything, so I thought I might need some more features. Where do you look for features on an app for the app store? Reviews. My own reviews weren't much help. In fact, they were raving reviews. People loved it. At least the 8 or 9 who decided to take the time to talk about it loved it. So, I had an app that from my own reviews, looked great. So I looked for other bracket manager apps on the app store. With all those tens of thousands of apps, you'd think there would be a hundred of them. Wrong. There was one more (now I think there's just two or three besides mine). So, I looked at THAT apps reviews. The big thing people seemed to want was Double Elimination brackets. I thought, great, there's no way I can do that with how I wrote Bracket Man, so I'm going to have to rewrite the whole thing.
About six weeks later, Bracket Man became "Bracket Man Lite" and Bracket Man Pro was born.
The interface was 100% reworked, as was the way data was stored, and even how the brackets were drawn. Without getting into boring details, I changed everything but about 10 lines of code. After re-releasing the app, I was curious as to how I would be received by the paying public. The bottom line, I was received OK, but not like I hoped. The new version was released mid September, so it's been out about a month. In that time, it's sold a few copies, but not like the free version did the first time. The free version, now "lite" has had a couple hundred downloads, but the paid version I think is only at around 60. I guess that's not too bad, but I think I can do better.
So, now, I have Bracket Man Lite and Bracket Man Pro, both on the App Store
Subscribe to:
Posts (Atom)
