It's a nightmare to maintain an ionic app

Ionic Framework
1

Why is backwards compatibility broken ALL THE TIME? I’m maintaining an app that was built with ionic-v1. Lots and lots of things have broken and been deprecated in just a few years. Strong recommendation to move to capacitor for unclear reason other than breaking compatibility. Surprise, capacitor requires typescript which is not supported in ionic-v1.

It’s pretty obvious to me that those that develop Ionic has NO INTEREST whatsoever in making an app easy to maintain over the years. And with constant launching of new versions with compatibility breaks and new best practices it’s almost impossible to find useful docs in forums, as it’s so fragmented between the versions.

Sorry for the language, but I’m just so incredibly frustrated when I’m spending days to just get stuff to work, with NO real code change whatsoever to the app, I just want it to build with an up to date toolchain.

Making apps with web technology is supposed to be easy. And it is. If you follow the current tutorial. But if you get back three months later, that tutorial looks different, and if your app was based on the old tutorial, you’re f****d. It’s like as if this framework is made for people that make apps that take one month to develop and has a life cycle of three months before it’s thrown away.

I make apps that have life time that spans many years, and they don’t need that much functional update. Is that use case really that unique that you need to make migration a living h*ll?

8 Likes
2

Software development is constantly changing for many reasons, so it’s the developers responsibility to update their projects accordingly. Ionic 1 came out 7 years ago, that’s a very very long time in the software world. It’s not the Ionic’s fault that you lack a skill of updating your project to keep up with modern standards. The best advice you are going to get is the following:

Migrate your whole project to the latest ionic 5 using angular or react, which ever floats your boat.

There any many benefits you gain: You learning something new & your customers will be happy using your app. Good luck!

2 Likes
3

It’s not about lacking skill. It’s about if you think that a framework should support the idea that a developer using it should spend time developing actual new end user functions, or instead spend time keeping up with today’s fashion of solving the same problem that was already solved yesterday in a somewhat different but still functional way.

I’m not against frameworks moving forward. But I think there has to be a balance, where you carefully think if an improvement is really worthwhile to break backwards compatibility, and if you serve the users of the framework, or if you just go for a vain idea of being “modern”, or make things “smoother”.

Or maybe I take it back, it’s indeed about lacking skill, as you don’t ever get chance to get any, as by the time you have it – it’s obsolete.

I don’t work full time with web development and apps. I work much of the time in other software development areas, like telecom and desktop applications. And there is a marked difference. For example, QT is a toolkit that see a lot of development, but it’s no way near making your software rot at the speed I’ve seen it do in Ionic. It’s like if backwards compatibility is not something that’s even considered.

I think one shouldn’t count from the time ionic-v1 was first released, I made the app back in 2016 and it was still v1 back then. It’s only 4 years ago.

If you really work full-time specializing in doing only apps only using Ionic, it’s quite okay using a moving target. If you jump in and out of app development doing other stuff in-between it sucks pretty bad. But maybe it has to be this way.

One big frustrating part is that from an end user perspective migration is 100% meaningless, the app will work exactly in the same way as before and look exactly the same. The only reason I need to migrate is so I can compile and deploy today so I can make minor feature updates and bug fixes.

1 Like
4

I think one problem is that those that develop frameworks live with it all the time, 100% of the time. They don’t see the users that go in and out of app development, and don’t notice what happens if the software has moved a few major versions since you last made a release.

The thing with mobile apps is that many are quite trivial in nature, and once they are made they are “complete”, ie there is little need of further development and the app stays current as long as the service/function it provides is useful. Which can be many years. But occasionally you need to add this little feature or fix a bug, and you need to modify the source a bit and make a new build. My guess is that a cross-platform framework will see more of this type of apps than apps that are made native.

So I’m a bit surprised that this use case is not considered more than it seem to be.

Note that I don’t claim to be an expert in Ionic or the conditions Ionic need to work in. iOS and Android development environments are also quite quickly moving targets, and I guess that is part of the problem. So if it has to be this way, so be it.

I just thought I’d share what I see from the perspective of being a relatively “casual user”, and point out that not all of us love to get new features and exciting toolchain changes at a blazing speed.

1 Like
5

I can totally relate to how you are feeling. Ionic is great, but it would have been so much better with many new features if they had not rewritten it so many times. In turn forcing our stable apps to be rewritten/updated/fixed just to catch up.

