Our website is mobile ready and provides service to end uses. Someone has developed a wrapper application around the website and published on playstore. I checked the web request header from this wrapper application and from mobile browser and they are identical.
Is there any other way to differentiate if the request is from webview of native application or mobile browser?
Unfortunately for your case, a WebView is indistinguishable from the default mobile browser. So I believe that you have a legal problem here, not a technical one.
As #Daniel says, you may want to appeal to Google to have the app removed from the Play Store.
Since there seems to be some market out there for a native version, perhaps you should look at providing your own. If you provide some extra added value in a native app, there would be less incentive for someone else to wrap your web app.
you can according to User-Agent， of course, you can custom User-Agent
Related
I am currently investigating the possible to build a html webpage connecting cgi. Then, I use Phonegap to render the html pages into native apps. A few years ago, someone can release the app on the App market.
I have seen that app with pages including Webview cannot be published. So I would like to ask this possibility.
Of course any information about that would be very helpful!
Thanks for your help!
Your question is interesting because it is a problem that hybrid developers regularly face.
Normally on the side of Google there is no problem because the GooglePlayStore imposes very little, so it's fine for mobile applications.
On the Apple side it's more complicated because the concerns come from a series of points in the apple guidline.
https://developer.apple.com/app-store/review/guidelines/
The first point was added in 2009 and is still relevant:
Your app should include features, content, and UI that elevate it
beyond a repackaged website. [ … ]
This is understood as follows: Your application must not be a simple website but must have a minimum of functionality requiring the native, such as gps or photo taking.
Then in 2014
there was the integration into the iOS SDK of Webkit and the end of UIWebView which was used by Cordova.
In apps that run in iOS 8 and later, use the WKWebView class instead
of using UIWebView. Additionally, consider setting the WKPreferences
property javaScriptEnabled to false if you render files that are not
supposed to run JavaScript.
Cordova has made the necessary changes to continue to operate.
But the biggest problem is that the day Apple says stop, Webview is over, cordova can't do anything about it.
To sum up, today no worries on Google and Apple but the future is uncertain so if you are thinking about what technology it used, considered the native.
(I'm telling you this but I have more than 15 cordova applications in production on Google store and Apple store...)
Is there a way to simply open an other app in a cordova application and if the app is not installed, forward on the store. This request for ios, android and windows phone.
I am searching this on google but is not clear between intent, deeplinking, url scheme, ... And it look there is not complete solution...
How should i do it ?
Moreover, if we need the urlscheme or id of the other app, how can i exactly find it ?
Regards,
At the moment, there is no easy way to do this without the cooperation of other app.
Chrome Intents and Custom URL Schemes are two different methods to do deep linking. Two other terms you may come across are App Links and **Universal Links*.
Chrome Intents
Work within Google Chrome on both iOS and Android. A limited number of other apps (for example, Firefox) also support this approach. This is a custom — and unnecessarily complex, in my opinion — approach cooked up by the Chromium team at Google that basically specifies both app and fallback destination information inside the same request. However it relies on the source application to properly parse it, otherwise it will fail. In other words, not a good option for a complete solution.
Custom URL Schemes
Previously the de facto standard for deep linking. Unfortunately all good things must eventually come to an end, and Apple basically killed URL scheme deep linking in iOS 9.2. Long-term, this is probably good for the ecosystem because it solves a lot of problems that were starting to come up with scheme collisions, but it's still a headache for app developers in the short-term. There is no easy way to handle situations in which your app isn't installed, because attempting to open a custom URL scheme that isn't registered on a device will lead to an error page. URL schemes are still supported on Android. I'm not as familiar with the deep linking ecosystem on Windows Phone because it is so small, but I believe it is also based around custom URL schemes.
Universal Links & App Links
Essentially the same technology: Universal Links is the iOS implementation, and App Links is the Android version. These work by creating a verified connection between your normal website URLs and your app. If your app is installed, the OS will intercept the website request and instead open your app. This is much easier to authenticate than a URL scheme, because only one person can control and verify a given domain, and a website URL is an automatic fallback destination if your app isn't installed. However, this can be a big limitation if you don't have a corresponding website. These are also not supported everywhere yet.
To get a comprehensive approach, you need to handle all of these standards along with several others, and then be prepared to handle a huge number of complicated edge cases. A Cordova app is even worse, because you'll need to deal with edge cases on both iOS and Android within the same app. To open another app and reliably fall back to the app store when it isn't installed, you need that other app to do all of the above and then provide you with specs for their implementation — not an easy task.
At Branch.io (full disclosure: I'm obviously on the team) we provide all of the above as a free service, and actually facilitated an app-to-app collaboration exactly like this between Yummly and Instacart. You can read about the specs in this case study.
So we're developing using NodeJS, angular, html5 and all that jazz. But we want to have a more native app experience. So we're going to use ionic. However, instead of building the app as a local app and pulling in the data we want, they've decided to just build a web app and point the native app to the wep apps url.
So it's a glorified browser that looks like a native app.
Do we lose the ability to harness the devices hardware? Such as hardware acceleration and access to the devices tools like the camera. If you could provide a link to an article detailing the cons of this approach, that would be fantastic.
#Chauncey, If you are using phonegap, you are a liberty to use any of the hardware devices you have permission to use, as long as you have the plugins loaded.
However, both Google Play and Apple iTunes frown on having Apps that are just glorified browser. There is another misconception. Phonegap Apps can have as much look and feel as native Apps. With Ionic and others, those things are done for you, and hidden from you. So with Ionic, your native look and feel is only as good as Ionic gives you.
Oh, and your request for for links to articles lgtfy --Jesse
Pointing on an external URL is not a good idea.
A mobile app should have all images/css/scripts on device in order to shrink network access.
That you want to do will be really slow and does not offer a good user experience. In this way, your application can be rejected by Apple when you will submit it to AppStore.
Cordova/Phonegap needs to run some scripts at start and then raises events. You can't use device specific hardware before that. And if you redirect the main frame to an URL, you will overwrite these scripts ...
My web application run's nicely on every smartphone. An additional native iOS/Android app would have the advantage of being available over the app stores and more visible to users. But I find it unnecessary work to do everything from scratch in all the development environments.
Instead I could make an app that just implements a web browser and just shows the website. Does someone know if this is allowed by Apple/Google at all? I have heard that at least Microsoft seems to have nothing against it in their Windows Phone market.
Thanks
# quape, apple will reject the application made with the idea you are thinking so it will be of no use to move in this direction.
Apple will simply reject the application for lack of functionality...
I have absolutely no idea about Google's policy on that question.
I want to deploy an Android app in a similar fashion as the Wireless, Over-The-Air method that exists for iOS devices. That is, setup a web page and the user clicks a link from his device that includes the manifest (xml) file, containing information on how to download the app. This works well on iOS devices, and I thought Android may have something similar.
How do I go about this?
Thank you for any help.
Please the comments above. Have the correct MIME settings, link to the apk, and make sure unknown sources is checked on the device to allow non-market apps.
Since you seem to imply an app market / store is not involved in the iOS case, it seems you might be talking about an offline-cacheable "web app" rather than a native iOS application.
The android equivalent is: on devices where the offline web app capability exists, just visit the same web page (referencing an html5 manifest with appropriate mime type, etc) you are using for iOS. Perhaps you will ultimately end up with platform-specific refinements, but the basic idea is portable.
Or perhaps you just mean that a desktop/laptop need not be used to open obtain the app. On Android, that has been the case since day 1 - the primary market client is on the device, with over-the-air install. You can send an android device to the market with a market:// url. The ability to trigger an install from a web browser running on something other than the device is a more recent and still secondary capability on android.
Finally, android does offer the ability to side load native applications, something that has no iOS equivalent outside of jailbreaking or having a developer account. Most of the responses seem to concentrate on this, but it's not clear if that is what you are actually asking for.