Category Archives: Mobile App Development

Mobile Apps Aren’t a Get Rich Quick Scheme Despite Rumors.

Posted on by

We have all heard stories of apps that have brought their creators a lot of money. We all know of programs and apps that are worth millions. Unfortunately, that isn’t the case for most apps out there.

I have personally managed to get apps ranked in the top 10-20 in their categories, yet I am far from rich. It’s kind of like winning the lottery, though to even get to the small winnings takes a lot of work. I have close to a dozen apps for sale that I have written and updated over the years. I am currently working on several more along with some major updates to an existing app, yet money isn’t rolling in.

If you want to get in the top tiers, you need to be ready to work and also find a way to focus on marketing. Marketing is side of app development that I have the most trouble with. I am decent at creating an app that is useful for people and supporting the app. I’m not the best at getting people to find the app in the first place, though. That is a subject that I hope to write about more as the year goes on with some actual solutions.

But, for now, if you are planning to write an app or several don’t be discouraged if the sales don’t magically appear. It takes time and effort. Also, remember for every app that you hear about that is worth millions of dollars, thousands of them bring in at most a few hundred dollars. If you really want to make things work, then you’ll need to find a way to keep pushing even if you aren’t making the money that you hoped that you would make.

Listen to Your Users, but Don’t Surrender Your Own Vision.

Posted on by

This post was inspired by one of my apps – Time Clock Helper. As I mentioned in a previous post, Time Clock Helper was written because I needed to calculate the hours I worked on a standard punch card. The app has been in the app store for a while and used by a lot of people. So, that being the case means that I get requests for features regularly. Some of these features are good ideas such as being able to track more than a single day, or emailing the hours worked to someone else. They weren’t aspects that I had originally planned on, but they have proven useful to many users. I didn’t have to give up the core reason for the app to implement them, or make it more complicated to use.

Well, sometimes the requested features don’t make as much sense. One example of this was making a way to track multiple employees using a central server. While, it would be possible to make that happen and I know it could be useful it would take away from the actual purpose of the app. There are many apps out there that do just that and probably do it better than I would have. That wasn’t as much the issue, though.

I wanted an app that would make it easy for a user to calculate the hours worked on a single time card using the standard four punches. Anything that makes that more difficult would take away from the actual purpose of the app. So, while I like giving people what they want, I make sure that it makes sense for the overall app and won’t hurt the original purpose for the app.

As you develop your own apps, it is important that you know what you want to accomplish, and who would most likely use it. Then, try to only implement features that will be needed to serve those users. It is really easy for features to creep into an app that make it more difficult to use, or hurt it in other ways such as clutter, or slowing it down.

Rubber Duckies aren’t only for Bathtime – how to solve problems.

Posted on by

When you are stuck with a problem it usually helps to talk through what is happening. Often, simply talking through the problem will make a solution come to light. It’s technique that has been around for a long time, but often the credit goes to The Pragmatic Programmer book that I mentioned a week or so ago. The technique in the book is called rubber duck debugging.

If the problem is with a program that you are writing, simply talk through the code line by line outloud to an inanimate object. A person would also work, but that’s not often possible or the easiest solution. As you talk through each line and explain them you will often realize that the code might not be doing what you were planning for it to do – thus finding the problem and guiding yourself to a solution.

I’m going to post a link to an article that goes into a bit more detail about the psychology at play: https://www.thoughtfulcode.com/rubber-duck-debugging-psychology/

Talking about your problems with a rubber duck will often lead to a solution even if it seems a little foolish.