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.
Subscribe to:
Comments (Atom)
