We’re thrilled to have recently announced the release of Ionic’s fourth major version, and its ability to work across all frameworks (or with no framework at all).

We’ve been overwhelmed with the positive feedback, and so far 4.0 has exceeded our expectations of what’s been possible with a rewrite. So, with the official Ionic Framework 4.0.0 release behind us, I figured now would be a great time to lay out our roadmap and immediate plans for next steps—a vision, if you will, for where we hope to take Ionic Framework in the near future…

Improved Desktop Support

As you might be aware, we’ve always had a ‘mobile-first’ mentality, focusing on providing a mobile and tablet friendly user interface and experience—something that, traditionally, has been difficult to pull off with only the web. However, as more developers and organizations have adopted Ionic as their UI framework of choice, the request for improved desktop support has been ever increasing.

As a result, our next big area of focus will gravitate towards improving the desktop experience with Ionic, while continuing to ensure its mobile-friendliness. Our first step will be to improve Ionic’s media queries by ensuring components adjust as expected when the browser’s real estate space expands or changes. Beyond that, we’ll ensure individual components adjust accordingly.

For example, the current ion-datetime component acts as expected on a mobile device, however, it looks a bit out of place on desktop. What’s great is now that Ionic is able to lazy-load components, on-demand, we’ll be able to instead load a different calendar component that is expected for a desktop UI. Other plans involve vertical range sliders and investigating if we should provide another mode following the desktop macOS patterns. Please feel free to submit, or add to any feature requests for desktop UI components that we should look into next.

Framework Integrations

With the initial 4.0.0 release, we also shipped @ionic/angular, which is based on top of the framework agnostic @ionic/core. The next step is to get both Ionic React and Vue up to the same quality as the Angular release. Throughout their beta versions we’ll keep them at 0.x.x, but once they’re ready for the official major release, we’ll then line them up with the same release version as @ionic/core.

Luckily, a vast majority of the work within Ionic is already available to each integration without any code duplication, and the framework integration itself is a minimal wrapper. In most cases, if a bug is found within a certain component, then the fix is immediately available to each integration. Same concept goes for any new features.

Another upcoming improvement is packaging up each Ionic component as a stand-alone, self-contained web component. By default, each component has the added feature to allow them to be lazy-loaded. But, we also want to ensure each component can act as a traditional web component, which allows Ionic to be consumed in any way possible.

Server-Side Rendering (SSR) and Prerendering

One enhancement that can drastically improve startup performance is server-side rendering, which renders components to static HTML on the server, or prerendered during a build step. For more information about the “why”, plus benefits and trade-offs, please see Rendering on the Web. Most frameworks provide a way of rendering their components without a browser, and Angular Universal is Angular’s way.

Upcoming versions of Ionic will provide methods to “hydrate” themselves on the server. In the case of Ionic Angular, this means we’ll be providing the IonicServerModule which can be imported within Angular Universal builds. The exciting part here is that the core server-side hydration code is reusable in each framework, and only a minimal wrapper is used at the final step. Expect to hear more about this soon!

Custom Web Animations

Animations within a web browser have come a long way since Ionic 1 was first released. In previous versions, even the game-changing requestAnimationFrame API wasn’t available on many mobile devices, resulting in the janky animations from the fallback use of setTimeout.

Ionic 2 and 3 saw many improvements due to our internal animation library, which actually continues to power 4.0’s page transitions. However, this animation library has been intentionally kept as an internal tool knowing that we’ll soon be able to migrate to the standardized Web Animations API.

By following a web standard, it’ll make it easier for developers and third-party libraries to provide custom animations for Ionic. Making this transition has long been in the back of our minds, and we hope to start providing even more animation options, soon.

Improved Stability and Predictable Releases

With the core team focused on refactoring Ionic and shipping 4.0, it was often difficult to triage issues that came in. Now that the API has stabilized, and the refactoring is behind us, we’ll be able to dedicate more time to handling issues reported by the community. This effort can already be seen from our cadence of patch releases since 4.0.0 was released. At the top of our list, right now, are page transitions, navigation fixes, and keyboard issues.

Patch releases, meaning any release that fixes existing features, are scheduled to ship every two weeks. To see which issues we’re currently working on, or what is next in the queue, please see our Github Project Board. Major releases will not be released any sooner than six-months from the last major release.

