Develop Reference

React Native vs WPA apps experience so far

I have a medium size project on React+Nodejs and I need to choose best suitable technology for the mobile part. I am considering React Native or Web Progressive Apps for that. I want to ask you guys what is your experience so far about performance of "native-like" React Native versus WPA based apps.
I need to put into consideration:
1. Making it as easy as possible to make a transfer from ReactJS code into mobile.
2. Hardware support on mobile devices. Such as Barcode reading and NFC.
3. Push notifications.
4. Function well on both Android and iOS.
Biggest question is whether WPA technology has already become mature enough to trust it or not.

I had to make the same decision couple of months back and we chose PWA (not the answer for everyone yet).
Here is why we chose PWA,
1) Performance - Web can now perform 60fps - The magic number needs for native like smooth transitions.
2) Cost - Its fast and easy to build a product for both as a mobile app and web using PWA with no learning curve for existing web developers.
3) Proven - Starting from Twitter lite to Flipkart, there are so many success stories on PWA. No doubt its reliable. With iOS support coming couple of months back, now all major browsers support it.
PWA limitations and workarrounds,
1) Hardware - PWAs are limited to what web can do today. So there are hardwares like bar-code scanner we don't have any scope of support anytime soon and there are some hardware which very limited support and some hardware like Bluetooth with average support(in terms of % of browser versions supporting today) We had to build a small Android Native application to interact with these hardware and pass on the info to PWA suing web sockets. Say, when a barcode is scanned, this native Android service will listen for and receive it and pass on to our PWA. Same thing goes to NFC.
2) Packing and deploying - There is no official way to generate an APK and distribute in corporate environment. We were able to extract the APK after adding the PWA app to home screen using some file explorer and use that to distribute though. Havent tried on iOS. Hope for latest versions for any mobile OS, we can use cordova(not pure PWA but we get most of the benefits like Service Worker) to package and distribute as well.

