As I started to work with Xcode I started to get utility routines that I would like to use across multiple projects. The first 'solution' is to just copy those into the new application. From a software engineering standpoint this is not bad, it is very bad.
I found a VERY useful post at
http://blog.stormyprods.com/2008/11/using-static-libraries-with-iphone-sdk.html
This provides in great detail how to establish a static library which can then be linked into your applications. Any routine that will be used in more than one application should be in a static library.
Monday, November 30, 2009
A useful idea: Sight Words Lists Unlimited
The next idea, which I will probably publish first is a simple flash card application. My daughter and son are learning how to read. In addition to learning phonics, they also need to learn sight words. I've spent a lot of time creating flash cards, and going over them.
In addition my daughter will often have a specific set of 8 sight words to learn for that week. She needs to learn those for this weeks test, but we also need to go over the older sight words so that she continues to gain mastery over them.
There are multiple sight word applications in the store, but most of them suffer from limitations that I can bypass.
Exiting Limitations on many sight word applications
In addition my daughter will often have a specific set of 8 sight words to learn for that week. She needs to learn those for this weeks test, but we also need to go over the older sight words so that she continues to gain mastery over them.
There are multiple sight word applications in the store, but most of them suffer from limitations that I can bypass.
Exiting Limitations on many sight word applications
- A lot of the applications only support 100 or fewer of the sight words, divided into groups, and which have to be purchased separately.
- The applications only allow you to use the pregenerated sight words.
- The ability to limit the words you go over to a specific set is not present, or is not easy to use.
The following are the features of the sight words application I would like to develop.
Minimum Feature List (in priority order)
- It should include all of the common sight words, both from the Dolch and Fry sight word lists with out of the box spoken versions of all those words.
- It should support the ability to add additional words to the list.
- It should support the ability to record your own version of the words using the iPhone.
- It should support the ability to create and manage sub lists of the total word set.
Additional nice to have features
- The ability to designate individual words to be successfully identified or not, and to remove the successfully identified ones from the current pool.
- The ability to change fonts and colors.
- The ability to restore the DB back to its original state.
- Games where a word is pronounced and select a sight word from individual choices. The faster the word is selected the higher the score.
- Better graphics and colors
Labels:
flash cards,
Requirements,
sight words
Thursday, July 30, 2009
Marketing Strategy
I am not developing applications to make a living. I would like to make enough money from my applications to cover my costs, and maybe a little extra. However part of the game is to try and maximize my exposure for the applications, and to also develop quality applications that are either useful, or give someone a laugh.
It seems to me in the current application market, the biggest problem is obscurity. My approach will be to:
Make my applications available in an ad supported format, as well as a pay format.
This won't be a light version, the ad supported format will be fully functional, it will just have ads. I expect that because of this I won't sell many of the pay versions, but thats ok.
I also plan to write this blog about developing my applications, including source code. This will hopefully both attract attention to the applications, and increase the likelyhood of getting my applications reviewed by one of the iPhone review sites.
Of course having a cynical reason to post the blog, will hopefully also motivate me to keep the blog going, and not let it wither away.
I'm a big fan of ebooks, and one of the points made by Eric Flint about book piracy applies to my applications, the biggest problem is obscurity, not piracy. Until I achieve a MUCH greater degree of success, anything that gets more hits or downloads for my application is better.
This is especially true on the Iphone Application store, there is a huge drop off after you fall out of the top 25, and even more after the top 100 (for a given category). I'm not aiming towards the big categories, but still am unlikely to enter the top 100 unless my ideas and implementation get out there.
Step 3. Apply for contracts
A helpful tip from
http://blogs.bigroostersoftware.com/2009/03/13/yet-another-iphone-developer-story/,
Namely that if you are going to be selling applications, you should submit your contract information as soon as possible so that once you have you application approved, you won't be waiting for Apple legal to review it.
Labels:
App Store,
apple developer program
Step 2. Install Source Code control
If you are going to be developing professionally, you NEED to have a source control system installed. While Xcode does not come packaged with a source control system, it does integrate nicely with Subversion.
The following document outlines some of the efforts needed to use subversion with Xcode.
Note, that this is a far more complicated process for installing subversion than is available elsewhere. You can download a prepackaged subversion that integrates with XCode from:
I pretty much just downloaded that, and ran the package. I then was able to follow the second half of the Apple document to add projects to subversion for management in Xcode.
Labels:
Subversion,
XCode
Step 1. Buy a Mac and install XCode
The very first step you should do if you really want to do development with the iPhone, is purchase a Mac. While it is possible, with a jailbroken iPhone and a Linux virtual machine to develop without a Mac, I don't recommend it. (You can even develop directly on the iPhone itself, but I really don't recommend it.
In addition if you wish to distribute through the Apple store, you need a lot of infrastructure provided by Xcode, I don't know if its possible to get around it, but IMO, it's far more effort than it's worth. Instead buy a Mac Mini, which is a pretty nice machine, and download a free copy of Xcode from Apple.
Sunday, July 19, 2009
Enrolling the iPhone Developer program
You can develop for the iPhone using the simulator just by owning a Mac, and downloading xcode. However if you want to put stuff on the iPhone to test it out, then you need to be a registered developer. It costs $99 to join, but if you are at all serious about developing for the iPhone, you should join as early as possible, since it seems to take Apple a long time to respond to your application.
5/15/2009 I bought into the developer program.
5/19/2009 I sent an inquiry about why they haven't sent me the activation code.
5/28/2009 I sent another email
6/23/2009 They responded to the first email, over a month later, and resent the email that had never been sent
7/7/2009 They responded to the second email that I had successfully enrolled in the program.
The moral of the story is that if you are going to join, join soon, and if you don't get an activation code rapidly, send a support email because it will take over a month for them to respond to the email.
5/15/2009 I bought into the developer program.
5/19/2009 I sent an inquiry about why they haven't sent me the activation code.
5/28/2009 I sent another email
6/23/2009 They responded to the first email, over a month later, and resent the email that had never been sent
7/7/2009 They responded to the second email that I had successfully enrolled in the program.
The moral of the story is that if you are going to join, join soon, and if you don't get an activation code rapidly, send a support email because it will take over a month for them to respond to the email.
Labels:
apple developer program,
iphone
Monday, June 8, 2009
Developing for the iPhone
The iphone is a very neat device. I've been using Windows Mobile (non phone) PDAs for several years, but for general usability the iphone blows them away. (My other device is an IPAQ 210, which has great specs, but I prefer using the iPhone).
Seeing the success of the application store, I've decided to try to write some software for the iphone, and maybe even make a little money along the way. This blog is for my products (when they come out), as well as my general experiences with iphone development.
Seeing the success of the application store, I've decided to try to write some software for the iphone, and maybe even make a little money along the way. This blog is for my products (when they come out), as well as my general experiences with iphone development.
Subscribe to:
Posts (Atom)