Let’s Build Some Apps!

Obviously, we’re pretty excited about Ionic Framework and what the future holds for Ionic developers! And, we hope this update gave you a little glimpse into all the next steps to come. We are also beyond grateful (THANK YOU!👏🏽👏🏽) for the Ionic community and their support throughout this process.

As always, we’re open to your feedback so please feel free to hit us up on Github, Slack, or the community forum.

Happy building with Ionic Framework 4.0! 🎉

Read more

Today, we’re excited to announce that Ionic React is now available in beta! Take a read below to understand more about this release and how to get started building with Ionic and React.

A Quick History

If you are familiar with Ionic Framework, you more than likely associate it with Angular. Historically, your assumption would be correct, as Ionic and Angular have been exclusively paired for a long time. However, with the recent release of Ionic Framework 4.0 this has changed: Now, Ionic’s core is able to adapt and expand to support many different frameworks. In previous posts, we mentioned that Vue and React were in the works…

Finally, however, we’re thrilled to share that the @ionic/react beta is here! 🎉

What is Ionic Framework?

If you’re already using React, but haven’t done so with Ionic, you might be wondering: What is the Ionic Framework and why should I care?

Well, let’s take a step back and just say, “Hello, we’re Ionic!” We’re about 5 million apps (and users) strong, with companies like Nationwide, Marketwatch, and Sworkit using our code.

We’re best known for our popular open source Framework, which at its core is a collection of UI components for building high-quality, cross-platform hybrid apps. All of these components are built with HTML, CSS, and JavaScript and can be easily deployed natively to iOS and Android devices, to desktop with Electron, or to the web as a progressive web app (PWA).

Why does this matter? Because the web is awesome and only getting better! Building with web technologies allows developers to leverage their existing skills for native development, while also depending on the stability of the web. Meaning, you don’t have to learn any special new tools, use a subset of CSS, or rewrite portions of your app when building with Ionic—It just works across multiple platforms, all using one codebase.

And, because the Ionic Framework is focused on the Component/UI layer, you can still keep your framework’s build tools and CLI. Our main goal is to care about how your apps look and behave, not how they’re built. In the past, Ionic Framework has been built only supporting Angular. While we still love and support Angular, we’re also opening up to other tools in the front-end ecosystem. This is why we’re excited to share the details about @ionic/react.

How to Get Started with React & Ionic?

Getting started is quite simple. Begin first with create-react-app, because we want you to use Ionic with React in the most familiar way. We also recommend using TypeScript in your app, something we recently wrote about on our blog if you need tips. While this is not required, we mention it because Ionic React ships with TypeScript type definitions, and it makes for an excellent developer experience.

 npx create-react-app my-ionic-app --typescript
 cd my-ionic-app

Ionic provides components to help with navigation like tabs and stack-based navigation. Right now, we support react-router so we will need to install it as a dependency along with @ionic/react.

npm install @ionic/react react-router react-router-dom @types/react-router @types/react-router-dom

Fire up your favorite code editor and open up App.tsx. Then replace the contents of the file with:

import React, { Component } from 'react';
import '@ionic/core/css/core.css';
import '@ionic/core/css/ionic.bundle.css';
import {
} from '@ionic/react';

