"Hybrid or Native Mobile App?" - A Good read

BenHayat

http://www.telerik.com/blogs/hybrid-or-native-mobile-app-use-the-right-tool-for-the-job

johntalbott

Ben thanks for posting this diagram. It's a good visual to differentiate what each mobile app category means.

For those that are not familiar with the mobile app categories and where AwareIM fits in ... read on ...

The current version of AwareIM supports building mobile web apps only. The caveat is that the front-end can be compiled using PhoneGap build so that the web app is embedded in the Native Wrapper App (see diagram) allowing it to be installed on a device. Basically it's creates a web app that can be "installed" without any other functionality one would expect of a hybrid mobile app. One might say ... AwareIM is dipping it's toe into the hybrid category.

This can be confusing because AwareIM marketing and documentation makes it sound as though it supports building Native mobile applications which is not accurate/misleading.

We've heard that the next version will support hybrid mobile. Hopefully that is the case.

As a final note ... because AwareIM's front end is based on HTML5, JS, CSS ... it fits the hybrid model. I would never expect it to fit the native model. That's ok, it's just important to make the distinction as there is a significant difference.

BenHayat

I have a very important question regarding Updates that we make in our Aware codes and how it reflects users.
Let's take a look at this diagram to understand my point/question.

Currently our desktop and mobile runs as a "Web app". Anytime we update our code on the web server all users will access the code in the next server request. Users don't need to do anything.

In Native apps like you write in Objective C in iOS for example, you have to submit a new build to App store, and users must update their mobile to see the new code.

Now here is my question. In hybrid, Phonegap offers a series of native codes that accesses Phone's hardware and services and also a chromeless browser shell (called Web View) that Aware code will run in it just like it would run the normal browser.
So, first I "Assume" if we make any changes to our Aware App code, and put the new code on the server, the user doesn't need to get a new copy of the hybrid app, because the our code still runs in browser shell. Right?

Now my question is, When does the user have to get a new updated our hybrid app that is on the App store? Is that When Awaresoft makes changes to the hybrid shell or perhaps updates to new version of Phonegap code? I think this might be the case, but I wanted to bring it up.
So, how will user knows when to get a NEW updated Hybrid app (that has Phonegap and browser shell in it)???

The best part about hybrid, is that every time we update our Aware code, users don't have to go to app store to get a new version of our App code.

johntalbott

BenHayat wrote
Now here is my question. In hybrid, Phonegap offers a series of native codes that accesses Phone's hardware and services and also a chromeless browser shell (called Web View) that Aware code will run in it just like it would run the normal browser.
So, first I "Assume" if we make any changes to our Aware App code, and put the new code on the server, the user doesn't need to get a new copy of the hybrid app, because the our code still runs in browser shell. Right?

Now my question is, When does the user have to get a new updated our hybrid app that is on the App store? Is that When Awaresoft makes changes to the hybrid shell or perhaps updates to new version of Phonegap code? I think this might be the case, but I wanted to bring it up.
So, how will user knows when to get a NEW updated Hybrid app (that has Phonegap and browser shell in it)???

The best part about hybrid, is that every time we update our Aware code, users don't have to go to app store to get a new version of our App code.

It depends ...

All changes that are strictly server-side logic changes (BO rule or Process logic) that will not impact the client side ... a new client install on the device should NOT be required.

Any changes to the client app - HTML, CSS, Kendo widgets, JavaScript (Advanced scripts), dynamic rules will require a new build of the mobile app to be reinstalled on the device. There are other ways to do it, but in most cases the workflow is to deploy the new build to the stores and then when the person runs that app he/she gets a notification that an update is available for download from the store.

The reason is that when the hybrid app runs it's loading/executing the client-side code (HTML, CSS, JS, UI widgets, PhoneGap plugins) directly from the the device. As a result UX is better than running a mobile web app running in a browser. Connectivity with the server is strictly running server-side processes/operations, transferring data, etc.

I haven't personally used them, but some hybrid app tools/frameworks .. such as Telerik App Builder, Appery, Ionic have tools to deploy an updated build to device without going through the store.

johntalbott

Ultimately the primary benefit of hybrid application is that they are based on standard web application technologies .. HTML5, CSS, JavaScript, etc .. that for the most part will run on Android, iOS and Window mobile devices. So code once, run anywhere is more of a reality.

This is much more efficient that having to write the web version to run in a browser, Java version to run on Android and X Code version to run on iOS.

BenHayat

johntalbott wrote
It depends ...

All changes that are strictly server-side logic changes (BO rule or Process logic) that will not impact the client side ... a new client install on the device should NOT be required.

Any changes to the client app - HTML, CSS, Kendo widgets, JavaScript (Advanced scripts), dynamic rules will require a new build of the mobile app to be reinstalled on the device. There are other ways to do it, but in most cases the workflow is to deploy the new build to the stores and then when the person runs that app he/she gets a notification that an update is available for download from the store.

