Ionic : The Good, The Bad and The Ugly.
Sunday, July 31st, 2016
In contrast to native app development Ionic provides developers an opportunity to build for multiple platforms from a single code base. As it is clear in the figure Ionic requires a total of 8 stages until the app is deployed on the app store. This figure accounts only for the front-end developer's work load. Since Ionic is built on top of Angular JS there are extra development stages which pertain to the browser(Chrome/Firefox). Because of this workflow the development timeline is much more longer than native apps.
The stages A to C are the least tricky to carry out and should mostly be used to decide last-minute functional or design changes that would not be possible later in the development process. The development process starts to get heavy from stage D. This is where most of the bugs for the browser are visible as bulk of the logic and styling would already be implemented. After fixing bugs for stage D developers will want to move to stage E which is the device testing stage. But this is where the app starts to show more signs of underlying bugs which are much more harder to debug. Every effort should be made by the developers to reach stage E as soon as possible. This will not only prevent any unexpected delays but it will also allow ample time to start fixing bugs on the device. From stage E to stage G is the longest part of the development process. This is also where huge number of bugs arise as specified in the graph. So fixing device specific bugs will guarantee smooth and functional apps. The last stage H is the finish line for the development process where most of the bugs on the device would be fixed. If the developer reaches the last stage within a specific deadline for the project then it shows that time was managed well for each stage. But if there were unexpected delays then time was not managed appropriately for each stage.
The Good: Cross platform apps with the same code base.
The Bad: A lot of cordova plugins don't work on iOS but work on Android and vice-versa. This eats up a lot of development time which could be used to polish the app.
The Ugly: The browser is not a reliable way to test functionality. Always test any changes on device before committing code. Everything might seem right on the browser but the compiled APK or IPA files will end up not functioning correctly.
Suggestion: Have as much device testing as possible between stages E and G for the target platform. It is also important to test with different device sizes and operating system flavors(Stock Android, Cyanogen..etc). This should be done in-house or contracted to other device testing service.