2.0.0 final released!

Hey everyone,

We’re SO excited to announce the Ionic 2.0.0 final release! :tada:

What’s New

If this is your first exposure to Ionic 2 or you have been waiting patiently (thank you!) for 2.0 final, a number of things are new and different – enhanced performance, new components, features, tools and documentation. Read the full blog post here: http://blog.ionic.io/announcing-ionic-2-0-0-final/

Getting Started

Start a new project by following our quick Getting Started guide. If you already have the Ionic CLI installed, make sure to update to the latest CLI by running npm install -g ionic.

If you are curious about updating to V2 from V1, we’ve put together a Migration Guide (PDF) that walks through updating a sample app.



Congratulations to 2.0.0. We all waited a long time for this moment!

But for me, this is just - how to say - disappointing. There are a lot of unresolved issues I have expected to get solved until the final release.
Startup time is still really bad and not acceptable on even newer devices, the keyboard under Android has a lot of issues and some component problems remain unresolved.
And on top Max is writing in his blog post “Ionic 2.0 final is hardly the end of Ionic’s development.” What does this mean?

And I get the impression that not really many programmers are working on the frontend. There are basically only Brandy, Adam and Manu. For these amount of issues, problems and development?

I’ve been playing around with Ionic 2 the whole year '16, but some things didn’t get any better.
Just right now, I started evaluating other frameworks and alternatives. But I just don’t want to!!

Please keep up you work and make Ionic 2 great :slight_smile:


@mpaland Dude, build the app with -prod, it reduced me the startup from 7~ to 2~ seconds.

@post: Updated my Ionic now, was already using 2.1.18, didn’t faced a problem at all. Thanks developers for the awesome work!

1 Like

I completely agree with you. Personally I am using RC3. I can get faster opening times with RC3. I tested with RC4 and RC5 and opening times were terrible. And there are a lot of Native plugin incompatibilities with RC5. I haven’t tried final release yet. But RC6 and final releases released too soon. I don’t think they can solve these problems with such short time period.

My app was recently accepted and released in the Play and App store using RC.3 and now RC.4.

Therefore, in my case, I’m agree and happy that Ionic 2.0.0 is final and no more a release candidate.

Having a final version doesn’t mean that, I guess, the Ionic team not gonna improve it anymore, just that they achieved an important step in their lifecycle.

Furthermore, I think that reaching this step will add stability in the framework (like no more ground breaking changes as it was between Beta->RC).

As everyone, I will always welcome improvements, specially in the boot time and looking forward to the future :wink:

Congrats Ionic team :tada:, it was a long journey for you as it was for me (my app was recently published after many months of development too).

Kiss and :heart:

Great work team Ionic! I’ve been with you since beta version 1.0 and all the way through 2.0. I just want to say thank you for all the hard work. I appreciate what you have achieved in making a framework that helps us web based developers able to create great apps for all relevant platforms. Congratulations!!

For the package.json file to utilize this new version, all you have to do is change the version to 2.0.0? Like below?

"ionic-angular": "2.0.0~rc4"
"ionic-angular": "2.0.0"
1 Like

Always get in the habit of reading the CHANGELOG whenever planning to upgrade. There are other steps you must take to get from RC4 to final.


I’ve been using Ionic 2 for the most of 2016 and although it’s a great framework, it is not production ready. There are a lot of UI issues that have existed for many months and are still unresolved and mainly the startup time is unusable (yes, I’m building it in production).

