Ionic Native

Ionic is a framework for developing mobile apps. I've completed a few successful projects using Ionic. I like Ionic. I think that as far as cross platform mobile development goes, Ionic is pretty good.

Ionic was built on Cordova, and has been gradually moving away from it with Capacitor. I like Capacitor better than Cordova. I think they've done a really good job.

Ionic Native is a set of Cordova plugins that they've provided a wrapper for. If you look at the list, it looks very impressive. If you try to use any of them, though, it's a toss up as to whether you end up with something production standard. Some of the plugins there shouldn't be on the list because they're just broken.

The Local Notification plugin is a good example of this. Currently, it's pointing at the underlying Cordova plugin version 0.9.0-beta2. At the time of writing, this is around three years old. The most recent version is 15 months old. So not only is the plugin not actively maintained, we're also out of date even by the plugin's standards.

Unfortunately it doesn't work very well on modern Android operating systems. Trying to schedule a repeating notification causes the plugin to go into an infinite loop until the OS steps in and kills it, so the workaround is to set a notification with a large 'count'. This causes very slow interaction with the notification in future, presumably because the operating system is dealing with a notification instance per count. This is something you can work around by scheduling, say, 100 days in advance and making sure your app reschedules when you're getting close to the end of the 100 days. You shouldn't have to do this, but it's an option.

However, there's a much more serious problem in that the plugin can't schedule notifications that persist past the device rebooting. There are a few use cases where this may be acceptable, but for a general notification system, this is a deal-breaking limitation that you don't find out about until testing (and physically testing notifications is tedious and error prone enough already).

Then there's the in app purchases plugin. The IAP plugin is bizarre. When dealing with subscriptions, there is no way of simply querying whether the user owns a subscription, because the 'owned' field isn't reliable. When the plugin starts up, a subscription goes through a variety of states, but always starts with owned = false. Maybe it reaches owned = true, maybe it doesn't. The point is that owned = false is never a useful piece of information because there's no guarantee it's correct. This means that there is no completely reliable way of determining whether a user's subscription has expired. You have to look at the subscription billing period and be aware of when it may have expired, and if you go a certain length of time with successful communication with the plugin but without seeing owned = true you then assume that it must have expired. This is absurd, and I would be extremely surprised if the underlying billing library exposes subscription information in this way.

Ionic should not be providing wrappers (and exposure) for these plugins unless they meet a certain standard. It's a waste of developers' time to attempt to use sub-standard plugins and will fuel a perception that it's difficult to achieve production quality software using Ionic.

Update: Another one - Ionic Native Audio doesn't work with Capacitor because it hard codes audio assets as existing within the www/ directory. In Capacitor, this directory has been named public/ so the plugin can't find any of your audio assets. Again, why is this being advertised by Ionic, with Capacitor instructions?

See also Ionic Native quality issues.