The updates from Ionic1 to Ionic2 to Ionic4 have taken us ‘months’ of work for each app unlike what tutorial writers claim to be doing within hours and days. Like you said, I have also felt at times as if everyone else is only implemeting apps that take a month to finish and then they don’t have any real work to do other than be excited about chasing angular and ionic updates, or maybe I am becoming old and grumpy at 36. The framework and the app is all new and shiny inside with new Ionic and new Angular etc, but the end-user sees almost exactly the same app as before - just with new bugs because some of the code had to change.

I absolutely love Ionic, and can’t find any better alternate to it. So hats off to the awesome team, I really admire all the hard work and how good the framework is. From technology perspective, I can completely understand why they did it everytime. But it is painful, and expensive, and disruptive to manage this. I just hope they don’t get any new awesome ideas motivating them to do another rewrite for next 5 years, please.

Cordova has its flaws, and a lot of the technology decisions behind Capacitor are great. But it is hard to know if it will stay the same after 18 months or become another moving target for us to keep chasing - just to be able to build the apps with latest toolchains. Forcing us to wait for the dust to settle a bit.

With Ionic 5, focus seems to have already shifted a bit with only minor breaking changes, and I sincerely hope that backward compatibility continues to get more importance in future releases.

3 Likes
6

It is not just a casual user issue. We are consultancy with multiple developers working full time on multiple apps built with Ionic. Even for us with Ionic in our mind all day, its a problem to return to another app which hadn’t been updated for 5-6 months.

Its a completely different problem convicing the clients for the cost it will take to update the app to newest versions - some agree, some don’t, some expect us to ‘absorb’ the cost because using Ionic was our decision.

For a developer going back to add a feature to apps still on Ionic1 or Ionic3 after working on migrating an app from Ionic4 to Ionic5 (and all the ionicon changes that come with it), and then switching between adding features and fixing bugs in multiple such apps on different Ionic versions after every few weeks - the insides of their brains start to resemble mashed potatoes :slight_smile:

But despite these issues, Ionic is still a great choice for building mobile or web apps and we are not planning to switch to any alternate any time soon.

3 Likes
7

Some experiences so far from my migration:

I tried to move to Capacitor as the Ionic CLI strongly recommend to do that. New script hooks system with slightly changed format, fine, fixed that. But then further in it turns out though that Capacitor requires typescript and you need to make an ugly hack to make it usable from old-school javascript used in ionic-v1. So Capacitor is not compatible with ionic itself…

Then I changed back again to cordova. Cordova has changed a bit too, but no real breaking changes. However again ionic cli has removed all cordova wrapping commands, while I can write “ionic cordova …” it seem to provide no value whatsoever over just running cordova command directly. I thought the idea of the ionic CLI was to wrap clumsy commands and make things easier. It turns out to be the opposite due to that the CLI keeps changing.

So now the plugins need to be installed and managed by cordova directly. Which seems fine by me as cordova’s command line seems to be a lot more stable and not deprecating commands all the time. Some of my plugins had become deprecated, but then replaced by new one with the same API. With one exception – the ionic keyboard which had been replaced with a new plugin with an incompatible API.

Ionic just keeps popping up as one that make source-breaking changes… it seems like the ionic team doesn’t understand the value of keeping a stable course and make designs that can hold up for a long time. I seriously think that they team should reconsider the balance between following the fashion of the day and striving to have an eco-system that makes it somewhat easier to maintain apps which has a life span of more than one year.

I also admire the hard work. I don’t want this to be just a bunch of negative feedback, but I think this feedback is important too if they want Ionic to become even more successful and useful to a broader audience.

For my next project I may look into running just cordova and some generic HTML5 gui toolkit. Not because I dislike Ionic, but because my next project is also expected to have the same property as this one, that is a long life span, while being “complete” at the first release and thus not needing more than minor maintenance over the years. And then using a framework that constantly re-invents itself is not the right tool for the job.

I need stable long-lived APIs and thought put into backwards compatibility.

1 Like
8

I am totally in agreement with you. But I think you are applying an app development art paradigm that has long ago been lost.
I have programs that I wrote in C over 20 years ago, and they still can be recompiled as needed if a mall change is needed.

I do not expect Ionic or Vue, or React to be backward-compatible at that level, because platforms and programming environments are evolving a little faster these days, but we have to face the evidence that the purpose of these platforms look like it is not to make application programming easier, it is to “capture” developers in one of the competing platforms and force them to keep up with changes that seem relate to marketing rather than to actual technological needs.

