{"id":7159,"date":"2013-11-12T10:05:47","date_gmt":"2013-11-12T16:05:47","guid":{"rendered":"http:\/\/www.mrc-productivity.com\/blog\/?p=7159"},"modified":"2022-11-22T13:22:05","modified_gmt":"2022-11-22T19:22:05","slug":"7-hiddens-risks-of-native-mobile-app-development","status":"publish","type":"post","link":"https:\/\/www.mrc-productivity.com\/blog\/2013\/11\/7-hiddens-risks-of-native-mobile-app-development\/","title":{"rendered":"7 hidden risks of native mobile app development"},"content":{"rendered":"

\"Education\"As more businesses build their own mobile apps, we\u2019re seeing an increasing number of mobile app success stories crop up. For instance, here\u2019s a recent article<\/span><\/a> highlighting 4 different companies that use mobile apps to attract customers. Here\u2019s another article<\/span><\/a> from earlier this year highlighting other companies who are using mobile apps to improve business. I could share many more such stories, but you get the point: Mobile apps are taking off in the business world.<\/p>\n

I believe this trend is on the rise. As businesses begin to understand the true power of mobile apps, many more will start building their own apps. <\/p>\n

This is where things can get dangerous. Blinded by the possibilities, many businesses dive into mobile app development completely unprepared. They don’t understand the risks associated with mobile app development, and are headed for some unpleasant surprises.<\/p>\n

Today, I\u2019d like to help you avoid those surprises. I\u2019m going to highlight a few of these hidden risks, with the hopes that you\u2019ll be more prepared when you start the process. <\/p>\n

But first, let\u2019s quickly specify which type of mobile app we\u2019re referring to. There are 3 different types of mobile apps (native\/hybrid\/mobile web), which you can learn more about here<\/span><\/a>. However, today we\u2019re focusing on the risks of developing native apps. Native mobile apps are downloaded via an app store\/market and installed on the device itself. I\u2019m addressing native apps because they\u2019re probably the most popular application type, but also come with their fair share of hidden risks.<\/p>\n

So, what hidden risks should companies watch out for when they dive into mobile app development? We posed that question to a few experts in the field, and have compiled their advice (along with some of my own) below. Here are 7 hidden risks of native mobile app development:
\n<\/a><\/p>\n

1. Risk of building an app that your target users don\u2019t want<\/h3>\n

The biggest nightmare for any business developing a mobile app: Delivering an app that their users don\u2019t even want. Native app development requires tens (and sometimes hundreds) of thousands of dollars and months of time. It\u2019s all wasted if no one uses the app. How does this happen? This happens when you approach mobile app development from the wrong perspective. <\/p>\n

\n\u201cMany businesses fall into the trap of creating an application from their own perspective, and not the perspective of the customer,\u201d says Arash Zafarnia, Director of Business Development at Handsome<\/span><\/a>. \u201cIt is a good habit to seek input from customers and understand what type of feature and functionality they would be looking for in a mobile experience. In addition, it will be helpful to understand what type of mobile devices most of a business’ customers have.\u201d\n<\/p><\/blockquote>\n

2. Risk of unsustainable user growth<\/h3>\n

On the opposite end of the spectrum, we find another challenge: What happens if too many people start using your app? What if it takes off faster than you could ever expect? You could be stuck supporting hundreds of thousands of users. Are you prepared for that?<\/span><\/p>\n

\"photo
photo credit: FutUndBeidl<\/a> via photopin<\/a> cc<\/a><\/figcaption><\/figure>\n

\u201cA small dev team may create an app that is then used by thousands or even millions of people,\u201d Abinash Tripathy, CEO and cofounder of Helpshift<\/span><\/a>. \u201cProviding service and support to rapidly growing numbers of end users becomes completely unscalable (*and costly*), which can result in angry or confused end users who either leave a negative App Store review and\/or delete the app (according to Flurry, a majority of app users churn within 90 days). As with any new technology, internal apps create new burdens for IT to help users individually when they’re having trouble. Some solutions for both internal and external apps include automating the service and support process by creating custom FAQs, utilizing shared inboxes, bulk actions, and integrating in-app help desks into the app.\u201d<\/p>\n<\/blockquote>\n

3. Risk of choosing the wrong development partner<\/h3>\n

\n\u201cThe biggest hidden risk lies in the propensity to outsource mobile development among companies big and small,\u201d says Danny Boice, co-founder and CTO of Speek<\/span>. \u201cYou have to be very careful who you “get into bed with” when it comes to these shops and making sure your contract accounts for things like who is responsible for UX and UI Design, how is QA going to be handled, what is the definition of “done” mean is extremely important. I have had some nightmare experiences dealing with questionable mobile development shops at both Speek and The College Board.\u201d\n<\/p><\/blockquote>\n

The fact is, most businesses can\u2019t afford to develop their mobile apps in-house. As result, they must turn to outside help–which adds a layer of risk to the project. After all, the wrong development partner can ruin everything. So, how can you avoid choosing the wrong development partner? While there\u2019s no single answer that applies to every situation, here\u2019s one rule of thumb: Avoid low-cost outsourcing.<\/p>\n

\n\u201cLow-cost outsourcing can be one of the nastiest traps of mobile app development,\u201d says Joseph Pigato, Managing Director at Sparked<\/span>. \u201cI’ve had numerous colleagues who just couldn’t pass up the low bids of overseas operations. They almost invariably encounter delays, hidden costs and lapses in quality. Occasionally, they’re forced to scrap their low-cost code and start all over.\u201d\n<\/p><\/blockquote>\n

4. Risk of security breaches<\/h3>\n

Security breaches are certainly nothing new, and apply to any type of web or mobile app. The danger here lies in underestimating the need for proper security precautions within native apps. Some companies make the mistake of assuming native apps are inherently secure, and ignore proper security measures in the process.<\/p>\n

\"photo
photo credit: ePublicist via photopin<\/a> cc<\/a><\/figcaption><\/figure>\n

\u201cDespite many of the same security flaws as web applications (XSS, insecure storage, Cross-Site Request Forgery, insecure communications, etc), many mobile developers assume mobile devices are more secure by default and don’t go through the same security-vetting process as with other applications,\u201d says Benjamin Caudill, Co-founder and Principal Consultant at Rhino Security Labs<\/span><\/a>. \u201cThese lax security protocols can result in data compromises or even infrastructural breaches on the server side, using attacks such as SQL injection.\u201d<\/p>\n<\/blockquote>\n

5. Risk of getting denied<\/h3>\n

One of the most important realizations that businesses must come to accept about native mobile apps: You\u2019re playing in someone else\u2019s sandbox. You must play by their rules, or run the risk of getting your application denied.<\/p>\n

\n\u201cAnother hidden \u2018consideration\u2019 is the app store submission,\u201d explains Boice. \u201cThis is something you simply don’t have to deal with when it comes to traditional desktop or web applications. It is imperative that your contract make the dev shop responsible for the submission and acceptance of the app store you are submitting your app to. Apple in particular will very likely reject your app at least once and you need the dev shop be on the hook to fix it and keep resubmitting until it is approved and listed.\u201d\n<\/p><\/blockquote>\n

To make matter worse, these app store\/marketplace rules are subject to change. After all, the owners (Google\/Apple\/Microsoft) have full control over their respective stores. If they change the rules, you must comply…or face rejection.<\/p>\n

\n\u201cEach mobile platform has it’s own ever changing rules and requirements for app submission,\u201d says Diane Hamilton, Managing Partner at Binary Formations<\/span><\/a>. \u201cThere is always a risk that one or more of your features, though passed originally, may be rejected because a new rule or requirement has been introduced. This is an ongoing cost that is often not considered. Sometimes these App Store changes can be significant (Apple sandboxing for Mac OS X).\u201d\n<\/p><\/blockquote>\n

6. Risk of investing in a platform that you can\u2019t control<\/h3>\n

In my opinion, the biggest risk of native mobile application development lies in your complete lack of control over the platform itself. What happens if the platform owner decides to sell itself or shut down entirely? Since you have no control over the platform, you\u2019re out of luck. <\/p>\n

For example, look at Blackberry. The company that practically invented the smartphone market is now on the ropes–having lost considerable market share over the past few years. Companies that chose to build apps for this platform now face the very real possibility of seeing all of their money and effort disappear. It\u2019s a big risk, and one that you shouldn’t take lightly.<\/p>\n

7. Risk of tying yourself to a single platform<\/h3>\n

When developing native apps, you face a tough question: Should you support every platform or just one? Supporting every platform protects you from the problem listed in the previous point, but is also far more costly and time consuming. Choosing a single platform is cheaper, but ties your application\u2019s success to that platform\u2019s success.<\/p>\n

Why is that such a risk? Besides the risk of the platform disappearing, it could also limit your company\u2019s future options. For instance, suppose you build an iOS app for your sales team, who all currently use iPhones. What happens if your sales team wants to switch to Android or Windows phones in a couple of years? Unless you recreate the app for the desired platform, you\u2019re pretty much locked into iOS. Choosing a single platform is a risky approach, because it limits your company\u2019s future options.<\/p>\n

What do you think? Would you add anything else to that list? If so, I\u2019d love to hear it in the comments. <\/p>\n","protected":false},"excerpt":{"rendered":"

As more businesses build their own mobile apps, we\u2019re seeing an increasing number of mobile app success stories crop up. For instance, here\u2019s a recent article highlighting 4 different companies that use mobile apps to attract customers. Here\u2019s another article from earlier this year highlighting other companies who are using mobile apps to improve business. …<\/p>\n

7 hidden risks of native mobile app development<\/span> Read More »<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"default","ast-global-header-display":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","slim_seo":{"title":"7 hidden risks of native mobile app development - mrc's Cup of Joe Blog","description":"As more businesses build their own mobile apps, we\u2019re seeing an increasing number of mobile app success stories crop up. For instance, here\u2019s a recent article h"},"footnotes":""},"categories":[8],"tags":[35],"class_list":["post-7159","post","type-post","status-publish","format-standard","hentry","category-education","tag-mobile-apps"],"_links":{"self":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/7159","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/comments?post=7159"}],"version-history":[{"count":20,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/7159\/revisions"}],"predecessor-version":[{"id":14053,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/7159\/revisions\/14053"}],"wp:attachment":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/media?parent=7159"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/categories?post=7159"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/tags?post=7159"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}