What features do Progressive Web Apps have vs. native apps and vice-versa, on Android [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
In 2015 Google introduced a new approach for developing web apps for Android: progressive web apps. One can create an application that will look like a native application, will be able to use device's hardware like camera and accelerometers, receive push notifications, have a launcher icon, work in offline, store local data, etc.
On Android, what features do native apps provide that progressive web apps do not support, and vice versa.

TL;DR - As of Feb 2017, Progressive Web Apps are a sufficiently powerful platform that Twitter has moved all of their mobile web traffic to a React PWA.
As of August 2016, Progressive Web Apps actually offer more hardware access than commonly thought. Here's a screenshot of whatwebcando.today from my Chrome 52 stable on Android:
Hardware access includes
geolocation - supported in the vast majority of browsers
camera and microphone via the getUserMedia/Stream and the upcoming MediaStream Image Capture APIs
device vibration
screen orientation and accelerometer access, including compass and gyroscope
battery status
Upcoming hardware access
These features are being implemented or already work in some browsers:
Bluetooth via Web Bluetooth API
NFC
ambient light sensor (works in Firefox 48+)
proximity sensor (works in Firefox 48+)
accelerometer, magnetometer and gyroscope sensor access
shape detection API
Another important point to note is that the Origin Trials Framework (implemented in Chrome) enables manufacturers to expose and test hardware (or software) capabilities without having to go through the standardization process. For example, a phone maker could expose an API for reading the values of a pressure sensor, refine it, then submit it for consideration to the W3C.
Besides hardware access, there are also software features traditionally employed by native apps that are now available to web apps.
Traditionally native features that PWAs can also use
push notifications
working offline
adding an icon to the home screen
appearing in the apps list thanks to WebAPKs - Progressive Web Apps can now be packaged into actual installable Android packages!
launching in full-screen
clipboard access
hardware-accelerated 2D/3D graphics via HTML5 Canvas or WebGL - check some of the HTML5 Canvas demos, WebGL sites or the three.js library. A 2014 benchmark of the Unity cross-platform game engine compared native vs. WebGL rendering performance, and concluded that
"The most important takeaway is, while there are still areas where WebGL is significantly slower than native code, overall you can get expect very decent performance already, and this can only get better in the future."
The gap has indeed been closing.
reading user-selected files in any browser
slick, smooth UIs with 60fps animations
These features cover a lot of use cases, and many popular native apps nowadays could be rewritten as PWAs. Take Slack, for example. Its open source alternative, Rocket.Chat, is building a PWA version. For more PWA demos, see https://pwa.rocks.
Native-like features coming to PWAs
handling intents  —  for example, sharing a page to another app, or being the share target, e.g. a PWA chat app that receives an image to set as the user’s avatar
Native Android features not yet available to PWAs
access to the fingerprint sensor (under development)
contacts, calendar and browser bookmarks access (lack of access to these could be viewed as a feature by privacy-conscious users)
alarms
telephony features - intercept SMSes or calls, send SMS/MMS, get the user's phone number, read voice mail, make phone calls without the Dialer dialog
low-level access to some hardware features and sensors: flashlight, atmospheric pressure sensor
system access: task management, modifying system settings, logs
Progressive Web Apps offer features that native apps lack
discoverability - content in progressive web apps can easily be found by search engines but a content-centric native app like StackOverflow won't show among app store search results for content that it does offer access to, such as "pwa vs. native". This is a problem for communities like Reddit, which can't expose their numerous sub-communities to the app store as individual "apps".
linkability - any page/screen can have a direct link, which can be shared easily
bookmarkability - save that link to access an app's view directly
always fresh - no need to go through the app stores to push updates
universal access - not subject by app stores sometimes arbitrary policies or (unintended) geographic restrictions
large data savings, extremely important in emerging markets with expensive and/or slow Internet access. For example, e-commerce website Konga cut data usage by 92% for the first load by migrating to a PWA.
low friction of distribution - if your progressive web app is online, it's already accessible for Android (and other mobile) users.
65.5% of US smartphone users don't download any new apps each month
PWAs eliminate the need to go to the app store, search for the app, click Install, wait for the download, then open the app. Each of these steps loses 20% of the potential users.
Final note: PWAs run, with the same codebase, on the desktop as well as most mobile devices. On desktop environments (ChromeOS, and later Mac and Windows), they're launched in the same way as other apps, and run in a regular app window (no browser tab).

The main advantage for native applications is that they can access all native APIs a platform could offer (contacts, camera flash, SMS, telephony, network, bluetooth, sensors, raw sockets...) while a progressive web application can not (yet) as they are constrained by the Standard Web capabilities.
The goal for progressive web applications is to expand these capabilities to cover the most critical cases. In this mood, take a look at Progressive Web Apps: Escaping Tabs Without Loosing Our Soul where you can find a list of what a progressive web application should offer:
Responsive: to fit any form factor
Connectivity independent: Progressively-enhanced with Service Workers to let them work offline
App-like-interactions: Adopt a Shell + Content application model to create appy navigations & interactions
Fresh: Transparently always up-to-date thanks to the Service Worker update process
Safe: Served via TLS (a Service Worker requirement) to prevent snooping
Discoverable: Are identifiable as “applications” thanks to W3C Manifests and Service Worker registration scope allowing search engines to find them
Re-engageable: Can access the re-engagement UIs of the OS; e.g. Push Notifications
Installable: to the home screen through browser-provided prompts, allowing users to “keep” apps they find most useful without the hassle of an app store
Linkable: meaning they’re zero-friction, zero-install, and easy to share. The social power of URLs matters.
From these points, linkable was one of the first characteristics imported by native applications from the Open Web in the form of mobile deep linking.
But special mention deserve the combo fresh + installable as it represents one of the main advantages of the Web as a platform over the native alternatives. Here installable means that it appears in your home screen. It does not mean you require to pass downloading and installation stages. You open a URL or discover a service while browsing and it's done: it appears in your home screen.
Fresh refers to how a regular web works, offering an instant load and seamless updates. You are not asked for installing an update from the web of YouTube, it is deployed and you consumes it the next time you visit it.
I'm not talking about the benefits of the remaining points because you were asking for the differences and, for instance, re-engagement is something native applications already have via push services and notifications and now web applications have caught up.
Other related and key question is about which platform is more suitable for your needs. If you are not accessing special hardware capabilities, the Web should be enough and choosing the web you are free from the marketplaces, proprietary ecosystems and by the way, you can ensure certain grade of ubiquity and interoperability.
As final notes, I recommend you to browse www.flipkart.com from a mobile with Chrome. It's pretty awesome: no bugs, smooth navigation, app-like feeling. Go offline and it will continue working. A truly real world example of that post. Add the app to home screen and next time you open it, the experience is even better.
You can take a look at Firefox OS as well as an example of bringing more platform APIs to the Standard Web (with more or less success).

Cross mobile browser testing

What is the best way to test my website across various mobile browsers AND various versions of each of those browsers.
Additional Info:
Most of the online cross browser testing support wide range of desktop browser testing, and quite a range of mobile devices. But they don't seem to offer various versions of mobile browsers on those devices.
This similar question is quite old and it is surprising that in spite of the proliferation of mobile devices and focus on responsive designs, testing services for mobile is not catching up.
Major mobile browsers I would like to target : various mobile versions of Safari, Chrome, Firefox, Opera, Dolphin, UC Web etc
Just wanted to note this and this good alternative to online testing services for desktop browsers. Maybe something similar exists for mobile browsers too?

I'll suggest that both Opera's "device mode" is a really good for a first crack. But nothing beats actual device testing. I have found the odd case where Chrome's iPhone mode renders something different than what the actual phone does, but I would say it is about 90%. And the fact that it is so much easier to tweak code, and refresh using Chrome on the desktop rather than tweak, and refresh on phone, that I tolerate the 10% difference as long as I can. Then I just verify on an actual device after I am done with Chome's device mode.
I have not used Opera's device mode, but have heard it is good too.

There is a tool called as https://www.browserling.com/ which can be used for Desktop and Mobile testing(Android)

I don't think there is one way of doing cross browser testing across various mobile browsers and versions. It all boils down to what you want to do?
It is impossible to cover ALL browser combinations and versions. So my suggestion based on experience would be-
If you have too many combinations in mind, use a combinatorial tool (pairwise testing) from here - http://www.pairwise.org/tools.asp and reduce the number of permutations to get the best coverage.
Then go to Android and Apple website to see what the most commonly used phones and versions in the US, Europe and Asia region are based on where your customers are located. They have all these stats publicly available on their website
If you have google analytics see what browsers, versions and phones your users most commonly use to access your website
Now, you will have a list of devices and browser versions which is more focused.
Check what budget you have to invest in cross browser testing. Based on that I would recommend buying at least a couple of phones and tablets based on the usage statistics you got in the first 3 steps. Then, you can choose from a number of cross browser testing tools/services like
BrowserStack
Amazon Devices Farm
Saucelabs
Now atleast you have a more scientific way of doing cross browser testing :-)

