The essential news about content management systems and mobile technology.
Powered by Joocial & JoomGap.

Getting your Ionic apps updated for iOS 11 is easy. There are a few things you need to do and some steps are different depending on whether you’re using UIWebView or WKWebView.

Note: if you don’t push a new build then your apps will work the same as they always have. These changes are required for apps doing updates for iOS 11 using Xcode 9.

ionic-angular nightly

The latest nightly of ionic-angular introduces compatibility for the iPhone X to make sure that your app looks great on this new device. To install the latest nightly run 3.6.1-201709212234. These fixes for the iPhone X will also be in the next stable release of ionic-angular so no fear in updating when it comes out.

Viewport Fit

The first change is to make sure you update your viewport meta tag in your index.html to add the viewport-fit=cover field. This ensures the webview takes up the full size of the screen. The new default is to stick the webview in the new safe regions which is not what you want for Ionic/Cordova apps:

<meta name="viewport" content="viewport-fit=cover, width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no">

This change has been made to the base starter project for Ionic 1.x and 2.x and above, so new projects are covered.

Learn more about new safe regions in iOS 11.


WKWebView will soon be the default for all Ionic apps running on iOS, before the release of the iPhone X. However, many are using it today.

This week we pushed a number of fixes to WKWebView fix padding issues, an issue with videos, and some smaller feature requests. Please update your plugin to the new version to try it.

If you aren’t using WKWebView yet, we suggest trying it today. We will be moving to make it the default given iPhone X and better support for safe regions. For installation instructions check out the readme here.

New Icon and Splash

Xcode needs a 1024×1024 sized icon for submission. ionic resources doesn’t yet generate this file, but you’ll need it for submission. We are working on adding this to the resources generator.

Additionally, to support iPhone X fullscreen, a new splashscreen image needs to be provided. For an existing project you will need to run npm install -g ionic to get the latest version of the cli, and then run ionic resources. This will generate the correct splashscreen image and reference it in your config.xml automatically for you. For new projects, you dont need to do anything, the correct setup is already built in.


There is currently a PR open to update the cordova statusbar plugin but it has not been merged yet. We are expecting this to be merged very soon, but in the meantime you can install the plugin with that PR automatically by running the following commands:

rm -rf platformsrm -rf pluginsionic cordova plugin add\#patch-1ionic cordova emulate ios

If you follow the above instructions and are having problems deploying to a simulator or device, open the platforms/ios/myapp.xcodeproject and hit the play button in the top left corner Xcode.

Report an issue

Notice anything weird or out of place? Please file an issue and reference iOS 11 and this blog post:

Read more

Voyager Live Demo

It has been over 2 weeks since the initial pre-order release of Voyager template. Now we have put together a little playground for you to have a spin on Voyager template.

Read more

EasySocial 2.1 Beta 2

We are getting there! The team is wrapping up the development for EasySocial 2.1, tirelessly fixing all reported bugs while still experimenting several new ideas on the fly. This will be the final beta before we go into an RC release.

Read more

Critical Update For PayPlans 3.6.3
We just released PayPlans 3.6.3 to address a possible security issue with regards to a vulnerability with IDOR exploits​.

Read more

Framework Churn: that breakneck pace of creation and abandonment that plagues the JavaScript community. Here one day, out the next. Hot today, obsolete in a year. Number one loved on the Hacker News frontpage, now number one hated on the Hacker News comments.

Framework Churn is something every one of us deals with in the JavaScript community. How do we know that big investment we’re making in Tool/Framework X is going to be relevant in a year, five years, twenty years? It’s at the point now that many are afraid to pick anything for fear it’ll be irrelevant long before the life of the product built with it.

At Ionic, we’ve seen churn first-hand. At first, Angular 1 seemed to be the end-all in JavaScript land, and we focused all of our energy on it. That period of relative simplicity didn’t last long, though, and soon there was a proliferation of new frameworks and tools that came and went. Suddenly, choosing Ionic meant betting on a frontend framework in a world that couldn’t stick with one for more than a year.

It was exhausting, and like many, we knew we had to break out of the cycle.

What causes Framework Churn?

To finally solve Framework Churn, we need to understand what a modern frontend framework is and why it causes lock-in and subsequent violent churn as it fades from the developer toolbox.

At the core, a frontend framework provides a component model that specifies how custom elements work and how they interact with each other, along with tools for templating, component loading, and more. Some frameworks are more “batteries-included” and come with utilities such as routers and animations, and while these utilities make it harder to leave a framework, their potential for lock-in is emergent from the component model.

