After posting the article, "Time for a change" yesterday, a few people made comments to me that I thought I should bring up. They basically said that on mobile it doesn't make sense to release fast and often. The point made by most people is that when you release regularly you wipe away all of your App Store reviews and start from a clean slate. And this unduly hurts small developers, when my suggestion was that a small developer should be moving quicker to beat the bigger competition. This is definitely a problem that I didn't address in my last article, so I wanted to address it here.
First off, there are big problems with the structure of the app development process as it stands today. I think there are few people who deny that. From discoverability, to workflows and the launch/update process, there are a number of frustrations and limitations that developers and app teams have to either work around or have adapted to.
I also think that we could all agree that these problems are for the most part not present in web development. Over the past couple decades a lot of the workflow, discoverability and update processes have been worked out to enable the concepts of lean development.
This all brings me to the point that releasing fast and often is the ideal goal. It is a goal that is clearly not achievable for all mobile developers today. Which is unfortunately the reason why most developers stick to the long release cycles they have adopted. I don't believe that is the ideal path that is being chosen, but rather the best of the available options.
It is our goal at Taplytics to make quick release cycles on mobile a reality. Our technology allows mobile teams to push new design, layout and flow changes without an app update, taking away that big issue of losing all of the review goodwill. But clearly there is still a ways to go. We're working hard to get there and hope we can help developers of all sizes along the way to get to a more ideal way of developing, designing and testing their apps.