confusion of all the W3C specifications and implementations of different browsers

I got really confused of all the W3C specifications and implementations of different browsers.
I have a list questions:
I found this page from W3C's website: http://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html
And I found this page from apple's website: http://developer.apple.com/library/safari/#documentation/UserExperience/Reference/TouchEventClassReference/TouchEvent/TouchEvent.html#//apple_ref/doc/uid/TP40009358
They are talking basically the same thing.
So my question is : did apple published all the multi-touch apis first then W3C followed apple to make all the specifications? or did W3C published the specifications first then apple followed the specifications to make a new version of Safari?
2.Is the Touch Events Specification a part of HTML5 specification?
3.If I write a web page that uses multi-touch to interact with users, can the users be able to use this web page in IPad, Android devices and Windows Phone 7(Mango)?
Or do I have to write different code for each different platform?
Thanks

The Touch Events Specification is based on events cloned from Apple Safari's implementation, although it adds significantly to it. It is not technically part of HTML5. The other platforms have also copied Safari's touch events. It should be possible to write code to the original Apple Safari reference documentation and have it work on iPad and Android. I don't know about Windows Phone 7 (Mango).

Mobile development recommendation

I want to start develop mobile applications and sell it. There are many mobile platforms for which I can begin develop: Windows Mobile , Android, Iphone, Linux based Devices.
I want to find out from people who has such experience which platform more comfortable and more profitable for me to use.