I have had the same experience with an Ionic 1 app that will never need any upgrade, because 1) its feature set is limited in scope, 2) it has no bugs 3) it has thousands of happy users.
I just can no longer compile it, even with (purposefully) making no upgrade to the environment, because some of the run-time remote dependencies have been taken off-line. Meanwhile, my C, C++, C#, Java, and SQL apps still compile and run, whatever their age.

My main gripe is not about having to keep up with new tech, that’s great, but the lack of backward-compatibility could potentially affect thousands of perfectly happy users of a great app, because a new fashion causes them to break with no warning and irremediably unless they are ported to the new shiny toy. I believe the market (the users) will eventually decide which platforms will remain, based on what they want, not what the marketing department “du jour” wants.

2 Likes
9

It would seem to me that this grievance would be better directed at an Angular forum. At the end of the day, the Ionic team don’t decide how Angular is developed, they are providing a collection of helpers that make the development process simpler.

I think it’s extremely unlikely that I would start a new project on Angular but I would seriously consider Ionic.

1 Like
10

Sorry, but this isn’t just an Angular problem. Sure Angular has changes massively since Ionic v.1. The problem also is with Ionic pushing out a major release every 12 months with large amounts of breaking changes. The rate at which changes are made means you have a choice of

  • using the current version, and hope that fixes will be made to it.
  • or start a new project using the beta version (coping with all the newly introduced bugs) because by the time you’ve finished it’ll be released.

My heart sinks when I get an email from Ionic say “look everybody, we’ve released a new version” because I know that large amounts of what I’ve learned is now obsolete. Maybe I’m just spoiled that the Windows Forms code I wrote in VS2003 17 years ago still compiles without a hitch today in VS2019.

I appreciate that that’s comparing apples to oranges, but having v.5 introduce a tonne of breaking changes in an app I wrote in September 2019 does make me question whether I’m using the correct tools.

Don’t get me wrong. Ionic is a great framework and you can build some beautiful apps with it. I just wish it’d slow down a little and be a it more stable.

Warning - massively cynical thought! - I sometimes wonder if the reason behind these rapid release cycles is because some developers’ incomes depend largely on refactoring projects.

5 Likes
11

Unfortunately, your lack of detail makes it impossible to comment. All the changes I can think of were directly driven by the development in Angular so, if you are making an opposing point, evidence would be beneficial.

Just keep in mind, you may not need to have the latest version of the framework. If you are allergic to refactoring, maybe just stop.

12

Ionic1 to Ionic2 can be blamed on Angular. But not the breaking changes in Ionic 4 or Ionic 5. That is a self inflicted wound.

Main problem is that as soon as a new version with breaking changes is released, all maintenance on previous version stops. Or in case of Ionic 4, all maintenance/fixes on Ionic 3 stopped more than 12 months before Ionic 4 was released. Of course being able to support React was understandably important for Ionic team and they wanted to build Ionic4 for that, but why did that need to be a migration forced upon all exisitng Angular Ionic2/3 projects?

How hard could it be for Ionic team to allocate just one developer to continue with bug fixes and merging pull requests etc for Ionic 3 till Ionic 4 was ready for release and a few months after that?

You can see the release history of v3 here if you go back long enough:
https://github.com/ionic-team/ionic/releases

Last actual v3 release was 3.9.2 in Nov 2017. All the releases after that are just version bump releases with 2-3 bug fixes after every 2-4 months to make it look alive. Ionic 4 was released Jan 23, 2019.

My guess here - Ionic team remarkably underestimated the effort it will take for them to finish Ionic 4 - after all they were just refactoring stable existing code to do the same thing but structured differently. Instead of taking a few months it took them almost 1.5 years.

And then they remarkably underestimated the effort it was going to take for everyone else to migrate to Ionic4 - after all they were just asking for refactoring of stable existing code to do the same thing but structured differently.

Only people doing tutorials, blog posts and 2-3 page proof-of-concept build-and-throw apps can get so excitied to jump on everything new that comes out. More changes, more tutorials to sell, more visitors on blog.

You can look here at how long it has taken, and is still taking exisitng projects to migrate from Ionic2/3 to Ionic4 one full year after release - while all the tutorials/blogs claim its a 2-hour or 2-day job:

https://npm-stat.com/charts.html?package=ionic-angular&package=%40ionic%2Fangular&from=2016-06-30&to=2020-03-31

For any team working on a real app in production, finding a few weeks of time for migrating all the code is not easy. And then like any change - it is going to introduce new bugs which will need to be tested and fixed in a few more weeks before being able to release that migrated version. And during that period, the old app will still need to be maintained/updated/fixed.

