There are two fields of thought of thinking when it comes to app versioning:

1) Add multiple features in the next release

This theory states that if we have multiple,  well thought- out features and we publish them in a comprehensive release, the user’s experience will be enhanced. While its heart is in the right place, we believe that this wide approach is detrimental.

Since uUsers have limited attention spans, if multiple features are introduced at the same time, we run the risk of some features not being discovered and ultimately forgotten. This is a problem for multiple reasons:

- Resources spent creating a non-used feature;

- Less ideas for future releases;

- We will never know if this feature failed on its own merits or not.

2) Introduce 1 or 2 major features per release

It might seem counter intuitive to stimulate user engagement by providing fewer features but we believe this approach is best for several reasons:

- One/two features to focus on, no attention dilution;

- Easier to determine whether a feature is a success or not;

- If it’s a failure, it can be improved upon or replaced;

- If it’s a success, the feature paves the way for a new feature;

- Cheaper to deploy.

So how do you decide what feature(s) to add to the app on the next release?

The short answer is let the users tell you. The long answer implies studying all your feedback loop tools like analytics, emails, AppStore comments, Apptentive feedback etc.

Most of the time, there will be a feedback red thread. It usually looks like: “It would be great if we could do x” or the less appealing “This app would be good if it had x”. This red thread is a great jumping point when it comes to deciding upon new features. While not infallible, if multiple users ask for the same feature, it’s a safe bet to add that feature or a variation of that feature. At best, this new feature will be an educated guess that will be disproved or ratified in time as user feedback begins pouring in.

Look at many of the famous, million- plus, user-base apps; the majority of these are on version 3, 4 or higher. These companies understand the crawl, walk, run approach and understand the value of releasing a small upgrades in a steady fashion based on user feedback.

We hope these thoughts are helpful to you whether you are building a completely new app or you are improving on an established product. Feel free to give reach out to us as we will gladly jump on a call and discuss your app versioning strategy.

Check out the press release on Market Watch here:

http://on.mktw.net/YRBOSv 

We want to thank all of our clients for working with us and constantly challenging us to be better. Thanks to SourcingLine and to the entire Ebbex team

Enter into the murky world of the Apple Review Process. Cupertino never shares (or commits to) an app review timeline; it took the efforts of a congressional subcommittee dedicated to consumer protection to begin to understand Apple’s reasoning and process.

“Of the 26,000 applications submitted for review each week, 30 percent are rejected for failure to meet developer guidelines”. – Tim Cook (Apple CEO)

The interesting stat here is that 26,000 apps are submitted each week (or 1.3 million a year). That number has grown significantly from 8,500 in 2009 and 15,000 in late 2010. In essence, Apple also has to staff, train and review at the same pace as the markets’ voracious hunger for their apps, and keeping up is a feat in itself. Apple has to staff, train and review at the same meteoric pace of the markets’ hunger for apps, just keeping up is a feat onto itself.

Nevertheless, we all still need to know when our apps will be available. The following are 2 very good (though, not perfect) options that we use on a day to day basis:

1) We obsessively check reviewtimes.shinydevelopment.com. The guys at Shiny Development have created a crowd-sourced timeline, based on other developers’ experiences that constantly updates itself. From our point of view, this resource has been pretty accurate. As a rule of thumb, we add 3 days to it just to play it safe.

2) Update Versioning. This is an indirect, yet successful way of dealing with marketing and app review timelines. With update versioning, you can choose to submit to the App Store without 1 or 2 main features in order to make marketing timelines. While Apple is reviewing, (currently at 7-8 days per above) the app can be completed as the features are re-added and/or revised.

With this option, the app gets shipped and marketing deadlines get met. In addition it has been our experience that app updates (aka v1.1 ,etc.) take less time to be reviewed and accepted onto the AppStore.

This strategy is beneficial when the cost of loosing missing marketing deadlines is more than the cost of not having a full-featured app on the AppStore for approximately a week.

While these 2 options have proven to be very helpful, the best advice is often the simplest. Schedule your marketing to start way significantly after development and has been completed.

Thank you to all of clients and the whole team. Its all your trust and hard work that makes everything possible.

Check out the report here.