class App extends Component {
  render() {
    return (
              <IonCardSubtitle>Welcome to Ionic</IonCardSubtitle>
              <IonCardTitle>Running on React</IonCardTitle>

export default App;

Run npm run start and you got yourself an Ionic React app!

Alright, that is pretty much it. From here, you can use Ionic Components as you wish. Now, let’s dive into the specifics of what components are available from Ionic.

What Does Ionic React Include?

We ship around 70 components with Ionic React. These components should cover the majority of use cases for building a mobile application—Including buttons, cards, menus, tabs, alerts, modals, and so much more. Next, let’s take a look at a few example components to gain a better understanding of what to expect when building with Ionic.


Button provides a clickable element that can be used in forms or anywhere that needs standard button functionality. They can also display text, icons, or both. Additionally, buttons can be styled with several attributes to look a specific way.

<IonButton onClick={this.props.dismissModal}>Cancel</IonButton>


Cards are just a standard piece of UI that serves as an entry point to more detailed information. A card can be a single component, but it is often made up of some header, title, subtitle, and content.

    Card Heading
    This is some card content.


A Modal is a dialog that appears on top of the app’s content and must be dismissed by the app before an interaction can resume. It is useful as a select component when there are a lot of options to choose from, or when filtering items in a list, as well as anytime you need the users’ input before you can continue.

  onDidDismiss={() => this.setState(() => ({ showModal: false}))}
  Some content to display in the modal.

Ionic & the React Ecosystem

Additionally, some people might be wondering how Ionic fits into the overall React ecosystem.

React developers have long used React Native to make native apps for iOS and Android. We think React Native is a good approach for native app development, but we have always believed in the web platform and think React developers will find many advantages in creating hybrid mobile, desktop, and progressive web apps with Ionic and React. We even see opportunities in using React Native and Ionic together. Stayed tuned for more info on that coming soon.

Next Steps for Ionic & React

It is pretty early for @ionic/react and there’s a lot more to test before we recommend it for production, though we’re happy to finally have this available for our community to try!

If you would like to see an example application that shows usage and provides more context around the best way to leverage each component, please take a look at our demo application built with @ionic/react, here.

To see the demo running live, click here.

We’ve always said that Ionic’s biggest asset is our large, passionate community, and now we need your feedback.

If you want to give Ionic a try in your next React app, please do so—we’d love to know how it goes! You can reach out to us on Github with your thoughts and updates, just make sure you mention React somewhere in the issue text when you do. Our issue bot will make sure it gets to the right people.

Now that you have more information about how to use ‘@ionic/react’, we can’t wait to see what you create. Happy building!

Read more

A few months ago, we wrote about the release of Chrome 70, its slew of new features, and what this update meant for the future progressive web apps (PWAs).

To quickly recap, Chrome 70’s release allowed PWAs to be installed on a user’s device via the browser, much like a native app with new features that improved the user experience. Given that Chrome holds the majority of browser market share, it was an exciting move by a major industry player to add more capabilities that helped inch PWAs closer to the mainstream.

Cut to earlier this month, when Chrome’s latest PWA update dropped in Chrome 72, which added a new feature that opened up the Google Play Store to PWAs as first-class citizens. The news initially broke through a developer’s Medium post, with Google following up a few days later when it published more information about using Trusted Web Activities (TWAs): The newly released feature that allows PWAs to be hosted in its Play Store.

Put simply, a TWA allows Chrome to run fullscreen in an app—with no visible browser toolbar or Chrome UI—all within a native Android package (APK).

Additionally, what’s great about TWAs is that they give access to features unique to Chrome, like web push notifications, background sync, and form autofill (e.g. if your contact info is already stored in Chrome, a TWA can automatically pull that information into your PWA).

While TWAs have some benefits, there are still some barriers ahead as well as complexity in adding a PWA to the Play store. At some point, one would hope submitting a PWA could be as simple as adding its URL to the store and publishing. However, this is currently not the case and publishing an app takes more than a quick, two-step process. Instead, it requires a lot of manual work to be done and knowledge of some native code.

More than that, according to a Chromium blog post published about TWAs, in order for a PWA to be accepted into the store a few requirements must be upheld:

  • Your app must meet all PWA installability criteria
  • Your app must achieve, at minimum, a performance score of 80/100 in Lighthouse
  • All content in the TWA must comply with Play store policy

You might be asking: But isn’t the point of a PWA to avoid app stores altogether? Isn’t one of the PWA benefits the ability to publish apps and deploy updates without going through an approval process?

Well, for some, the answer isn’t so simple.

In one of our recent posts, Native or PWA? How to Choose the Right Approach for Mobile App Development, we explore the pros and cons of these two approaches when choosing how to build a mobile app. And, while a lot of companies appreciate PWAs for their speed, performance, discoverability (you can search PWAs in a browser and can link directly to a URL), and more, there’s still the fact that until PWAs are universally available in app stores, you miss out on some of a store’s benefits.

For companies that are well-established in an app store, want to take advantage of a store’s infrastructure, or have users who are more familiar with the app store experience, there is a benefit to making PWAs available in-store. We wrote about a few in the above Native or PWA? post and have included some additional benefits from the Medium post we referenced earlier:

  • Easier monetization of apps in the store
  • Promotion of apps in featured sections of the store
  • Improved measurement and error reporting for apps
  • Ability to offer app shortcuts and deeper integrations with the OS
  • Access to background services for more native functionality
  • A custom home screen widget, plus the ability to reinstall after a hard reset

These are just a few of the benefits that companies can leverage when they seek out publishing to an app store.

Alright, so now that you have some information about this new update, you’re probably wondering if it’s a big deal or not. Is this as exciting as it sounds or is there still a long way to go for PWAs?

Well, it depends on who you ask!

Read on below for perspectives from a few of our thought-leaders at Ionic and form your own conclusions.

Hot Takes: PWAs in Play Store

Ely Lucas
, Ionic Developer Advocate

“I’m really excited for the future of PWAs in the Google Play Store. This move just adds validation that PWAs are an effective platform for developers to build their mobile solutions on, giving them the most reach (the web runs everywhere, after all) to engage their intended audience. Chrome’s Trusted Web Activities seem like a great approach to securely deliver PWAs through the Play Store. Over time, I expect the TWAs tooling and capabilities to only get better.”

Max Lynch
, CEO at Ionic

“I think this update is a step in the right direction, but still misses the mark a bit. For the general developer, TWAs do provide a new functionality that helps get a PWA into the Play Store. But, when you dig a little deeper, it’s still quite complicated and requires a lot more manual work/native knowledge than you’d want to do to get a PWA packaged and published. In my opinion, there are better solutions out there in the interim that can help achieve the same result in a less convoluted way—using standard web technologies, which are already ideal for building a PWA. For example, at least for Ionic developers, TWAs are kind of a half-measure, because with our technology you can build a full native app that is published to a store and in a PWA, which gives you the best of both worlds. The reality is, despite the existence of TWAs being helpful, they still provide a pretty constrained environment for building. So, before jumping onto this new feature, especially if you’re using Ionic, it’s worth evaluating, first, whether to invest in a TWA at all or just use a technology, like Ionic, to build a native app (and/or PWA) instead. All that said, it’s exciting to see Google continue to add to the narrative for PWAs, and it will be interesting to see how this plays out as more capabilities are added.”

Mike Hartington
, Developer Advocate at Ionic

“I try to be optimistic about TWA’s and their capabilities. Currently, though, it does seem like it’s a bit of a compromise for people who want to make PWAs and remove app stores from their perspective. There are some good parts, like app/PWA verification through Digital Asset Links, but there also seem to be some limitations. One aspect that stands out, to me, is any payment processing needs to be done through the Google Plays In-App Purchasing System, versus any payment setup developers want or prefer. Understandable, at this point, but still disappointing. That said, I do look forward though to the possibilities that could come from this and how it can affect installable PWAs from the browser.”

No matter which perspective resonated with you, it’s safe to say that the Chrome 72 update has done some good in furthering the vision for PWAs. Yes, there is still a need for increased functionality and better tooling to streamline the process of adding PWAs to the store, but this marks an important step in the viability for PWAs, long-term.

Additionally, there are already some big brands already taking advantage of publishing their PWAs to the Play store including Instagram Lite, Google Maps Go, and Twitter Lite, so check them out for some great examples of what this implementation looks like.

With the evolution of the web, plus more updates to come from Google, and hopefully other heavy-hitters in the industry, it’s likely we’ll see it become even easier to implement PWAs both within and outside app stores. We’ll be sure to follow up with our thoughts on future updates.

Looking for more information on PWAs or want to get started with one? Check out our resource page dedicated to progressive web apps, with explanations, use cases, and more.

Read more

This post is contributed by Kevin Ports, designer and front-end developer at Ionic. He’s passionate about pixels, code, and the space in between.

If you’re building a handful of apps in a startup or small business, delivering a consistent user experience across teams and projects is relatively easy. But if you represent a global corporation with hundreds of developers and designers distributed throughout the world, enforcing a set of design standards can get messy. Having a Design System can help.

A Design System is a centralized library of components that can be shared across teams and projects to simplify design and development while ensuring consistent brand experiences, at scale. In some cases, a Design System is nothing more than a collection of visual design specs. But for the purposes of this post, we’re going to talk about Design Systems as a collection of real-code components that front-end developers drop in their projects like Lego blocks, to quickly build new user experiences without having to worry about the core design of each component.

The HubSpot team, a pioneer in Design Systems, explains why this is valuable:

“That’s the beauty of building a design system. By deciding on a detail once, you free up your entire product development team to focus on solving actual customer problems.”

Of course, for HubSpot, it took 34+ designers and over two years of work to perfect their Design System. For most businesses, that kind of commitment just isn’t feasible.

Enter: Web Components. In this post, I’ll explain the five reasons why Web Components are the perfect way to quickly bootstrap a new Design System, with a future-proof design that will benefit you for years to come.

1. They work everywhere

Web Components use a set of standardized APIs that are natively supported in all modern browsers. These UI components run on nearly all mobile devices and desktop browsers today.

Through the use of a hybrid mobile framework like Ionic, you can deploy Web Components across just about any platform or device, from native iOS and Android apps, to Electron and desktop web apps, or even Progressive Web Apps.

For anyone building a Design System, the big benefit of this is that it finally addresses the need for a single source of truth—one standardized library that works everywhere.

2. They’re easy to customize

By definition, a Design System implies a customized collection of UI components that match your specific brand standards and style guidelines. While there are no limits to what your designers can conceptualize, implementing those customizations in some development environments and frameworks can be tricky.

For example, let’s say you’re using React Native to build a mobile application and you want to change the border around a button. If React Native doesn’t open up customization for that border, you’d be unable to modify it without going directly into the native implementation to manually program it. That doesn’t mean you can’t change the border, it just means it will be harder to do so in some situations. Check out our guide comparing Ionic and React Native for more on this topic.

In contrast, Web Components can be styled and customized to match any design pattern you want to achieve. With the simple use of HTML, JavaScript, CSS, you can build a library of UI components that match whatever your designers dream up. You can start with a ready-made Web Component library like Ionic and then customize from there, or use a tool like Stencil to build your own Web Components from scratch.

3. They help drive adoption

A Design System is only valuable to the extent that it’s actually adopted by your team. Having a brilliant style guide that is widely praised but always ignored is of no value. Web Components can help to address this challenge in a few key ways.

First, the simplicity of Web Components (just a few lines of HTML) makes development faster and easier. And, because they run on any platform or device, a single library will serve any development project. All of that adds up to a great developer experience. And happy developers are more likely to adopt your Design System.

Second, if you’re using Ionic’s library of components, we offer solutions to help drive adoption, like building your own collection of robust developer docs (modeled after our own world-class Docs) and tools like Studio, which offers a customizable library of components that developers can drop right into their development project.

4. They’re future-proof

Perhaps the most appealing benefit of Web Components is that they liberate us from the highly volatile landscape of front-end frameworks and tooling. By using a consistent set of web standards, Web Components are not dependent on a specific front-end framework like Angular, React, or Vue. Sure, you can use Web Components with any of these frameworks, and we encourage you to do so in order to take advantage of the many benefits they provide. But, the great thing is that you won’t be dependent on that framework for your components to work.

This is awesome news for development teams. First, as much as we love the hot frameworks of today, who knows what tomorrow will bring? By choosing Web Components, you insulate yourself from the threat of tech churn and no longer have to worry about picking the right horse.

Second, you will give your development teams the flexibility to choose the underlying frameworks and tools that they prefer. One of the great challenges of implementing a universal Design System is getting all of your development teams to standardize on just one set of technologies. Given the varied interests of most developers, that pretty much guarantees that someone will be unhappy because their tool of choice wasn’t selected. With Web Components, each team can use what works best for them, giving them complete freedom to use the tools they love—today and tomorrow.

5. There are plenty of WC libraries to leverage

Building a Design System from scratch is no easy task. I already mentioned that it took the HubSpot team two years and over 34 designers to build their Design System.

The great news is that there are already a number of Web Component-based UI libraries out there for you to start with: Ionic being one of the biggest and most well known. In fact, as our CEO, Max, argued in his post from a few weeks ago, Ionic is a Design System. You can start with our library of components and easily customize them to suit your needs.

How to get started

If you’re ready to start building a Design System with Web Components, start by checking out our library of totally free, open source UI components. Or schedule a Strategy Session with one of our team members to see how Ionic can help you build a customized Design System that your developers will love.

Read more

At Ionic, we are big fans of TypeScript and use it in several of our important projects, including Ionic Framework, Stencil, Studio, and AppFlow. We find TypeScript beneficial for a number of reasons, but mostly because it helps us scale our large (and fairly complex) codebases in many areas, including:

  • Catching bugs before build time through static type checking
  • Providing code completion and refactoring support in many of our favorite editors, like VS Code, WebStorm, and even Vim
  • Allowing us to use modern language features of JavaScript before they are available in all browsers

We think TypeScript is great, and we think many of our Ionic Angular developers would agree. We have also found TypeScript to be beneficial outside of Angular as well. In fact, we use it in our own AppFlow dashboard, which is a large React app.

Over the past couple of years, TypeScript has started to gain momentum in the React world and, now, has official support in create-react-app. So, we thought it would be helpful to share a little tutorial on how to kick off a new React project using TypeScript.

Using Create-React-App

Create-react-app is the CLI for React projects. While not as encompassing as the Angular CLI, it still does a great job at creating new apps (hence its name).

Install the latest Create-React-App through npm:

npm install -g create-react-app

Now, start a new project by running create-react-app and specify your project name:

create-react-app reacttypescript
cd reacttypescript

This will scaffold out a new React project. Notice, we have not specified that this is a TypeScript project. It will use standard JavaScript with the Babel transpiler by default, but we will change that soon.

Next, we will install TypeScript and some typings in our project:

npm i typescript @types/react @types/react-dom @types/node @types/jest

The typing files provide static type checking and code completion for npm packages that aren’t written in TypeScript. Install any additional ones for other third-party libraries you will be using.

The magic of enabling TypeScript comes from renaming all the js files in the project with a tsx extension (if the file contains JSX), or a ts extension (if it does not). Go ahead and rename App.js to App.tsx, and start up the development server.

npm run start

And, just like that, your React project is running in TypeScript! When you run the start task, behind the scenes react-scripts will detect that the project has TypeScript and automatically run a TypeScript build, no need to set up one in a Webpack config.

Notice also that you now have a tsconfig.json file as well. This file was created the first time the start task is run in a TypeScript project. Feel free to customize the settings in here to fit your needs.

React Components in TypeScript

Next, let’s create a new component in TypeScript and consume it from our App to see some of the benefits we now receive.

Create a new file named SayHello.tsx and paste in the following code:

import * as React from 'react';

interface SayHelloProps {
  name: string;
  onGetNewName: () => void;

interface SayHelloState {
  count: number;

export default class SayHello extends React.Component<SayHelloProps,SayHelloState> {
  constructor(props: SayHelloProps) {
    this.state = {
      count: 0

  render() {
    const { onGetNewName, name } = this.props;
    const { count } = this.state;
    return (
        <p>Hello {name}!</p>{' '}
        <button onClick={() => onGetNewName()}>Enter new name</button>
        <p>You clicked {count} times</p>
        <button onClick={() => this.setState({ count: count + 1 })}>

While this example is a bit contrived, it does highlight a major benefit of TypeScript, which is statically typing our components by specifying interfaces for the props and state objects. The SayHelloProps and SayHelloState interfaces specify the shape of the props and state objects, which are then passed in as generic arguments to the Component class.

Now that our component is statically typed, it is no longer possible to accidentally mistype a name of one of our props or state members, nor can you try to assign it a value that does not match the member’s type.

What’s great about Typescript is that you can catch these errors right in your code editor and also during build time, as seen below.

Wrapping Up

TypeScript helps teams scale their JavaScript projects by providing modern language features, static type checking, and tooling. With the official support of TypeScript in create-react-app, I expect more React users will discover how great this language is and how it can help them with their development.

You might be wondering why a post about React on the Ionic blog? Well, in case you haven’t heard, Ionic 4.0 was built from the ground up to work with any framework, and we have some exciting updates about official support for React coming very soon.

Expect to see more React content coming from us in the future. In the meantime, check out a sample Ionic React app to see the alpha in action.

Want to see more of the benefits of using TypeScript in React? Hit us up in the comments section below or on Twitter with your questions and feedback.

Read more

© 2020 Extly, CB - All rights reserved.