The reason is that when the hybrid app runs it's loading/executing the client-side code (HTML, CSS, JS, UI widgets, PhoneGap plugins) directly from the the device. As a result UX is better than running a mobile web app running in a browser. Connectivity with the server is strictly running server-side processes/operations, transferring data, etc.

I haven't personally used them, but some hybrid app tools/frameworks .. such as Telerik App Builder, Appery, Ionic have tools to deploy an updated build to device without going through the store.

I disagree on the highlighted statement.
Even in Aware's hybrid model, ALL the client side JS/HTML/CSS still comes from server side (at runtime) exactly like the way we run today, except it will run in Cromeless browser (WebView). Awaresoft maintains the phonegap shell and we call phonegap functions via Aware's API. So, there is no client side code from us that talks to Phonegap directly. Another words, with hybrid model, we will still design and develop Mobile just like we do today running in browser, except we get new functions from Aware that allows us to tap into Mobile features. Same mobile app should still run the same way in browser like today.

Perhaps support can clarify this notion.

johntalbott

I'm 100% positive that the hybrid stack works as I described.

Wrapping a web browser in an installed shell that pulls everything from the server each time is of zero benefit over mobile web app running in a browser on the device. If this is what AwareIM is current doing and is intending to do in the next release, I'll have very little option but to abandon ship .. at least for any mobile application development.

BenHayat

johntalbott wrote
I'm 100% positive that the hybrid stack works as I described.

Appery, Ionic and any other "client" side development work as you described it above, directly use Cordova engine as client side JS like Angular JS or appery in a 3 tier model. Your client JS talks directly to Cordova engine. However, products like Aware or PHP or ASP or any other server side, use Phonegap to wrap it in a shell, because the server side nature of the model where the JS/HTML/CSS is delivered via server.
The benefit of this model is, you can turn your Web Browser app to Hybrid without modification plus having more functions to call Phonegap. This model may actual suffer from performance due to the implementation of Web View (being another browser inside of Phonegap shell).

The hybrid that you have in mind, like Ionic or Appery or Angular, are totally designed and built other than an Aware app. those are built just as a 3 tier model like we did with Silverlight where client JS, via Cordova layer talk to device OS in real time.

johntalbott

This blog post does a nice job explaining hybrid mobile apps ...

http://developer.telerik.com/featured/what-is-a-hybrid-mobile-app/

BenHayat

johntalbott wrote
This blog post does a nice job explaining hybrid mobile apps ...

http://developer.telerik.com/featured/what-is-a-hybrid-mobile-app/

Yes, this is for the 3-tier model using Kendo UI with JS as the client tier, but it does not apply to 2-tier model like MVC or Aware or PHP that are server side. This are two types of hybrids: a) Client side (as you described, using Kendo or Ionic, Angular) and b) server side like Kendo (MVC/Java), ASP MVC and Aware type apps.

I remember that blog and interview last year.

Big difference!

BenHayat

johntalbott wrote
Wrapping a web browser in an installed shell that pulls everything from the server each time is of zero benefit over mobile web app running in a browser on the device. If this is what AwareIM is current doing and is intending to do in the next release, I'll have very little option but to abandon ship .. at least for any mobile application development.

Just to clarify, Phongap is a great solution fr LoB apps that don't require heavy animation/effects and direct device services. It's well suited for business apps. But if you want to get close to the metal without going native, you need to use Cordova with other 3-tier models like Ionics that gives much better performance and you get to use Angular as your client's framework.

In fact, if you want to go through 3-tier model, you might as well use Telerik Native Script, writing code in JS and the system produces native apps like Xamarin does with C#.

mrbdrm

we have tested publishing our app with phonegap and it is running great no performance issues there with grids and charts.

but the main issues is that we don't have access to phonegap plugins from awareim.

so the only difference is users don't have to open the mobile web browser and navigate to the app url.

aware_support

This can be confusing because AwareIM marketing and documentation makes it sound as though it supports building Native mobile applications which is not accurate/misleading.

The end user is not aware of these subtle differences - "hybrid, "true native" etc. To the end user this IS a native app - it is installed as a native app, it is started as a native app and it runs as a native app - no browser is required. End users do not care about the technology underneath. So there is nothing misleading in Aware IM marketing.

The only problem with the so-called "hybrid" technology used by Aware IM behind the scenes is performance, which will never be as good as the "true native" technology. But then again writing your web application in assembler will have superior performance as well. The only thing is how long it will take you to write such an application and whether performance differences will even be noticeable compared to writing it in Java, for example. Or in Aware IM.
Performance of the hybrid apps is very decent in our observation and in most cases you won't see the difference. And hey, you write your app once in Aware IM in the fraction of the time and you get a desktop app, a mobile web app and a mobile native app for the same amount of effort. Now try doing this in Java/.NET with Objective C or Native Script...

