As a small (but growing) engineering team, being as efficient as possible with our development effort is massively important to us. We want to give our wonderfully engaged members, the best functionality we can as quickly (and as bug free) as possible. Hence as preparation for building our upcoming App, we wanted to review the pros and cons of Native vs Hybrid mobile development frameworks, and see how the latter lived up to it’s promise of write once, run anywhere.
TL;DR
Native won.
Approach
Each team member picked a framework and once provided with a supply of cake and beverages began working on building a basic Messenger-esque app. Development would continue in ernest for 2 days, where upon we would review experiences. Here’s how they got on:
Ionic framework is an open-source SDK for developing mobile apps. As it is based on AngularJS and Apache Cordova, Ionic enables building hybrid apps rather than separate ones for iOS and Android. Even though Ionic is a relatively new framework (1.0 was released in May 2015), it has fairly good documentation and tutorials. Also just knowing basic Javascript and HTML will get you started.
Setting up the developer environment was fairly easy, and done in just a few steps through NPM and Cordova (for Android and iOS platforms). Creating, building, and deploying apps can also be easily done from the command line. As Ionic is based on web technologies, it allows using a browser for development, making it a lot faster than having to fire up an emulator after every syntax fix. Ionic also provides a desktop app, Ionic Lab, to preview changes on Android and iOS, along with the ability to build, run, and deploy apps through it.
Ionic was very easy to get into. Even though I was not very comfortable with AngularJS (having only done a few tutorials and some random experiments), and had not used Ionic before, I got up to speed in a couple of hours. I managed to complete most of the target goals for the app and learned a good deal of AngularJS at the same time. While we won’t be using Ionic to build our mobile app, Ionic is definitely worth giving a further look at.
Anssi
React has been on my radar for a while now, and ashamedly I hadn’t got round to actually using it. Having just rolled out an Angular version of our members account area, this seemed like a great opportunity to try out one of the other “big hitters” in the JS framework arena. Along with React, I wanted to try Redux - functional (and especially anything immutable) programming is the new cool, and Redux borrows a lot from Elm which I had heard a lot of positive things about. The final piece in the jigsaw was React Native. This provided a javascript bridge that allows actual native UI elements to be created from special React components defined in JSX.
My initial experience wasn’t great, though this wasn’t React Native’s fault. I was trying to develop using a physical Android device, but kept running into issues with ADB dying/quitting/exploding. After spending several hours downloading various Android SDK’s and USB drivers I found I had an old version of ADB on my path. Bad times. Once removed everything began to work great. Remote debugging using Chrome and hot reload of code all worked well.
I liked the structure that Redux provided, although at times felt a little too heavy on boiler plate. This however wouldn’t be an issue for a more complicated application, just overkill for our little proof of concept.
Overall I found using React Native a positive developer experience. I do have concerns over the requirement to use “special” components for each platform, negating the “write once, run anywhere” mantra, but guess there’s not that much you can do about that if you want functional / UI parity with the target platform.
Will
The first day of hackathon was spent on familiarising myself with NativeScript, doing a couple of tutorials, trialling Telerik’s AppBuilder and then finally choosing to set up NativeScript dev environment on my local machine.
I used the Groceries sample app which is very well documented as a staring point to build my own Messenger app. That was simple and straightforward to begin with - you define the page layout in XML, add interaction using JavaScript and styling using a subset of CSS. But I quickly ran into simple problems that I would not expect to have - adding a logo image on my login page. I simply could not get the image loading - I tried all possible ways to add the image as per documentation and none worked. Another issue I had was debugging. I was using console.log() for this, which felt far from productive given that I had to run a build every time I made a change.
Writing logic in JavaScript was quite straightforward, but an app can quickly become difficult to work with and manage especially if you have to write a lot of custom functionality.
Overall, NativeScript was quite interesting to learn and work with on a small project, just like the sample Groceries app. I still have some concerns about app performance (some tutorial apps I’ve tested were running sluggish on my Android). I didn’t have enough time to learn the language in two days to give it a proper evaluation, but my main gripe with NativeScript based on my experience was the tooling and I don’t think it’s really suitable for complex apps. On the positive side the documentation seemed to be pretty good.
Dimitri
As a developer, who knows his way around Objective-C, I found Swift quite fascinating. It was my first time using it and learning at the same time. I found it easier to read, because it doesn’t have to differentiate keywords and types from C types using @ symbol.
Apple made a big change from Objective-C, dropping brackets that were surrounding methods and functions, thank you! It is also easier to maintain. You don’t need to declare functions in separate header files anymore. The compiler can now figure out dependencies and perform builds automatically.
The one thing, I found a bit confusing is the usage of exclamation marks or question marks. They introduced the term ‘optional chaining’ which is a process for querying and calling properties, methods and subscripts on an optional that might currently be nil. You specify optional chaining by placing a question mark (?) after the optional value and it’s similar to placing an exclamation mark (!) after an optional value to force the unwrapping of its value. The main difference is that optional chaining fails gracefully when the optional is nil, whereas forced unwrapping triggers a runtime error when the optional is nil. It can sound complicated but the Xcode is doing an amazing job helping you when you make a mistake.
If you want to make your first iOS app then go with Swift. I had more pleasure learning it than Objective-C, it’s less verbose, meaning you have to write less code. There are also some good tutorials and a nice playground to help you with learning. But once you get your head around Swift then, by all means, dig into Objective-C and learn both. There are many companies out there who’s codebase is written in Objective-C.
Tim
Conclusion
The first framework we ruled out as a contender was Nativescript. If you’re building your App around a 3rd party framework, you want to feel it has enough traction and support that it’s not going to disappear overnight (note…I’ve been stung before…https://en.wikipedia.org/wiki/AppForge). Nativescript does a lot right, but for us it’s too immature a technology.
Next to go was Ionic. Great documentation, good sized community, and a core technology built on Angular (which we’re using). Major downside is the implementation - delivering your app through a WebView is only ever going to get you so far from a performance perspective.
Lastly was React Native. Good documentation with a growing community. However still fairly immature (Android support only landed recently), and although Facebook is behind it, whats not to say it doesn’t become another Parse (https://parse.com/) and be deprecated.
So the winner is native. Both Apple and Google have invested heavily in their respective mobile SDK’s, and it shows. Open source is great, but does require a certain amount of the code > error > stack overflow > repeat cycle. Additionally unless you’re building a very simple application, you’re going to find yourself maintaining separate codebases for iOS and Android. Watch out for our forthcoming mobile app landing later in 2016!
Think we've got it wrong? Would love to hear your thoughts. Reach me on Twitter here
