My first application has been in the App Store for about a week and a half.
I have a learned a lot and I want to share some of these lessons and maybe save some pain for the rest of you:
1 - Get frank feedback from someone - The reviewers in iTunes will be brutal and that feedback is forever. Get someone you trust to beta the app and tell you what you need to fix before it goes on sale. I already have updated my app to address some of the negative feedback, but it is still out there and people won't realize it is feedback from a previous version of the app.
2 - Set up your minimum OS to the lowest possible. I had friends who were going to buy, but their phones were set to OS 2.0. Once they realized they had to upgrade, they lost interest.
3 - The itunesconnect app is a nightmare. Be very careful. When you do an update it shows two rows in the app. So I assumed I could go ahead and update description,screenshots, and release date for my 1.1. Those changes were to my version 1. It was a nightmare and I lost a whole day of sales as a result.
4 - Work the release date. When you submit your app, put your release date as current date or a day or two in the future. But if you leave it there, then when it goes on sale it will not show on the first page because itunes will sort on that date. The first thing you do when apple approves the app is go back into itunesconnect and change the date to today's date. Then it will show up on the first page for its category. And don't put a future date because then your app won't show up at all. It is kind of comical that it is so messed up but I think everyone does it this way.
5 - Be as literal as possible when naming your app. The search feature is terrible. If you have a poker app and you get all clever and call it HoldEm, then a user searching for poker won't find it. Just call it poker.
6 - (May be controversial) - Don't spend too much time on your website and doing screenshots and demo videos. I have sold about a thousand copies of my app and have had less than 50 visitors to my site. I am sure in the long run it does matter, but don't delay getting your app in the store because of it.
7 - While we are on the subject, don't delay. I had an idea that I thought was an obvious winner, and was surprised noone had done it. In the weeks leading up to my release, two other apps came out.
8 - When you do an update, it shows as a $.00 sale when users upgrade. I freaked out when a bunch of $.00 sales showed up on my report. Given my struggles with itunesconnect, I thought I had accidently given away apps. But they were just transactions for the updates.
9 - A large percentage of users will apply the updates
10 - Another controversial one - I won't user Interface Builder. I built an initial test app with it and abandoned it because it seemed complicated and I fought with it. I have written two apps now without it and never regretted it. I have much more control and there is no voodoo to deal with.
11 - Maybe controversial - I am not sold on putting the initial release out for free. The way I look at it, you can have a free app and still get negative feedback. And that cuts into future sales. Make it good enough to be worth a little money day one. I say that it has an introductory low price. If feedback is good, I will raise the price. If not, leave it low. Also, it appears the sales in the first week are the best (maybe sustained longer with good feedback). If you give it away you may never get those sales back.
3 & 4 -- yup, itunesconnect stinks. Typical case of a company doing a bang up job on their public user oriented apps and just throwing something together for their developer audience.
5 -- I have found the search feature is actually pretty damn good. It searches descriptions and just about anythign in the metadata. It also seems to use popularity to help sort search results. My app is the #1 hit for "Scream" (it's called "The Scream") but it's also the #1 hit for "scare", and amongst the scare oriented apps, I think mine probably is the most popular.
6 -- I don't think the website is important at all. People shop for your app from the app store, not the web. Do you really think people go to each and every company website before purchasing? No way. For my game I plan to just put up a few screenshots, and a contact email, that's it.
7 -- I might be wrong about this but I don't think this applies to games. I think games are a totally different ballgame (no pun intended).
10 -- interface builder has a very steep learning curve. But it's worth it. So very worth it. You can cut your interface development time by orders of magnitude once you get used to it. It also translates to Mac apps should you ever decide to provide a conduit for your iphone app.
Yeah search definitely uses popularity as part of it. I used to be #1 for scream and scare. Now I don't even register for scare and am #2 for scream. My app has faded away into "page 48 obscurity" since I last tried it.
1) Absolutely. Too many stories of people finding bugs after submission and having to reject and redeploy. Test, test, and test again before submitting.
3) Yeah, it's picky but once you know how it works it's actually no big deal at all. I submit an update and leave everything as-is. When I get the "Ready for sale" email I log in and update everything. Simple.
4) No need for that first date change. Just set the date to "today" when it's "Ready for sale". I do this with all the other updates for #3.
5) My experience has been the opposite. I can search for just about any term in my app's description and the app shows up. I've tweaked my app's description to include important words and possible variations too.
6) I think this depends on the app. My "Palettes" app has a ton of screens so the 5 in the store just doesn't do it justice. I made mention to checkout my site for more info and screen shots and I do get hits. I've gotten emails that the extra screen shots sold the app.
8) Upgrades are of type 7. Regular sales are type 1.
10) IB sucks in my opinion. I hate magic frameworks when it comes to writing software. I used IB for two days in my first app and gave up. I much prefer to see what's going on and understanding what's going on. Much easier with code. I see so many people here struggle with IB. It's less work to just learn to write the code yourself. Then you know what's happening and know how to fix it.
I should add one other thing on the literal name thing - it is not just the searh.
When they are browsing a category, users are looking at a list of apps with no description and an icon and trying to decide which ones to click on. I think you want to make that name as literal as possible so they know what they are getting. Something may be clever but if the user doesn't get it they may not make that extra click to see what it is. Just my opinion.
I think IB is a love hate...either you love it or hate it. When I first started working on the Mac I didn't use it because it was confusing connecting things but now I use it for every app. If you understand it and how it works it can save you hours and hours of work. It's also so much easier for protoyping, I was able to bust out a full app prototype in IB in less than 20 minutes for a client yesterday..there is no way you could do that in code and make it look good.
Website: You might not get the traffic now and maybe you don't want to make it a promotional site but you MUST have a website for feedback. The feedback I've received over the past week is priceless, things I would have never thought of and some minor bugs I couldn't track down were reveleaved. I encourage everyong to setup at least a one page site with a feedback form.
__________________ Super Pig iOwn - Inventory anything and everything.
this one bit me a few days back so I'll contribute to the list:
if you have alternate localizations for your AppStore listing, be aware that the screenshots are also localized. When you first submit your app, it uses the initial screenshot submissions for all of your supported languages, but on updates, you need to manually upload new screenshots for EACH localization (if you change the screenshots, of course).
I had a situation where my app evolved tremendously and the entire look and feel had changed by version 1.3, but the poor French and German stores still were displaying all the old images of version 1.0 :-(
One other thing I'd add is the need for a well-designed, attractive, literal icon. Potential customers probably notice the icon before they notice the name of the app, and if you have a slick icon that grabs their attention, looks professional, and clearly communicates what the app is about then you have a better chance of making a sale. (I know I've made sales based on the icon for XyPhone.)
IB isn't a magic framework but what I meant is that the xib it creates and how your code/application make use of it is all hidden.
I like seeing code that does just what I want. Sure IB allows you to whip up screens quickly but I can do it almost as fast in code and I know exactly what is going on. But I'm also old school. I prefer a command line too.
The other issue I have with tools like IB is that it hinders the learning process. Since it does so much for you it is hard to figure out what's wrong when things aren't working. This is really true for newer developers. By doing it in code you are forced to learn how everything fits together.
Ideally people should learn how to do everything in code. Then use IB to make things easier and/or faster. The combination of the two is good. Just relying on IB (or any other similar tool in any other environment) limits the skills of the developer to some degree since they haven't learned the basics.
It's like math class in school. You learn how to add and subtract by hand before you are allowed to use a calculator.
It's like math class in school. You learn how to add and subtract by hand before you are allowed to use a calculator.
Not true. I'm taking Complex Variables math class as an undergrad, and we aren't allowed to use calculators on the exams. WTF ?? Some1 needs to tell the professor this quote.
My problem with IB was that it worked good until I had to do something more dynamic - like only show buttons in certain cases or change the screen based on logic. Then I ended up with a mish-mash of approaches that was more confusing than just coding by hand.
But I think for certain types of apps it would be worth the learning curve. A year from now I may be arguing the other way.
I've been trying to submit my first little app all morning and itunes connect hangs on the upload of the assets. Click the button, and nothing happens...sigh. Why does every single think I do with the SDK require multiple attempts, massive amounts of confusion, and 4 sets of documents?
At least the 2.2 sdk resolved my provisioning issues. my lord that was aggravating.
Thank god for this forum. Just having other developers moan about the same issue has helped me get through a lot of this.
IB isn't a magic framework but what I meant is that the xib it creates and how your code/application make use of it is all hidden.
I like seeing code that does just what I want. Sure IB allows you to whip up screens quickly but I can do it almost as fast in code and I know exactly what is going on. But I'm also old school. I prefer a command line too.
The other issue I have with tools like IB is that it hinders the learning process. Since it does so much for you it is hard to figure out what's wrong when things aren't working. This is really true for newer developers. By doing it in code you are forced to learn how everything fits together.
Ideally people should learn how to do everything in code. Then use IB to make things easier and/or faster. The combination of the two is good. Just relying on IB (or any other similar tool in any other environment) limits the skills of the developer to some degree since they haven't learned the basics.
It's like math class in school. You learn how to add and subtract by hand before you are allowed to use a calculator.
Just some thoughts.
I agree, IB is a crutch in a lot of cases... once you can visualize where on the screen a given point is you can place stuff very precisely without even seeing it.
for example (240,400)
that's the center of the width and 80 pixels from the bottom.
I agree, IB is a crutch in a lot of cases... once you can visualize where on the screen a given point is you can place stuff very precisely without even seeing it.
for example (240,400)
that's the center of the width and 80 pixels from the bottom.
I agree 100% with first poster and will add 3 more things:
1) I learnt that Apple, once a year, pay all regions that are stuck under $250, if these regions are over $50.
2) When you have your application Ready for Sale and you don't see it on the AppStore, just change its date. I had my first app 2 months ready for sale but not on the store. After 1000 emails to Apple without response, I discovered that "functionality" of itunes connect.
3) I discovered that reviews are localized. Change the country on iTunes and you will see different reviews. Probably reviews in other languages than english. So, a bad or good review in the US is not seen in Europe, neither in Asia... This is good for restraining bad reviews, but not for good reviews.
4) the same is true for ranking. An #1 app in the US may not be #1 in other countries... just try changing the country on iTunes home screen, at the bottom and visit each appstore.
ah, and btw, iTunesConnect sucks to infinity +1 and I hate IB too. I used it for two days too and gave up.
another thing that sucks on iTunes is this: you change your country to see reviews in other countries. Then you find a FREE application while browsing and try to download it. You cannot. You have to change the country back to yours and go for that app again.... that sucks.
Not true. I'm taking Complex Variables math class as an undergrad, and we aren't allowed to use calculators on the exams. WTF ?? Some1 needs to tell the professor this quote.
Complex numbers? Add the reals to reals, complex to complex, and simplify the roots
My First App - What I Learned
Linear Mode