Any changes to the client app - HTML, CSS, Kendo widgets, JavaScript (Advanced scripts), dynamic rules will require a new build of the mobile app to be reinstalled on the device. There are other ways to do it, but in most cases the workflow is to deploy the new build to the stores and then when the person runs that app he/she gets a notification that an update is available for download from the store.

This is not true. You DO NOT need to update your mobile app - no matter what you do. This is because everything about your app is provided by the server (even the advanced scripts) and the client only has the Aware IM engine that doesn't change. The only time you need to update your native mobile app is when you change the Aware IM version itself.

BenHayat

aware_support wrote
The only time you need to update your native mobile app is when you change the Aware IM version itself.

Thank you support. That was the answer that I was looking for and I kind of suspected it, but wasn't 100% sure.

johntalbott

aware_support wrote
This can be confusing because AwareIM marketing and documentation makes it sound as though it supports building Native mobile applications which is not accurate/misleading.
The end user is not aware of these subtle differences - "hybrid, "true native" etc. To the end user this IS a native app - it is installed as a native app, it is started as a native app and it runs as a native app - no browser is required. End users do not care about the technology underneath. So there is nothing misleading in Aware IM marketing.

The difference between Native and Hybrid may be meaningless to an end user, but it shouldn't be to your customers that have purchased AwareIM and are using it to build solutions. The difference is massive from a technical standpoint which in turn can impact UX even with line of business applications. Saying AwareIM produces is native AwareIM applications is completely misleading. There is no way around it.

If anyone here is out pitching their AwareIM based mobile solution as a native mobile application to someone that has even a basic understanding of mobile applications ... they will think you are trying to mislead them or you don't know what you are talking about. Either way you are done.

aware_support wrote
The only problem with the so-called "hybrid" technology used by Aware IM behind the scenes is performance, which will never be as good as the "true native" technology. But then again writing your web application in assembler will have superior performance as well. The only thing is how long it will take you to write such an application and whether performance differences will even be noticeable compared to writing it in Java, for example. Or in Aware IM.
Performance of the hybrid apps is very decent in our observation and in most cases you won't see the difference. And hey, you write your app once in Aware IM in the fraction of the time and you get a desktop app, a mobile web app and a mobile native app for the same amount of effort. Now try doing this in Java/.NET with Objective C or Native Script...
Any changes to the client app - HTML, CSS, Kendo widgets, JavaScript (Advanced scripts), dynamic rules will require a new build of the mobile app to be reinstalled on the device. There are other ways to do it, but in most cases the workflow is to deploy the new build to the stores and then when the person runs that app he/she gets a notification that an update is available for download from the store.
This is not true. You DO NOT need to update your mobile app - no matter what you do. This is because everything about your app is provided by the server (even the advanced scripts) and the client only has the Aware IM engine that doesn't change. The only time you need to update your native mobile app is when you change the Aware IM version itself.

If the client-side code is not getting packaged and installed on the device, it's impossible for it to perform as well as a standard hybrid mobile app implementation, let alone a native mobile app. And because of that .. no one is building hybrid mobile apps in this way, and just because you can doesn't mean you should.

Why in the world are you doing it this way?

aware_support

but the main issues is that we don't have access to phonegap plugins from awareim.

Version 7.1 to be released soon will include the most important plugins:
a) Access to camera
b) Access to photo gallery
c) Read geo location
d) Watch geo location
e) Send push notifications to a device

BenHayat

aware_support wrote
but the main issues is that we don't have access to phonegap plugins from awareim.
Version 7.1 to be released soon will include the most important plugins:
a) Access to camera
b) Access to photo gallery
c) Read geo location
d) Watch geo location
e) Send push notifications to a device

a) Will we be able to access "Contacts" and "Local Storage"?
b) Will we be able to provide different icon sizes as part of the package for the app store to use, when user installs the app?

mrbdrm

aware_support wrote
but the main issues is that we don't have access to phonegap plugins from awareim.
Version 7.1 to be released soon will include the most important plugins:
a) Access to camera
b) Access to photo gallery
c) Read geo location
d) Watch geo location
e) Send push notifications to a device

😃
much respect
AwareIM is just getting better by the day.

aware_support

a) Will we be able to access "Contacts" and "Local Storage"?
b) Will we be able to provide different icon sizes as part of the package for the app store to use, when user installs the app?

No Contacts yet in this version.

"local storage" is available from your advanced scripts - even in 7.0

BenHayat

aware_support wrote
Version 7.1 to be released soon will include the most important plugins:
a) Access to camera

@Support;

Just like the phones Camera app, allows us to select front or back camera, how do we tell Aware to tell the plugin which camera to use, since the user may need to capture hi resolution or low pictures using the front or back camera?
The default should be the back, high resolution camera.

Thanks!