Whether you have a web product that you want to take mobile, or an idea for a mobile product that you want to build, figuring out the right platform to launch is one of the first questions your team should ask.
Should it be mobile, if so, which platforms?
It seems to be a general assumption that all products should be on every platform, and I just don’t think this is always true. It’s 2015, you need a mobile strategy, but don’t assume an app is required or a complete mobile strategy.
Not every product needs a native app component.
I love mobile. It has the unique ability to transform every industry, and users expect anything internet related to work seamlessly on their phone. This doesn’t mean every product is a great fit for an app, or that every app needs to be native.
Many products are the perfect fit for a native app, but just don’t assume it’s your product. The web is too powerful now, and can even engage the phone hardware to create exceptional experiences that weren’t possible five years ago.
Figure out a delineating strategy between mobile web and native apps.
We need to stop thinking about the benefit of having a mobile application only from the business perspective, and always think about it from the users perspective. “Of course, people will download my app, we are XYZ company, and everybody loves us.”
This might be true, but does your app add reasonable value to somebody’s life? What is the purpose? There is a barrier to downloading new apps, and a barrier to having people keep the app on their phone — does what you are building cross these hurdles?
Frequency is a leading indicator for app value.
Depending on how often people are engaging with your brand or application, this can be a leading indicator for building a native application. If the app is going to live on a phone, it should have a delineating reason and frequency of use is a leading indicator. The more often a user uses or interacts with the product or brand, the higher the expectation is to have a mobile application.
Not every app needs to be native.
If you have decided that an app is going to be part of the strategy, now it’s time to understand there are a lot of routes to travel. For a long time, I was a purist at heart.
Every iOS app needed to be Objective-C, and every Android Java, but that’s just not true anymore. The technology for cross-platform frameworks has dramatically improved since 2010, and it is outstanding what some might do with native UI kits and shared code.
One strategy is not better than the other; it’s just a question of which strategy is right for your project.
Don’t make the mistake by assuming you need a native application. If you have any questions or need help to figure out what strategy is best for you, send an email to firstname.lastname@example.org, we’d be happy to help.
This is the last part of a 9 part series called 9 Mobile Product Building Mistakes. If you have any questions or need help to build your next app, contact Seamgen today.