- Category: Developer News
Getting ready to kick off your next mobile application project and not sure whether to build a native mobile app or a Progressive Web App? This guide is for you!
At Ionic, we are fans of both traditional mobile apps (the kind you download from the app stores and install on your device) and Progressive Web Apps (PWAs). And, we have the tools you need to build either, or both, types of apps. To help you decide which is better for your next project, we’re going to take a practical look at some of the top considerations for each one. We’ll break it down into four categories: Device reach, app-like look and feel, device integrations, and distribution. Let’s dive in!
The first factor you want to think about when considering a PWA is device reach. Some important questions might be: What devices does your app need to run on? Is it meant for the mobile user, the desktop user, or both? Do the web browsers you’re targeting provide support for PWAs?
Since the theme of this post is mobile development, it’s safe to say you’re likely thinking of targeting mobile devices, which, today, mainly means iOS and Android. But do you also need to reach users who are on their desktop computers as well? With user preferences evolving to expect a company’s digital experiences to be available on any and all devices—Chances are, you do.
If you were to go native, it could mean that up to three apps need to be built, each with their own codebase.
Alternatively, PWAs are built with web technology and the web has the furthest reach of any other platform, running just about everywhere. Meaning, with a PWA, an app can be built once with the same codebase and is able to reach all your target devices.
However, there are still a few more questions to consider when thinking about PWAs and device reach, such as browser support. Do the web browsers you need to support run PWAs? Most browsers today support the majority of PWA features, but what if we have a browser that does not?
And, even if a browser isn’t supported, is it okay if a user has a downgraded experience in case a particular feature is not available to them? Additionally, is it important that all users have the same experience, or is it better to provide an optimal experience to those users who have the latest supported browsers, but still provide a graceful fallback to those that do not?
If you opt for a PWA, using progressive enhancement techniques can help provide optimal experiences for all users.
However, if a particular device feature, or the exact same UX, is something that’s required to be successful, but not all user browsers support it yet, then building a native app might be the way to go.
Usually, when people say “app-like,” it often comes down to the following qualities:
- Native look-and-feel: Does your app look and behave like it should on the device it is being used? Can users easily navigate on the app, with natural movements, to find what they are looking for?
- Speed & Performance: Does your app load quickly and feel responsive when a user interacts with it? Does it launch quickly?
- Offline Support: Does your app still have a useable experience (even if limited) when there is little to no network connection?
- Installable: Can users launch your app from an icon on their home screen?
- Native Functionality: Can your app do things often found in native apps, like receive push notifications or access device hardware like the camera and sensors?
Just a few years ago, a mobile website was not a viable option as a replacement for native mobile apps. A mobile site just didn’t “feel right” running inside a browser, even if it did mimic the UI of a native device.
Progressive Web Apps, however, fix the shortcomings of mobile websites by addressing all of the above app-like concerns. Additionally, a mobile UI framework, like Ionic, can give a mobile app the look and feel it needs, while recent web standards give PWAs the offline support and device integrations necessary to make it feel like an app. Once installed, users will probably never notice (or care), if the app is a PWA or downloaded from a store.
Next among considerations between choosing a native app or PWA is what type of device integration your app needs.
Devices are equipped with various sensors and capabilities that native apps, naturally, have full access to. However, this doesn’t necessarily mean you need a native app to access these features. However, what does matter is which device features are important to your app, and what level of control is needed when working with these features.
Fortunately, the web platform provides web-based APIs to access many of these features. There are APIs to access device hardware like cameras, GPS, accelerometers, biometric sensors, and more.
Despite this, the web APIs available might not provide the specific access you need, or a particular feature may not be available, yet, in all browsers. If this is the case, it might be a legitimate reason to choose a native app over a PWA.
When it comes to device integration, you must evaluate what type of accessibility and functionality is needed before choosing which approach is best. For a majority of apps, PWAs will be a good option, but for those that just need access to certain features, then going native will be required.
The web platform is constantly improving, though, and more device APIs are popping up all the time, so it is likely that something that is not currently available might be coming soon.
The last question to consider when choosing a development approach for a mobile app is: How will the app be distributed and published?
PWAs enjoy the same distribution story as normal websites. Once pushed to a server, PWAs are available to everyone. Here are some advantages of PWA distribution:
- Updates are quick with no need to go through app store approval processes
- The content of a PWA can still be indexed by search engines, meaning an app is still searchable and linkable
- If you are building apps for an enterprise, and it is internal only, then distributing the app as a PWA might be a lot simpler than going through an enterprise app store
There are still some benefits to the traditional app store model. Here are a few:
- Apps in the store can be more easily monetized (though that money is split with the store in hefty chunks)
- The app stores can promote your app. And, apps lucky enough to be featured can have a huge boon to their downloads
- The app stores provide metrics and error reporting for apps, automatically
- The app stores provide the bandwidth and infrastructure for your app downloads
- Native apps get full hardware API access (as discussed above)
There might be some good reasons to put your app in the app stores. However, this doesn’t necessarily mean a PWA still is not a good choice, as a relatively new trend is starting where a few stores are accepting submissions from PWAs!
For example, Microsoft has let developers submit PWAs to its store for some time now. Some advantages gained using this method are discoverability in the store, monetization through the store (like in-app purchases), and access to device hardware APIs. The best part is, PWAs are still distributed as a normal website, and the store basically just links to the PWA’s site, so you still enjoy the same distribution benefits as a normal PWA.
APIs have surfaced in the latest Chrome update that shows Google is also preparing for PWAs to be a first-class citizens in its store as well. While there is no official documentation on this (as of when this post was written), expect to hear some more about these exciting developments from us soon.
Why Not Both?
So, after reviewing all these considerations you may have discovered that having a native app in the stores is needed. But, you may also still find PWAs intriguing because they have their own merits and are worth pursuing for a number of reasons. If you feel this way, that’s ok! Because, my next question is: Why not have both a PWA and native app with the same codebase?
This is where Ionic comes in. Traditionally, Ionic has been used to build mobile apps with web technology by utilizing the hybrid capability of Cordova to package those web assets into native packages that you can distribute directly to the app stores. These apps still get native API access (through Cordova plugins), and the additional benefits we mentioned from having an app in the store.
While providing hybrid technology for building native-like mobile apps is still our main focus, we have also put substantial effort into our latest version of the Framework, Ionic 4, to make it the platform of choice for building progressive web apps.
In our latest developer survey, 42 percent of developers stated that the PWAs they are building are companion apps to their native counterparts and that 35 percent are thinking about deploying their Ionic apps to the stores as well. PWAs can be a great way to get to market quickly and then rope users into a deeper native experience.
With Ionic, an app can be built for iOS, Android, and as a PWA, all with one codebase—Saving you time, effort, and cost by giving you three platforms for the price of one. To learn more about PWAs and how to get started, check out our resource page with use cases and best practices for progressive web apps.
- Category: Developer News
When it comes to choosing a cross-platform development approach, it can be difficult to know where to begin. Frequently, we’re asked by teams who are comparing frameworks to explain how Ionic stacks up against React Native, Xamarin, and others in our space.
Often, the expectation is that all of these frameworks work similarly and the decision to choose one is based largely on your current tech stack. For example, choose Xamarin if you like C#/.NET, React Native if you prefer React, or Ionic if you’re an Angular shop.
However, the decision isn’t nearly that simple. And the choice you make carries implications far beyond your current tech stack.
The truth is there are some pretty big philosophical differences that separate Ionic from these other cross-platform tools. We put together a brief guide to walk you through the key similarities and differences.
To keep it actionable, we limited our comparison to Ionic vs. React Native, two of the most frequently compared options. That said, nearly all the distinctions highlighted apply equally to Xamarin or NativeScript. As you’ll see, the real distinction comes down to two opposing worldviews: What we call, Hybrid-Native vs. Hybrid-Web. While we have great respect for these other frameworks, the fact is our approach is very unique. Hopefully, the following guide will help you make the right decision for your next project.
Check out our post, Ionic vs. React Native: A Comparison Guide, in the new articles section of the Resource Center. And, be sure to look out for more practical guides and emerging coverage in this space.
- Category: Developer News
It was almost a year ago at Ng-Conf, when I sat in on a session about TypeScript. One of the speakers that caught my attention was Alex Eagle, a software engineer at Google on the angular-core team, who shared an update about Google’s plan to integrate a new version of TypeScript internally before releasing it to the public.
This was of particular interest to me at the time because I had been working with our architecture team at SpaceX and the adoption of new architecture components had always been a pain point for us. When I discussed this issue with Alex, he explained that his team had been using TSLint fixers (more on those in a bit) to roll out changes to their projects’ code, which got my wheels turning on how I could implement TSLint in my own projects.
During this time, Ionic 4 Beta had just been announced and while the breaking changes list wasn’t much compared to the Ionic 1 to 2 upgrade, it still took a few hours for the migration to complete and left a bit of room for error in what was a fairly small app. It was during this period that I decided to test out using TSLint fixers to perform this migration for me.
Using the fixers
I’m happy to say what came out of this endeavor was the creation of the Ionic 4 Migration tool, which you can use similarly to how you would use the normal TSLint rules. Here are the steps:
- Upgrade your project to use the latest Ionic version, which was RC1 at the time of this blog post draft. You should now have a bunch of errors if you try to compile.
- Install the rule-set using
npm i -D @ionic/v4-migration-tslint. You will also want to add a file to the root of your project named ionic-migration.json and add the configuration below.
- Run the analyzer to identify all of the changes you will need
to make in your code using
tslint -c ionic-migration.json -p tsconfig.json. Bonus: We implemented a bunch of fixers to automatically correct most of the breaking changes, which you can use by adding the
--fixflag to the end of the command. (Tip: Be sure your project is backed up or stored in source control just in case anything unexpected occurs.)
Limitations of the tool
Unfortunately, there were still a few changes that we were unable to automate—A big chunk of which had to do with CSS changes. This is because stylesheets are a bit more flexible, making it hard to identify a common pattern to apply across the migration tool. We also had some cases like the Ion Menu Toggle where the DOM changes were incredibly complex and had to be fixed on a case by case basis.
Lastly, during this process, there were some breaking changes where methods returned promises. While the documentation specifies that async/await should be used to execute this, we found that people were using .then() instead or they would return the promise directly from their method instead of waiting and returning the result. Because the syntax for handling promises can be so varied, we decided to not implement a fixer for these rules, and instead rely on warnings.
Overall, we found these limitations to be pretty minor and most of the tedious changes should be covered with this tool. To see what changes are covered by fixers, head to the repo page to view all of the rules with each rule containing a link to its section of the Breaking Changes page.
How does it work?
This tool is built on top of TSLint which is a static analysis tool that takes advantage of the TypeScript AST(Abstract Syntax Tree) parser. We also used Codelyzer, which is an Angular-specific implementation of these rules and includes some very helpful utilities for parsing Angular-specific components, if needed.
Each rule generally has a single target. For example: In the case of ion-button, we had to find places where ion-button existed as an attribute and then replace the element on which it was annotated. We did this by first visiting every element in the DOM tree and looked for any attributes that matched ion-button. If we found a match, we extracted the element’s content and replaced the element with a new ion-button, which had the contents of the previous element.
Ready, set, go (upgrade your app)!
I look forward to seeing how others use this tool and hope it will help you or your team’s projects when converting to Ionic 4.0. And, if you’re interested in trying to build out some of the remaining fixers, please check out the repo and feel free to submit a PR!
I’d like to thank Dan Imhoff and Mike Hartington for their help on this project—Thanks to them, our team was able to get this project over the finish line quickly and easily. Can’t wait to see what you guys build. Happy coding!
- Category: Developer News
By now, you likely have heard the news that Ionic 4.0 is here! If you’re currently maintaining an older Ionic app though, you might have concerns about the challenges of upgrading to the latest version. While there will be some work involved to migrate over, there’s never been a better time to do so. Take a look below for some of the benefits of upgrading to Ionic 4.0, plus links to our migration guides to ease the process.
Another exciting change is that Ionic is embracing framework-specific tooling. Ionic 3 has custom command line and build tooling, as well as custom router implementations, which has often led to some churn and confusion. However, now that Ionic embraces the tooling and architecture of each specific framework, it’s become much simpler to integrate our technology. Using Angular? Use the Angular CLI. Using Vue? Use the Vue CLI, etc. It’s the best of both worlds. So, as your framework of choice evolves, you get the latest and greatest tooling, leaving more time to focus on what matters—adding more value to your app.
Angular is Still a First-Class Citizen
Angular fans, have no fear! Just because Ionic 4.0 broadens our framework reach, doesn’t mean we are leaving it behind. In fact, Angular will continue to be a major focus for us in 2019 and beyond. The best part is that you’ll be able to reuse the majority of your Angular-specific code when updating to Ionic 4.0. Your services, for example, should port over without modification (assuming they aren’t depending on any Ionic-specific functionality). Ionic 4.0 supports Angular 7+ today and will closely follow future major Angular versions.
Write and maintain one codebase that will run on any device or operating system across mobile and desktop. This includes native iOS and Android apps, as well as Progressive Web Apps, and even Electron-based native desktop apps. Ionic apps don’t just run on any platform, they are specifically designed to look and feel native to the platform that they run on. The benefit of this approach is that it drastically cuts down on the time and cost to create multi-experience apps that run on iOS, Android, desktop, and more.
Migrating from Ionic 1.0 to Ionic 4.0
This migration involves moving from AngularJS (aka Angular 1) to Angular 7+. There are many architectural differences between these versions so some of the app code will have to be rewritten. The amount of work involved depends on the complexity and size of your app. The upside is that for the most part, the Ionic UI components you know and love from Ionic 1 haven’t changed much.
In terms of a strategy for beginning the migration, identify a time frame (perhaps one or two sprints) to get started. We recommend feature-freezing the Ionic 1 application and getting the code in order: Fix any major bugs, eliminate tech debt, and reorganize as you see fit. Then, identify which features to migrate over and which to abandon. Then, create a new Ionic 4 application and begin porting features over. Once the team is comfortable that the new app is stable, you can shut down the Ionic 1 app.
Migrating from Ionic 3.0 to 4.0
Migration off of an Ionic 3 app will require less work than an Ionic 1 app, but you’ll need time to successfully complete the transition. Begin by reviewing Angular’s release guide to gain an understanding of the changes from Angular 2+ to Angular 7+. Next, generate a new Ionic 4 project and start by copying over various parts of your Angular code such as services, providers, pipes, and components. Work on one feature at a time, from top to bottom, testing as you go.
Two areas that received the most changes are navigation and lazy
loading. Instead of using Ionic’s own
we integrate now integrate with the official Angular Router. By
embracing the official
tooling of each framework, a more consistent and dependable
routing experience is achieved. Since navigation has changed, the
mechanism for lazy loading has also changed in Ionic 4. Now, this
is accomplished using the
loadChildren method of the
So, what are you waiting for? Check out the full migration guides and begin migrating to Ionic 4.0 today.
If your team would like assistance with the migration, please reach out to us for more information! Ionic offers Advisory Services, which includes Ionic 4.0 training, architecture reviews, and migration assistance.
- Category: Developer News
Today I am thrilled to announce the 4.0 release of Ionic Framework, lovingly known as “Ionic for Everyone.”
Ionic 4 represents the culmination of more than two years of research and hard work transforming Ionic from “mobile for Angular” into a powerful UI Design System and app framework for every web developer in the world.
There are so many things to talk about with this release, but first I’d like to talk about how we got here.
The Angular Years
Unfortunately, there was no standard way to do that back then, so we jumped on the next best thing: AngularJS directives. We loved that you could build custom directives in AngularJS and package up all the complexity we needed to offer native-quality components into an easy-to-use custom HTML tag. Any AngularJS template that used that tag would magically bootstrap the component and run it as if it was natively supported right in the browser. Our early experiments with AngularJS were so successful we stopped looking at alternatives and went all-in.
When Angular 2 was announced, we knew that in order to stay relevant in the Angular world, we’d need to port Ionic to it. So, we shipped Ionic 2 and 3 to do just that. I’m so glad we did, as Ionic 3 has been the most successful version of Ionic yet.
Oh, if only the story ended there!
Fast forward to 2019, and the frontend landscape looks nothing like it did back in 2013.
To start, AngularJS has been replaced by modern Angular. React, which wasn’t even on our radar back then, has achieved massive popularity. New frameworks like Vue have grown even more quickly and serve to remind us that the status quo is anything but.
So much change happened so fast that “frontend churn” became the bane of a generation of web developers.
At the end of 2017, we started asking ourselves if our original dream was worth revisiting. It was clear that frontend developers would never settle on any specific frontend framework or libraries, so to assume otherwise was futile. At the same time, we were frustrated that Ionic could only be used by those that embraced Angular. And, while we loved Angular, we hated the idea that Ionic wasn’t achieving its original goal of being a toolkit for every web developer in the world.
Luckily for us, something wonderful had happened in the frontend world between 2013 and 2018: Browsers had converged on a standardized component model, allowing developers to define custom HTML tags and easily distribute them to other developers. This collection of APIs become known as Web Components, and they were everything we had dreamed of back in 2013.
We started experimenting with turning Ionic into a set of Web Components in 2017, and we were blown away by how capable and efficient they were. In our minds, it was clear Web Components would be the way UI libraries, like Ionic, would be distributed in the future. So, we took a big bet and started porting all 100 of our components over.
Thusly, Ionic Framework 4, “Ionic for Everyone,” was born.
“Ionic for Everyone”
With today’s release, Ionic Framework is now distributed as a set of Web Components using the Custom Elements and Shadow DOM APIs available in all modern mobile and desktop browsers.
This means that practically every web developer in the world can now use Ionic’s components in their mobile, desktop, and Progressive Web Apps—just by using Ionic’s custom HTML tags in their app.
On top of that, because Ionic now targets standard web APIs instead of third-party ones, developers can rest assured that Ionic’s component APIs will stay stable for many years to come instead of falling victim to frontend and framework churn.
No longer just “mobile for Angular,” Ionic is now a modern, web-based Design System and app framework for every web developer no matter what tools and frameworks they choose to use on top.
This is the dream we’ve had since 2013, and, after six years of hard work and making some big bets on promising new technology, it’s finally a reality.
The Best Ionic Yet
Not only is Ionic 4 the most accessible and future-proof version of Ionic we’ve ever built, but it’s also the fastest and most complete.
Every one of the nearly 100 Ionic components has been evaluated for performance, theme customizability, and platform look and feel. This includes a complete iOS and Material Design refresh for each component to match the latest standards on iOS and Android.
Since each component is now a Web Component built with our new Web Component compiler project Stencil, Ionic components are optimized for load and render performance, helping Ionic apps reach the coveted 100/100 score* on Google’s Lighthouse benchmark tool (*heavily dependent on the framework used with Ionic).
We’re going to be publishing more extensive data and benchmarks comparing Ionic load/render performance across various frameworks, but the graph above shows significant improvements on First Meaningful Paint for developers using Angular with Ionic 4, and this is just the beginning.
Finally, we’ve dramatically improved the design for all new app starter templates, to help developers get to great design faster than before.
Performance for World-Class Progressive Web Apps
Progressive Web Apps are all the rage right now, and Ionic 4 was designed out-of-the-box to be the best UI framework for building high-performance PWAs.
For Ionic to reach performance standards set by Google, new approaches for asynchronous component loading and delivery were needed. To achieve this, we spent a year building out a web component pipeline using Stencil to generate Ionic’s components, ensuring they were tightly packed, lazy loaded, and delivered in smart collections consisting of components you’re actually using.
Today, Stencil-built components lead the pack in terms of bundle size and load performance, and Ionic 4 benefits from all of that.
Of course, you’ll likely be using Ionic with a separate frontend framework like Angular or React, so we will be publishing some guides shortly about how to pick the right technologies to reach Progressive Web App performance standards, since reaching performance standards with Angular and React requires some additional work.
Built for Customization
One of the biggest changes under the hood is the move to using native CSS Custom Properties, also known as CSS Variables, in each component.
CSS Custom Properties make it possible to expose a “public theming API” that provides structure to developers that wish to brand and customize Ionic’s components, in a way that supports easily upgrading to future versions of Ionic without introducing compatibility issues. CSS Custom Properties also provide a standardized way to theme Ionic apps independent of the frontend framework used in your app.
This means developers no longer have to modify the internals of Ionic’s Sass/CSS styles or inspect to find internal classes to override. Modifications now happen by targeting Ionic’s public theming API through the published, documented CSS Custom Properties.
This represents a significant improvement over the style modification process web developers have had to work with, in the past, which often restricted developers from being able to upgrade to new versions due to reliance on internal style modifications.
One of the things Ionic developers often tell us is that Ionic has some of the best developer documentation around.
We take incredible pride in that, but we also knew that our old docs could be improved in a number of significant ways.
Today we’re launching version 0.5 of a major revamp for the official Ionic Documentation, which along with dramatically improved performance also includes a simpler design, focused on content, and an easier-to-navigate organization.
We’ve also consolidated the API reference and the component reference, reducing the number of pages developers have to flip between to get the information they need.
We’re not quite done with the final version of the docs, but we’re releasing a version 0.5 today that has most of the content and API references filled out.
Check out the new work-in-progress docs.
Perfect for your Design System
With new theming capabilities and a focus on framework-agnostic web components, Ionic is ready to be the foundation for your own Design Systems, essentially building your own Ionic on top of Ionic.
We dug into this on the blog last week, so take a look if you’re interested in building a cross-platform, web-standards based Design System for your company.
Use your Framework’s Tooling
With Ionic 4, we now use your framework’s official tooling for building, bundling, and routing, so you can get the most out of your framework’s ecosystem and we can focus on what we do best.
That means you’ll use the Angular CLI when using Ionic with Angular, Vue CLI with Vue.js, and so on.
Read more about this on our blog.
React and Vue, too
Ionic is moving to a “bring your own framework” model, and because Ionic’s UI controls are now based on Web Component APIs, they can generally work out-of-the-box in all major frontend frameworks (Angular, React, Vue, etc.).
However, Ionic also needs to integrate with a framework’s
routing system for a first-class native navigation experience, so
we still have to ship framework-specific functionality.
Additionally, developers on each framework expect things to work a
specific way that sometimes deviates from the way they are done
with plain Web Components (like React devs expecting
Our official Vue.js and React bindings are currently in alpha and you can expect them to be a big part of the Ionic 4 developer experience going forward. We are incredibly bullish on these two frameworks and expect that the majority of Ionic developers will eventually build apps with one or both.
Lastly, we dug into how Ionic Vue was created on our blog. Take a look if you’re interested in how this project came to be.
Over the last two years, we’ve been intensely focused on making Ionic the most future-proof, framework-agnostic, high-performance, and standards-based UI framework ever.
Now that 4.0.0 (codenamed Neutronium) is out and production-ready, we’re thrilled to be able to invest some more time in improving what you love most about Ionic: Our components.
Next on our roadmap includes desktop-specific UI support to expand the types of desktop apps that can be built with Ionic, improved keyboard scenarios (chat apps, etc), better theming options, richer animations, and more. Along with improvements to the core of Ionic, expect more tutorials and guides on migrating to and building with Ionic, now that we feel confident going all-in on this brave new version of Ionic Framework.
Additionally, we are excited about making React and Vue support first-class in Ionic and expect that these frameworks will become a significant percentage of the frameworks used in Ionic apps, so watch for updates on those in the near future.
We will also be working to incorporate our new Cordova alternative Capacitor as an option for new Ionic projects in the CLI. Stay tuned for more on that this year.
Before we leave, we want to extend a huge “thank you!” to the entire Ionic community. We’ve been teasing Ionic 4 for a while now, and in an ecosystem filled with change and uncertainty, we are grateful to have had your trust and patience throughout the entire process.
We also want to thank the Ionic community members who took a big bet on Ionic 4 and shipped real apps even though it was alpha and we said very clearly it wasn’t production ready .
Teams like Sworkit, built and shipped entire new versions of their app with Ionic 4, and we’ve been working directly with enterprise teams that are doing the same. With Ionic 4 going into a production-ready state, the pressure release valve has been opened and we are excited to see other teams start building with it.
Last but not least, we want to thank the wonderful contributors that have stepped up to help Ionic 4, whether that was by submitting PRs, helping test new releases, or creating educational content for the community: None of this would be possible without your help.
Getting Started and Migrating
Getting started with Ionic 4 is easy. Follow the Getting Started Guide, or create a new project directly from the Ionic CLI:
npm install -g ionic # Update the Ionic CLI ionic start awesome-app
For teams looking to migrate from an older version of Ionic to Ionic 4, we can help! Along with a fully-supported version of Ionic Framework for Enterprises building mission-critical apps (including Cordova/Capacitor native plugin support!), we have Advisory Services available for teams that need assistance. Plus, we’ve also published a Migration Guide for self-directed migrations, along with some tools to help ease the process.