When developing mobile apps, it’s very common that we have to connect to web services or APIs which may be secure (https) but are still under development, so its SSL certificate is not valid or self-signed.

This would happen unless you want to spend a hundred bucks on a wildcard certificate for development environments.

For cases like the mentioned above it’s useful to be able to ignore errors generated by invalid certificates, so we can test the app, install it on any device, etc.

In order to get rid of this problem, the process changes depending on the platform we’re targeting.

iOS (Objective-C / Swift / Cordova)

iOS will always complain about invalid certificates, either in debug or release mode. To avoid this you should place the following code at the end of the AppDelegate.m file.

@implementation NSURLRequest(DataController)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
return YES;
For Cordova users this file is placed in

Thanks to @machadogj for this one!

Android (Cordova specific)

In Android the history is different. It will allow you to make requests to services with invalid certificates, but only if the app is compiled in build mode. On the other hand, when you would build the app in release mode (ie: to send the APK to a co-worker or stuff like that), the Cordova Web View, which is where the HTML + CSS + JS you wrote runs, will not allow you to make “insecure” requests. Once again, to avoid this you should modify a platform file. In this case the file will be CordovaWebViewClient.java

You would need to modify a method in the mentioned filed, like this:

public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
final String packageName = this.cordova.getActivity().getPackageName();
final PackageManager pm = this.cordova.getActivity().getPackageManager();

ApplicationInfo appInfo;
try {
appInfo = pm.getApplicationInfo(packageName, PackageManager.GET_META_DATA);
if ((appInfo.flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0) {
// debug = true
} else {
// debug = false
// super.onReceivedSslError(view, handler, error);
// —->
// <—-
} catch (NameNotFoundException e) {
// When it doubt, lock it out!
super.onReceivedSslError(view, handler, error);
This file is placed in (Cordova v4 and below)


In newer versions of Cordova (v5 and later) the file is now placed in

That’s all.

One thing I’d like to point at is that you should not use these solutions for production apps. This is just to test them or share them with co-workers.

If you have any comment feel free to drop me a line through the comments below.

Thanks for reading!

link: http://ivancevich.me/articles/ignoring-invalid-ssl-certificates-on-cordova-android-ios/

You probably already know about HTML5‘s <input type="number">. Which if supported by a browser displays a form input optimized for inputting numbers. Whether that means an up/down spinner or an optimized keyboard.

However iOS’ standard behavior for the number input isn’t that ideal. By default iOS will display a standard keyboard slightly modified with a row of numbers at the  top. This isn’t ideal as you don’t need the alphabetic keys and iOS already has a full numeric keypad it could use for the input instead. For reference, other mobile OS such as Android already display their numeric keypad when focusing a number input.

A html5doctor article article went over this, pointed out a trick by Chris Coyier using <input type="text" pattern="[0-9]*"> in which the pattern forces iOS to use it’s numeric keypad, and also mentioned HTML5’s inputmode.

The unfortunate issue with Chris’ technique as-is is the number input is no longer a number input. And the practice of depending on raw string matches to specific regexps in pattern="" to trigger UI changes is non-standard. So while the trick nicely displays a numeric keypad on iOS the input no longer has the spinner interface on desktop browsers and other mobile devices such as Android no longer use their numeric keyboards.

Wondering if this technique could be applied in a meaningful way to a number input without ruining the experience for users with other devices I started experimenting and came up with another technique.

<input type="number" min="0" inputmode="numeric" pattern="[0-9]*" 
title="Non-negative integral number">

I found out that the technique of adding pattern="[0-9]*" to an input to trigger the keypad in iOS works even when the input is type="number" so both type="number" and pattern are used. inputmode="numeric" was added for forward compatibility as unlike pattern="[0-9]*" is is the standard way to declare that a numeric mode of user input should be used for a form field.

I also realized that the use of pattern triggers the browser’s native form validation. Which in the case of browsers – like Firefox – which have implemented form validation but not type="number" results in the browser displaying a cryptic “Please match the requested format.” message when the user attempts to submit the form and the number input contains some non-numeric characters. So a title was added which is the standard way to note what type of input is expected within the form field and causes that text to be used inside the error message to describe what the format is.

pattern is ignored by most browsers that implement type="number" but is used by browsers that implement form validation but not the number input type such as Firefox. The pattern [0-9]* which is the only one that iOS will accept to trigger the keypad only permits the input of non-negative integral numbers. So I added min="0" to force browsers implementing type="number" from accepting negative numbers which other browsers would reject.

This technique works in all browsers; Displaying numeric keypads on iOS as well as Android and any other mobile device that’s implemented type="number" or inputmode="numeric" handling. Displaying the numeric spinner on browsers where it’s implemented such as Chrome and Opera. And displaying user friendly form validation on browsers like Firefox that have validation but no number input.

If you have an iOS device you can try out the demo which is depicted by figure 1 and figure 2.

This technique technically does not validate. As the spec defines inputmode and pattern as attributes on textual inputs but not on type="number". However the semantic meaning of these attributes is known and matches the semantic meaning of type="number". So while it is technically invalid the technique is safe to use and the better user experience is worth any error messages in a validator.



link: http://danielfriesen.name/blog/2013/09/19/input-type-number-and-ios-numeric-keypad/



<meta http-equiv=“Content-Type” content=“text/html; charset=utf-8” />