Developing a New App? Three Options (Two, Really…)
In our world where screens are getting bigger and bigger and smartphones are getting faster and faster, mobile apps are becoming more impressive than big and more important than fast. Mobile apps are no longer an option; they're an imperative for your marketing campaigns, your business intelligence reports, your project management tools, in every aspect of your business.
So now that we are clear that you need mobile apps, how do you start building yours? Like Goldilocks in Publisto’s iPad app “The Three Little Bears”, you might have to try a few chairs (in our case, development tools), before you find the one that is just right for you and your company’s needs.
Well, in order not to break any chairs like Goldilocks and waste time and money creating mobile apps that don’t perform well, or take a long time to develop or are completely unmaintainable after just a year or two we can help you make the correct choice.
There are two approaches (actually there are three but the two fall under the same category): a. you go native or b. you go cross-platform. If you choose to go cross-platform you have to decide whether you will go full-HTML5 or in a Hybrid approach. But let’s clear things out:
Native are the apps that are built for a specific mobile platform (iOS/Android) using the Software development kits (SDKs) and written in the programming language of the respective platform (Swift in Xcode for iOS and Java on Android Studio for the Android devices). These apps can only be installed on the appropriate operating system but they look and perform the best.
HTML5 are the apps that use web technologies (usually HTML5, JavaScript and CSS). They are built once but run everywhere on any device. You can build powerful apps using web technologies but some limitations exist when these apps run on the devices such as offline storage capabilities and interoperability with some native functionalities such as the various sensors, calendars, payment features etc.
Hybrid apps are exactly what the name suggests, apps that are built using web technologies encapsulated in a native container combining the best of the two worlds (and sometimes, the worst as well).
You might say that this is an easy choice, Native seems to be the best approach: it’s powerful, it has a good-looking UI and is supported by the company that makes the device. This is partly true. But if you intend to create an app in both the major operating systems (iOS and Android), you might have to think again because a native approach would cost twice as much in billable hours as the cross-platform (HTML5 or Hybrid) and you will need two separate development teams to undertake the task.
On the other hand, if you choose to go cross-platform you will not reach the level of performance that the native app will have and your UI will be emulated to seem like native but it will cost much less. And take less time to develop.
It sure is a tough choice. In our exceedingly volatile mobile development world, where Operating Systems change every six months and where new features and capabilities are constantly becoming integrated in smartphones, you have to choose the strategy that best fits your needs.
So your first priority is, really, clarifying with your team what your true needs are. No option about that.
So now that we are clear that you need mobile apps, how do you start building yours? Like Goldilocks in Publisto’s iPad app “The Three Little Bears”, you might have to try a few chairs (in our case, development tools), before you find the one that is just right for you and your company’s needs.
Well, in order not to break any chairs like Goldilocks and waste time and money creating mobile apps that don’t perform well, or take a long time to develop or are completely unmaintainable after just a year or two we can help you make the correct choice.
There are two approaches (actually there are three but the two fall under the same category): a. you go native or b. you go cross-platform. If you choose to go cross-platform you have to decide whether you will go full-HTML5 or in a Hybrid approach. But let’s clear things out:
Native are the apps that are built for a specific mobile platform (iOS/Android) using the Software development kits (SDKs) and written in the programming language of the respective platform (Swift in Xcode for iOS and Java on Android Studio for the Android devices). These apps can only be installed on the appropriate operating system but they look and perform the best.
HTML5 are the apps that use web technologies (usually HTML5, JavaScript and CSS). They are built once but run everywhere on any device. You can build powerful apps using web technologies but some limitations exist when these apps run on the devices such as offline storage capabilities and interoperability with some native functionalities such as the various sensors, calendars, payment features etc.
Hybrid apps are exactly what the name suggests, apps that are built using web technologies encapsulated in a native container combining the best of the two worlds (and sometimes, the worst as well).
You might say that this is an easy choice, Native seems to be the best approach: it’s powerful, it has a good-looking UI and is supported by the company that makes the device. This is partly true. But if you intend to create an app in both the major operating systems (iOS and Android), you might have to think again because a native approach would cost twice as much in billable hours as the cross-platform (HTML5 or Hybrid) and you will need two separate development teams to undertake the task.
On the other hand, if you choose to go cross-platform you will not reach the level of performance that the native app will have and your UI will be emulated to seem like native but it will cost much less. And take less time to develop.
It sure is a tough choice. In our exceedingly volatile mobile development world, where Operating Systems change every six months and where new features and capabilities are constantly becoming integrated in smartphones, you have to choose the strategy that best fits your needs.
So your first priority is, really, clarifying with your team what your true needs are. No option about that.