There is no certainty in the app world; even the best idea is just a set of well educated assumptions. You will never know what actually works and what needs some adjustment until you launch. Steve Blank said it best: “No business plan survives first contact with the customers.” So how do we find out what users really want?

The Feedback Loop
A strong feedback loop is the evidence that either proves or disproves our initial assumptions. Here are 4 tips to build a great feedback loop into your app.

1  App Analytics

We especially like Flurry’s free package. It is a very powerful program that allows you to track time used in the app, features used and demographical information.

2  ”Rate Us”
A well built app assumes that the user experience will be a positive one. Asking your users to rate the app is both a sign of confidence and a great feedback loop tool. There are two variations to this tool:
The “Rate Us” button that, when pressed, sends the user to your app’s AppStore page to rate and comment.
The “Rate Us” pop up that allows the user to either ignore, postpone or act on the rate request. This tool can be coded to appear at a predetermined intervals, for example at second, fifth and tenth launches.
Constantly checking the reviews posted on your AppStore is an important consideration of ratings. Equally as important is not overreacting to a couple of negative posts as we are looking for patterns, not expressive individuals.

3  ”Contact Us” Email
Placed in a “settings” or “info” area of your app, a “Contact Us” button that pulls up an in-app email is a very good driver of feedback. Keep these guidelines in mind:
Keep the “compose email” view in the app, don’t send your users to a mail app.
Ask them a direct question and phrase it in a way that they are prompted to express themselves. “Do you like our app?” is a bad question; instead ask something that involves a more in-depth answer, such as: “What is your favorite feature and what changes would you like to see in our app?”
Thank them and promise a reply. This helps start a conversation with your users.

4  AppStark
This new service, while not for everyone, is very powerful. Check it out for yourself at appstark.com

You have Feedback, now what?

Now Version 1.0 app is perfect. Your user feedback will now allow you to start versioning and create a roadmap of added features and adjustments. There are usually two schools of thought:

1)  Release Early and Often.

Releasing updates and fixes as soon as possible is the best way to keep your community happy, but this strategy is more effective for apps with bigger user bases and bigger budgets.

2)  Release comprehensive updates.

Unless you discover a mission critical bug, many app publishers and developers opt for a slower more methodically versioning model. As your feedback loop grows, identify all the changes you want for your app and collect them until you have a meaty update.

Regardless of who you are (app entrepreneur or established company) a feedback loop is one of the most important pieces of your app. Give us a call and we will help you decide on a strategy that best fits your business and app.

Benefits of Smart App Banners:

• When a user navigates to your mobile website on the Safari browser, the iOS will automatically show a banner with your App icon, reviews and pricing. Included in the banner is a “one click switch” to your app’s page on the AppStore.
• The feature minimizes your users’ effort to download your app. This in turn, allows you to concentrate on sharing your app’s value proposition on your mobile site instead of worrying about where to place the old “Available on the AppStore” rectangular link.
• The Smart App Banner feature puts even more emphasis on your app icon since it’s the first thing your user will see when they navigate to your mobile site. A great icon means more downloads.
• If the app is already installed, tapping the icon switches to the app.
• The app will remember any information that was inputted on your site before the switch.

As Apple keeps making conversions more efficient, the role of good design and development grows in importance. Give us a call or drop us an email and we will gladly talk about your app and your mobile strategy.

This first build, or Alpha, always brings the feeling of a “False Peak”. This term is used in mountaineering to describe a peak that appears to be the pinnacle of the mountain but, is in fact, not. False peaks can have significant effects on a climber’s psychological state by creating feelings of dashed hopes or even failure.

The Alpha build is almost always burdened with unfair comparisons since there is a tendency to think it’s going to be the finalized product, when in reality, a lot of work still remains. On average, we release 6 test builds to our clients before arriving at the final build to submit to the AppStore. The fastest we’ve arrived at a final build has been with 2 releases and the longest has been 15 releases. Our experience dictates, quite counter intuitively, that there is a sweet spot in terms of numbers of releases (5-6). The fastest is not always the best and here are a few reasons why:

