With a growing number of clinicians jumping into the world of health apps for the first time, we’ve taken some time to step back and cover a wide range of basic concepts, from the very basics of developing health apps to the ways in which you can deliver content to your users.

To date, we’ve focused a lot on the design of health apps. But the work doesn’t end once you release your health app. In some ways, that’s when things really pick up. Here are some tips and pearls on managing your health app after it hits the market.

Release cycle

The maintenance cycle consists of bug fixes and feature releases. You can lump them together or do them one-by-one. Usually, the feature release gets a “bigger” number, as in the X in 5.X.0, while bug fixes get the “smaller” number, as in the Y in 5.1.Y.

Because Google Play allows for quick releases, I tend to push out each bug fix as a separate release. It takes only 5 minutes, if that. I can even push bug-fixes to my bug-fixes really quickly if I made a mistake. Low risk, low reward.

The Apple app store takes about one-half hour for the file to process, so it occupies (part of) my attention for a while. Then I have to wait a day or two before submitting the next version. That waiting period could entail several new versions. As such, the strategy with iOS that I use is to push out new code in bunches. Test well before you ship. High risk, high reward.

Customer Service

Respond to your emails quickly. It will win the hearts of your users. It will also keep them from going elsewhere. Be honest with them. Do not promise the moon. All they want to know is that you’re listening, even if you say no. You are looking to win them – even if that means them telling a friend about you. Customer support is essential in any new venture.

Provide a means in your app to report bugs. I was embarrassed that my code possessed bugs when I first worked as a programmer in the early 2000s. Now, I realize that bugs are everywhere. I spend less energy anxious about bugs and more energy trying to find them. Make people who catch your difficult bugs to be your best workmates.


Your challenge in this phase is to grow efficient. Ideally, you have another project on board that you want to make time for. Learn to juggle. Bug-free code is always the unmet ideal.

The best way to grow efficient is to learn to handle your code quickly and to learn it inside out. I’m amazed at some colleagues I have that have their code memorized at an almost line-by-line level. I certainly don’t have that mastery. I memorize at the concept level, and even then, I have to reread code some. Luckily, the code doesn’t forget!

Some people find comments helpful in this aim of mastery; others, like me, find keeping up with comments unnecessarily slowing. I prefer to read native code because I find it quicker than worrying about whether comments are accurate. Different styles. Know the styles of your team and attend to them. If you have a new programmer on board, probably comments are necessary. If all you have are experienced folks, then comments may go to the wayside.

If you have experience developing health apps, feel free to share your tips and thoughts in the comments section. If you’re interested in contributing a guest article, contact us via our Contact page.