You’ve been neglecting this problem for the last 6 months, closing all issues about it without providing a resolution. If you don’t do anything about it, people who want to build real store apps (myself included) will have to switch to something else.
No customer will wait 5+ seconds for an app startup, even Ionic 1 started up faster.
I know that it’s mainly a problem of Angular 2, but at least you should communicate about it and not turn a blind eye, as I think that this is the most serious Ionic 2 issue (and I’m not alone, check for example this issue - https://github.com/driftyco/ionic/issues/6776).

1 Like

Hey yall, so I just wanted to address some comments that have been mentioned here.

So some of the facts regarding github issues seem to be misunderstood. We’ve been working on ionic for several years now, and with the focus shift to V2, the increase in issues is to be expected.
We could spend all the time in the world shipping betas/RCs, making sure every issue is addressed, and never shipping 2.0 final.
Or we can get things to a point where we feel good about the code base, ship 2.0 final release and then continue work after.
We choose to release 2.0 now because the code base was at a point where it had a solid, well tested core, and had the features that we thought it needed for now. This doesn’t mean we’ll stop adding features, or fixing other issues, but we needed to pick a point and say “Here is 2.0.0, this will be 2.0.1”.

Regarding build and startup speed:

With RC 0, we moved over from gulp to using app-scripts. This allows up to update the build task independently from the framework, which is huge.

Prior to this, if something in the build process broke, that normally meant having to:

  • cut a new release of the framework
  • adding notes on how to update gulp and the gulp tasks
  • Install/Update any packages
  • lots of manual changes needing to be done by a dev.

Instead, now, we can just cut a new release of app-scripts separately from the framework, and not have to have the framework involved at all.

Now if we need to add features to the build process or work on build performance, it can be done independently from the framework. So any build related issues/question, have nothing to do with the framework and it’s releases.

With app-scripts being 1.0.0 now, we’re not resting either, but we have not been very good at talking about what we’re doing.

Launch speed is something we’re working crazy hard on, and some of the techniques that we are trying are brand new. As we stated in the 2.0.0 release blog, this but is a bit of an uncharted territory for everyone. No one has a solid answer on “this is what you do”, but we’re getting a better picture everyday. What I can tell you what we’re working on is working with code-splitting, tree-shaking, and lazy loading. These features take time to work on though, so please be patient.

For some of the other speed related issues, we’ve noticed 2 common trends, both of which have been addressed many times:

  1. Slow startup from not running a production build (app-scripts change log)

This was introduced in 0.0.47 of app-scripts, allowing for a much smaller build and therefore faster load times. Most of the time when people mention to me “I have slow load time”, they haven’t run with the --prod flag.

  1. Slow builds due to source map generation during dev build.

Another thing I hear people say is that build times take a long time to complete. This is due to the source maps being generated. There two kinds of source maps, eval and devtool. We originally had eval as the default but switch after hearing that people wanted more detailed source maps for debugging. devtool source maps take longer to produce, as it has to go through bundled code, es6 code, and then to TS code. It’s simple to switch to eval, and is noted in the app-scripts README page.

A lot of the pain points that I haven’t mentioned, we’re aware of, and are working hard to address them. We appreciate your patience, and ask that if you find something new, please open and issue, and we’ll work on it over on github.

Thank you for hanging in there with us :smile:


I understand that it is a hard task to improve the startup times, especially when it’s probably caused by the Angular switch to modules amongst other things and it’s not completely in your hands. I just felt that you didn’t take this issue seriously, because you closed all the issues concerning this and always just responded that we don’t use prod build (which sometimes was true, but even with the production build it was very slow).

I understand that you had to ship a release version, yet for me it seems strange reading “Ionic 2 is finally ready for production” when I know that (at least on Android) it is not ready because of the startup times, which are unacceptable for users of any non-trivial app. Even the bare-bones blank app takes almost 4 seconds to start up on a modern Android device.

So thank you for writing this, I trust in you to improve the startup times in the future. I really love this framework and I’m looking forward to be able ship a new version of my app with it :slight_smile:

Not true really. While we have an internal note of what is causing startup to be slow for the framework, there can be a rabbit of hole of issue for why peoples apps are not starting fast. One dev I worked with was trying to preload a 2mb db on start up…

So it can range from things being done in a slow manner to a list of known issues. Rather than keep the issue open and get notifications that could range from literally anything, it’s best to close the issue as it’s too open ended, and really a better fit as a forum post.

As for a bare bone apps startup, I’m seeing less than 800ms on my old android 4.4 device. Though loading a bigger app like the conference app does increase load time. It’s all about the parse time for the JS that is getting produced. Looking at time line reports from the dev tools shows us how much time is spent just reading the JS.

Really only 800 ms from the click on the app icon to the loaded UI (after splashscreen) in the blank template app?
Then I must be doing something wrong, I have Sony Z3 Compact with Android 6.0.1, building it in release mode with production build, tried both with and without crosswalk, but couldn’t get under 4 seconds.

Do you have a tip on how to profile it?
I find it very hard to profile the startup as I cannot connect to the remote debugger and start the profiler before the app itself starts.

Yep, if you connect after start up, then while focusing the dev-tools, hit cmd-r or ctrl-r for windows, then you’ll be able to see the full time line

Could you build a best-practices doc for building dev and prod?

I find myself searching through post after post for what’s worked for different people given different build targets. For instance, there are currently a few threads dedicated to why does “–prod” not work for me.

Thanks, and great job with the v2 release!!

Thanks for info but, I think your greatest danger with going to 2.0.0 FINAL is that newcomers will experience the ‘slow’ launch time - assume its ‘normal’ for ionic and disregard the framework for another faster one. Newcomers are very unlikely to understand its still a #1 priority issue you’re actively working on.

Congrats to the team.

Ionic 2 is my entry to mobile app development and I am deeply thankful for that. Started working with it since it was in alpha and moved up with it.

God job guys.

Keyboard issue, for chat application is still there.

1 Like

Hi Mike,
I am a noob on profiling, could you head me to an article or link on where to start?