- The more eyes we can get on an app the best. If a lot of people that care are actually testing the build, we will capture everything that needs to be addressed before the release.
-Ownership: As we release the builds, we expect our clients to comb through the app and provide us with detailed feedback. Our clients have a vested interest in providing thorough, accurate feedback, which results in a superior final product.
- Multiple build releases lead to multiple conversations that help position the app to launch. Changing from “build” mentality to “ship” mentality takes time and energy.

To keep the momentum going, we use world class tools like TestFlight to distribute the builds and Basecamp To-Do lists to log and track feedback. These tools, as well as constant communication, help defeat the “False Peak” phenomenon.

Building an app is an iterative and very collaborative process. We work closely with our clients to produce an excellent and well-received product. Give us a call, we would love to discuss your project and see if we are a fit to work together.

We don’t believe in hourly rates, here is why:

• It creates an incentive to “waste” time and take longer on a project. It leads to over estimating the timelines.
• It takes advantage of the “knowledge gap”. If the developer says its going to take a little longer than expected, how is the client going to be able to refute this claim knowledgeably?
• As much as it’s growing, the mobile app development industry is still in its infancy. Most of the apps that we work on need a certain level of R&D. We do our homework before making promises, if we know your product will take some figuring out, we will let you know. We don’t believe our clients should pay for the early stage in which the mobile app industry finds itself.
• QA testing. We believe that the client should never pay for making sure that our work is done right. If we promise certain functionality, its our responsibility to make it happen.

So, what do we do instead of hourly rates?

Milestone payments. Milestones are about accountability and value. We typically ask for the first payment upon reaching an agreement. This shows us that the client is serious, committed and invested in this project. As we have shared before, client commitments are an integral part of developing an iPhone app or developing an iPad app.

From then on, the payments are to be released on meeting the following milestones:

• Completion of the Architectural phase
• Completion of the Design phase
• Completion of the Development phase

Milestones allow us to exchange money at the point of value creation and never on an arbitrary time measurement. To date, this method has worked very well. All of our clients have been fully engaged in the process and we have never had to change our quoted price.

To learn more about how we price apps please see our “Pricing” page.

We want to say thank you to all of our amazing clients. Thanks for trusting us with your vision and for always working with us and being open to our out of the box approach. We look forward to serving you in the new versions of your apps.

Check out the press release at MarketWatch

Thanks to SourcingLine and to the entire Ebbex team.

However, the following questions are almost always asked in the process of defining your app’s feature set:

• Is everyone going to understand how to use this particular feature?
• Should we include some explanation text?
• Should we change the layout?
• Should we increase the font size?
• Maybe we should change the design so it looks like the settings app, everyone knows how to use the settings app right?

All valid questions. But somewhat off point unless they are framed within the knowledge that, despite your best efforts, you will never be able to please everyone. There are many ways to answer a question, but not all of the answers are correct.

So, what’s so wrong with finding answers to every single issue? We want to make a great app, right? We do, but not at the expense of losing the app’s magic. We want to parade our apps’ sex appeal, not hide it under too many details. If we provide an itemized solution to every potential snag in an app’s feature set we’ll end-up with an instruction manual rather than an app. If we try to accommodate all the needs of every likely user we run the risk of diminishing the overall user-experience. And why would that be? Because we wanted to please everyone. In trying to explain a particular feature to a minority, we diminish the experience of the majority.

It feels counter intuitive at first, but quality apps are purposefully designed for 80% of potential users. Embracing this paradigm promotes innovation and stunning UIs.

So how do we avoid falling into the pitfall of pleasing everyone?

Easy. Create an app definition-statement. Apps are not a combination of features, but rather a specialized mobile solution to a specific mobile problem/opportunity. An app’s definition-statement works as the guideline for most architecture and design decisions.

Your app’s definition-statement helps you understand who your primary and secondary users are. Who are you making your app for? What is their age group? Are they a particular interest group?

Think about it this way. Let’s say you are developing a social media photography app. Will older users get confused by the swipe navigation feature? Maybe. Will my young tech-savvy users like a swipe navigation feature? Definitely. We should always focus on answering the second question, focus on our primary users, focus on the 80%.

Have a minimal feature set.

The app store is maturing and the bar is as high as ever. As a development community, we need to be bold and continue to produce great looking and easy-to-use apps. We encourage you to design for only 80% of your users.