Is that enough evidence?

By the way, Google is still maintaining Angular 1 - https://docs.angularjs.org/misc/version-support-status

4 Likes
13

I’m confused, I thought the issue was backwards compatibility but this response seems to focus on long-term support.

14

Either one could compensate a bit for lack of other, but Ionic provides none of them.

1 Like
15

Here is another issue I ran into today with Ionic 4 on iOS 10.

ionic4 ion-footer can’t display in ios10.3.1
https://github.com/ionic-team/ionic/issues/16328

Bug was reported on Nov 15, 2018 when Ionic4 was in Beta. It wasn’t fixed for 2 years, and then as you can see in the last comment, Ionic team decided to close it because Ionic5 has now been released which officially drops support for iOS 10.

Looks like they decided to not support iOS10 ‘silently’ long enough till it became OK to officially drop support for it.

@maxlynch1
Ionic is a GREAT demo of what is possible to be built with current latest state of the art - but it has become near impossible to deliver and support production apps with Ionic. It is very very hard to not LOVE ionic and appreciate all the great work they keep doing to push forward the cutting edge - which is great for building DEMOs. But building and maintaining anything beyond a demo has become more and more diffciult with every new release. They just don’t care about anything that isn’t all shiny and new, and that is the one and only ONE single negative thing about Ionic team that hasn’t changed in last few years despite repeated promises that NOW they understand and plan to be more responisble. I can’t think of any other reason to not love Ionic, but this ONE reason has caused us way way too much pain for way way too long :frowning:

Can you please please assign just ONE person in your development team with sole responsibility to test and fix issues on older platforms? If that becomes too painful for any single developer, rotate that resposnsibility among your entire team where everyone works on maintaining support on older platforms for 1 month at time, and then that responsibility shifts to next developer, and so on? Starting with your most senior developer and then on to juniors and fresh hires, but definitely not the other way round.

It will A) fix the support for older platforms, B) make your entire team a lot more responsible everytime they decide to break compatibility again.

2 Likes
16

Hi @torger,
So if they don’t need that much functional update, why not leave them in the version they currently are?
I know switching contexts from one app in Angular 1 to another in Angular 5 then another one in Angular 4123123 is a hard mental exercise, but maybe less hard and less costly than updating all those apps to the latest version of Angular and Ionic every now and then. And even then, when are you done with this work? Never?

Web-dev is going very fast these last years, so asking Ionic to wait for me or you may not be fair to them. If they do, other frameworks would leap forward nonetheless, and then you’ll end up with a dead framework, which is much worse.

I’m familiar with the telecom world also. There you might need to wait on your customers to update their systems so you can update your tech. And that creates a bit of a lag that slows things down.

In the web ecosystem, the internet does not need to wait for anybody.

Cheers!
Gustavo.

17

I agree so much. I recently challenged myself and started migrating my Ionic 3 app towards Ionic 4 and there are so, so many vital parts of the app that I should completely rewrite from scratch to make them work again. It’s literally easier to just build a new app from scratch, wow.

I guess this is the kind of stuff you only understand after using a toolchain/framework for a bit, unfortunately…

2 Likes
18

It’s even longer in the mobile world.

19

I’m feeling the same pain. I have an app I wrote in Ionic 1 / Angular 1.3. I’m currently rewriting it into Ionic 5 and Angular 9. It’s a rewrite.

But in the mobile world 7 years (since Ionic 1 came out) is a full generation. Almost no one carries a 7-year-old mobile device today. When PCs first came out, 7 years was a lifetime. That generation length has grown over time as the technology has matured. Mobile software development, and particularly hybrid development is still relatively new, and you’re right, there were some painful breaking changes to get where we are today.

That said, after putting off upgrading for a few years, I am loving Ionic 5. So many things have gotten smoother along the way, and TypeScript / modern Angular is a robust platform that will last longer than Ionic 1 ever did. Ionic 1 was a foray into this hybrid mobile/web dev world, and it worked well! But what we have available to us today is even better.

Hang in there.

2 Likes
20

Same frustration here. We started a big project using Ionic 1 and Cordova. Now we are migrating Cordova to Capacitor for obvious reasons and it is all good so far. But migrating from Ionic 1 to Ionic 5 for the UI layer and other features (Capacitor plugins for example) is a lot of work we are not sure it is worth doing. Our UI is still modern and functional and matches our web application. By the time we have an Ionic 5 application in production, there will be Ionic 6 or even 7 so let’s go and rewrite everything again…and again…