There is no general advice on this.
The recommendation clearly depends on your experience and several other factors. What programming languages do you know? What kind of applications do you want to develop? Do you want to take the risk that your software isn't even put in the corresponding app-store (see apple)?
You have to take several things into consideration. I'll try to make a short overview:
Android:
needs Android SDK
Java as programming language
free marketplace (i.e. no prior control whether your app comes in)
develop on any system you want to
open plattform
furhter information
iPhone
needs iPhone SDK
Objective-C as programming language
prior evalutation of your app before storing it in the app-store
you need to have a mac in order to develop for iPhone
closed plattform
further information
Windows Mobile
developing with .Net-Framework
don't know a lot more about it, but further information can be found here
Other Linux-based devices
take a look at their specifications, they often have an own SDK
Also don't forget about Symbian for Nokia. They recently launched their OVI-Store. And oh, also Palm could become very interesting just after yesterday's news that HP bought it. It's also a nice plattform.
Which one of these is more profitable for you also depends on your skills. Good software will sell good, no matter which plattform you decide for. My recommendation clearly is: Take a look at the SDKs and the needed environments and then compare it with your skills. If you say, you have a good experience in Java development go ahead with android. If you want to do some mac-stuff choose the iPhone.
I'd say the markets with the highes potential clearly are the iPhone and Android markets. I don't know, how Palm will develop now but there could be a big potential in it in half a year or a year.

Currently, the most lucrative platform is the iPhone. The Android is not even close yet. The number #1 selling game on Android is Robo Defense, its entry in the Market says 50,000 to 250,000 downloads, and its price is $2.99. Assuming the price has been constant, that means the developer has roughly made between $100,000 and $500,000 (after the 30% commission has been taken out). And yet, I have developer friends on the iPhone that have made way more money than that, and those friends are not even close to have the best selling apps on the iPhone in their own category.
Part of the problem is the number of handsets out there: according to Gartner, the number of Android handsets won't overtake iPhone handsets till 2012. The second problem is conversion rates: according to Admob, Android users are only worth 60% of the iPhone users in terms of converting from free lite version applications to paid applications (supposedly, Admob has compared identical apps on both Marketplaces).
That conversion rate is believed to be attributed to two factors: the type of users Android has, and the fact that Android currently only uses Google Checkout for its Market transactions (when in fact, it probably should use Pay Pal, not Google Checkout). But that too, should change soon. With the Evvo (from Sprint) coming out, Android will be a great phone, and with it, it will start attracting some of the very top high end users. Also, the Android Market is starting to accept transactions using carriers as go-betweens, so that should help remove some of the steps that it takes an Android user from buying an app (at least, I hope that it will).
And do notice that I didn't even mention the Ovi store from Nokia. The Nokia sdks are still as fragmented as ever. The Ovi store is currently a mess. Its three-star rating system is useless. All apps average to two stars. They don't allow you to upload screenshots. And the Ovi store is so expensive to upload an app to, $50 for Ovi + $150 in certificate signing fees, so it doesn't encourage new developers to even try it out.
Also, I didn't mention Microsoft. Microsoft is a bit of wild card right now. I can't say much about it, except that LG who was supposed to have more Windows Mobile phones than anything else now has more Android Mobile phones than anything else. So Microsoft better get their ass into gear if they'd like to stay competitive in the Mobile arena.

I would recommend Android as it's a growing market. Android development is well documented and newbie-friendly.
You may find these threads useful too:
What mobile platform should I start learning?
https://stackoverflow.com/questions/598252/most-promising-mobile-platforms
Getting Started With Mobile Development

You didn't mention webOS in your original question, but it's worth a look. Has an open development model, like Android, but is based on HTML and JavaScript, so might be easier to get started with if you have experience in Web development.
Here's the Palm developer website