The component model becomes the language of the framework. It’s the way components expect to be initialized, created, updated, rendered, destroyed, and how they communicate with each other. Generally, components built in one framework will not work in another framework due to the systems the framework provides to make the components run.

Thus, Framework Churn is due to incompatible component models that create interfaces that can’t be interchanged, and exacerbated by the rapid pace of innovation and powerful marketing forces in the JavaScript ecosystem.

Ending Framework Churn

To end Framework Churn once and for all, we need a way to create components that speak a language every developer and framework can understand. A component language that can be standardized but is also compatible with existing framework component languages.

Thankfully, there’s an answer: Web Components. Web Components are a modern web API spec with native browser support already in Chrome and Safari (and iOS!), with native support behind a flag for Firefox. For browsers without native support, a very solid and small (12kb) polyfill makes it seamless to use components.

At the core of the Web Components spec is something called Custom Elements. A Custom Element is just what it sounds like: a custom HTML tag that runs JavaScript that you specify. No more need for Angular Directives, or React Components, etc. Custom Elements are the holy grail of custom components: natively supported custom JavaScript browser elements that work like any other HTML tag.

It just so happens that these Custom Elements are the key to ending Framework Churn.

What about Framework X?

The best part about Web Components is they work just like any other HTML tag. This means that they are compatible with all major frameworks (*).

For example, once Ionic 4 is ready, the new Ionic Web Components will work in Angular just as well as they will in Vue and React (*). One major benefit, is that they will also work without any framework at all, making it possible to use the components directly for rapid development and even for integration into existing jQuery codebases!

This means Ionic will continue to support Angular but will also be able to support any other framework, making Ionic future-proof and ending framework churn for the project.

  • Right now React core has some issues with web components that can be worked around. However, Preact fixes them and we hope this is a short-lived issue

Using Web Components Today

Web Components are ready to be used today, and require nothing more than some JavaScript and a browser. You can write Custom Elements today using APIs provided natively in the browser (and supported with a polyfill).

Chances are, though, you’re going to want features you’ve gotten to know and love from Frameworks, like templating, efficient DOM updates, reactive databinding, and more. Tools like Polymer, SkateJS, Svelte, and Stencil bring those features to Web Components but without the need for a heavy, prescriptive framework.

Shameless Plug: Stencil

That last project, Stencil, is a project we’ve created at Ionic that will be the foundation of Ionic 4 and beyond as we port all of the Ionic components to standards-compliant Web Components.

Stencil is a compiler that generates plain web components for you, but with many features and a syntax you expect out of traditional frameworks. Things like using TypeScript, Virtual DOM for fast rendering, optimized async rendering similar to React Fiber, JSX for easy templating/UI, reactive data binding, and more.

Stencil creates Web Components with framework features as if you wrote them in yourself, but in a way that adds minimal abstractions that feel more like “TypeScript with WebComponents” than a full-fledged framework.

Stencil is new; we only recently announced the project at the Polymer Summit (watch the talk here). However, as Stencil will be a big part of Ionic 4, we are dog fooding the project heavily and development is progressing rapidly.


We believe 2017 is the year that web developers finally start to use Web Components in larger numbers. It’s going to take some time to reach mainstream usage, but the benefits are real and native support is improving rapidly. In fact, we’re betting everything on it.

For businesses, Web Components provide much needed API stability that traditional frameworks have failed to provide. A component built with web-standard Web Components will work without modification for decades. Not only will it run, but developers will know how to maintain it because it’s the web standard. Such stability is unheard of in JavaScript land today.

For Ionic, Web Components mean that picking Ionic isn’t making a bet on Angular. Rather, it’s making a bet on the web and the shared language of Web Components. We want Ionic to be the “UI layer for the web” and the only way for us to achieve that is to move to standards that will work everywhere and be stable for decades.

The era of Framework churn is coming to an end, and now we can all go back to working on what makes our apps unique instead of spending precious time, energy, and money jumping to something new every year.

I’m sure that’s welcome news to many that are exhausted with JavaScript churn and ready to get back to work.

Read more

Meet Voyager Template

Many positive comments and messages came in after announcing the newly acquired PayPlans just a couple days ago. Thank you so much and we really appreciate awesome and supportive users like you behind our backs. It makes what we do worthwhile.

Read more

Vanilla Template

​In line with EasySocial 2.1 and Voyager development, the team also agreed to release our own in-house social template concurrently. We decided to call it, Vanilla. 

Read more