Ionic
Ionic is an easy to use, hybrid application framework utilising Angular 2, TypeScript and HTML5, with several well documented built-in components.
Speed and simplicity
Ionic’s nature makes the mobile development process easier and quicker, with little training required for Angular developers to get started. Code is written once and can be compiled into Android, iOS or Windows applications. It’s a great concept for speeding up and removing barriers to mobile development.
However, there are some drawbacks to using Ionic.
The web layer and performance
Performance is impacted by the need for a web layer over the native features. This isn’t a major issue for smaller applications, however it can impact when an application becomes more demanding on performance. Also, as much as the built-in components are very useful in saving time, there have some bugs, and customising them can feel excessively tricky at times. It’s just not so intuitive or simple to apply a personalised feel to an application built with Ionic.
Testing can be testing
A further, but minor, drawback I noticed is that testing during development is done quickest in the browser. To view code updates on a real device or a simulator, the project must be rebuilt every time. This is usually fine, but sometimes OS/device-specific errors or differences can go unnoticed, requiring several additional builds to rectify and test these issues.
React Native
With the above concerns in mind, I decided to look into React Native – which is frequently compared to Ionic and often preferred. I wanted to see for myself if the learning curve was worthwhile, and also get a feel for the differences, benefits and drawbacks of React Native compared with Ionic 2.
Better simulator integration
One of the first benefits I noticed is that iOS and Android simulators can be run from the terminal, and update with new changes instantly. This means that any device-specific issues should show right away, which should reduce the need for unnecessary builds and require less reliance on the browser which can render things differently.
Steeper learning curve
The second thing I noticed was the learning curve. Coming from an Angular 2 background, I was surprised at how different React Native is. Aside from the expected differences when using React instead of Angular, React Native also uses JSX in place of HTML – and has a few different rules for CSS, too. The toolbox you are given is very sparse compared to Ionic, prompting you to build things up from scratch, or select suitable components online, instead of using a built-in library.
Help via documentation
Despite the learning curve, I was able to find plenty of good, free documentation online. I had no issue building an application from this – whether accessing native device features, creating dynamic templates or doing a range of things in between. The learning curve is definitely manageable and simply requires an initial time investment. At this point, the appeal of React Native’s improved performance made the short, accessible learning curve seem very worthwhile.
Not so fast
I also began to notice that development time feels lengthier overall, which is to be expected without built-in components. There are a variety of good quality components available online however, and you can of course build up your own for use in future projects. Again, this points to an initial time investment, in order to become familiar with the best component options online, and to learn how best to build up your own collection of these. There is also the option of simply building from scratch when more suitable, and not using anything pre-built.
Despite React Native’s approach likely requiring more thought and time, it does come with several benefits. It prompts the developer to consider their best option and customise an application in a deeper, more tailored way, instead of automatically reaching for built-in components.
Platform publishing flexibilities and challenges
Another key difference is that React Native does not fully encompass the Ionic 2 philosophy of “write once, run anywhere.” In fact, there will be some differences in the code for compiling to Android vs iOS. This adds to development time, but is a deliberate way to encourage developers to write code more suited to the native platform. This can give applications a more native feel, and prompts you to write the code best suited to each device, in scenarios where quality could be compromised on one device but work fine on another. This is something that would occasionally happen with Ionic 2, and I think having the option to write different code for different devices so obvious and built-in to React Native is a smart move. However, this further increases development time and is ultimately less simple, so could devalue React Native over Ionic 2 when time is a more important constraint.
Horses for courses
Overall, Ionic 2 is a great option for reducing development time and simplifying the mobile development process, but in terms of performance, customisation and quality: React Native comes out on top. Ultimately, it depends on the project – will the increased time and skill investment for React Native be worthwhile, or will the improved performance yielded perhaps not make enough of a noticeable difference in your final product?
Personally, I concluded that Ionic is the simpler, better option for applications you wish to produce quickly and which don’t have a high demand on performance. However, I would definitely consider React Native the better option when very high-level performance is a must. Perhaps React Native is also better in situations where we have more development time, since it inherently encourages better customisation and better quality which can lead to an improved final product.
