The number of companies doing mobile software development is rapidly increasing. Any company, even one that is past the proof of concept stage, will face following challenge — how to make sure the mobile product covers as much user base as possible. The two most commonly accepted options are:
1) Use of some cross platform development tools and frameworks like Titanium, Phone Gap, Xamarin (there are few more to name).
2) Use dedicated platform specific dev teams (one team per platform).
If you are adventurous and are starting fresh, the chance is you will go with option one.
If you are an established company with a steady revenue stream or have solid venture backing, you can afford the option two.
Both option have pros and cons.
Option one seems like a very reasonable choice, however your developers end up having to learn a framework like Titanium or PhoneGap and on top of that exposure to Android ad iOS skills will be necessary at some point anyways.
On the other hand, the second option, is arguably more expensive. In the long run, the first option will cost you just as much if not more in maintenance and in having to come up with platform specific hacks.
I would like to propose a third option, which will address the weaknesses of the previous two approaches.
There is huge value in building cross functional teams; I’m coming from a web development background. If you have the team, in which every developer can comfortably write CSS/JS/HTML as well as optimize SQL DB tables, that would be the most winning combination. Obviously, some people will be naturally better at the presentation front, while others will be more excited working with DB, but as long as anyone can cover for anyone else on the team — we are good.
The option that I’m proposing for cross platform mobile development is to build cross functional mobile development teams (X-platform team). Every developer on the team must learn at least 2 major mobile platforms — iOS and Android.
The company I’m currently working for was going through the same challenge as described above — using cross platform frameworks or hiring more mobile developers to maintain reasonable speed of delivery to cost ratio. While I’m not actively writing code any more (after more then 20 years in the trenches, I finally moved up the rank to a management position), I have decided to run a software development experiment to better understand the challenges of my company.
Just like most of us these days, I had an idea for a mobile app. Coming from WEB application development, I was initially hesitant to start learning a whole new programming concepts for mobile, and on top of that having to learn 2 platforms and 1 whole new language was some how not very appealing. At first, I was trying to get some friends, that already do mobile development, to get excited about my idea. But as you may have guessed, my attempt to employ them for free, did not have much success.
Finally, I realized — if no one will do it for me, the only option I have is to do it all myself.
So I challenged myself into learning iOS and Android. It took me a while (almost a year) -- I’m not as sharp any more and can only work on this pet project after hours. Along the way, just for the heck of it, I also implemented the backend Restful API in clojure (was always curious about functional programming, but could never find reasonable motivation to learn it). So, here is what I’ve learned doing all that:
Learning new development concepts these days is way different than it was 10-20 years ago. Back then, you would typically buy a book to get started. These days — there are simply no books that would be able a adjust to your personal learning abilities and style. And if you are short on time, you simply can’t afford to spend few weeks on studying a book. After doing some research, I ended up buying a few (I thought) best books on iOS development. But instead, I ended up watching free recordings of Stanford University’s lectures https://www.linkedin.com/groups/how-watch-online-IOSX-lectures-4856308.S.5791999172118851585?qid=efb3f917-2328-4b35-9b6c-a2a8a8f5781c&trk=groups_most_recent-0-b-ttl&goback=%2Egmr_4856308. I watched these recording at 2x (some parts 4x) speed which worked really well for me. I started watching the old version of the lectures for iOS 6, then the iOS 7 version came out and I had to continue on with that (often unlearning or relearning some previously learned concepts).
The most difficult part was to come up with reasonable MVC like approach so that I would be able to read my own code few days later and understand what’s going on. Learning Objective C blocks was scary at first, but at the end I really appreciated how non blocking UI (which is huge conceptual requirement for mobile apps in comparison to typical web app) can be implemented with Objective C blocks. Later I learned that in Android you can achieve the same thing by overriding methods dynamically, which is very different, but at the end was serving the same purpose. I could employ these different coding constructs in two different platforms without changing the structure of the application.
I ended up separating all backend access logic into functor classes with a bunch of static methods. This way I was able to keep the UI logic totally separate from the business logic; as it should be. In order to avoid low level networking coding, I chose the AFNetworking library, which was an excellent choice, though, as I was preparing for my first release, the AFNetworking 2.0 version came out which was quite different from the first version, so I had no choice but to migrate to the latest and greatest. Having to upgrade to a non backwards compatible version of the library the last minute is not the most pleasant experience — but I would highly recommend doing it, the benefits of not having to maintain the old legacy library outweigh the time and effort spent.
When the time came to learn Android, it was a bit easier for me, because I already knew Java and I didn’t have to learn a whole new language, the backend API was already developed and more or less stable. I also knew exactly what the application needed to do from a UX and a business point of view.
There was the same issue with learning material availability for Android — these days things are moving so fast, it’s simply impossible to come up with a book that is up to date. I ended up learning mostly from StackOverflow posts.
The fact that I already had the Model class’s encapsulation defined helped a lot; I simply copied the model classes from Xcode to Android, and translated the method declarations from Objective C to Java. The implementation of these classes was a bit more trickier but still pretty straight forward. I used the loopj android library for asynch networking which was a very good option to avoid writing low level networking code.
When you are implementing the same application in two totally different platforms, you really should keep the structure of your app the same as much as possible. Having shared backend APIs definitely helps. You should also consider naming all your major classes the same names (with adjustments to platform specific naming conventions). For instance, if I have a class called SignUpViewController in Objective-C for iOS, I would have the SignUpActivity class in Java for Android. This is, one of the best benefits to be able to code in two totally different platforms. If you can master doing this — your code structure will be clean and easy to follow. The trick is to really keep things in synch. If you are working on a new feature for Android and have to add a new API method and corresponding model methods, instead of waiting for someone who knows iOS to add it — add it to Objective-C yourself right away.
Releases is another thing you would want to keep synchronized as much as possible. In other words, if you are releasing a new feature for IOS and the version number is 4.3.1, make sure the same feature is implemented in the release 4.3.1 for android. This will make it very easy to keep track of what’s going on from project planning perspective. One of the most annoying things about IOS distribution model is that you have to wait for 5-6 days before your application is released to the world. However, this can be looked at as an advantage which helps to keep releasing the same functionality for different mobile platforms in staggered way. For instance, if you just finished working on release 4.3.1 for IOS and just put it on the iTunes store for approval — you’ve got whole 5-6 solid days to implement the same features on Android. This is exactly the best time for the developers to switch gears and forget about IOS for few days and work in totally different environment on the same features. Doing it this way encourages your to plan features in more agile way (smaller sprints). It’s not the requirement, but, this is a way cool that you could release IOS ad Android features at exactly the same time and, I’m sure, some of your users will think the same.
I don't have to argue about the benefits of test driven development. One of the most difficult things is to identify sufficiently correct set of test cases and scenarios, which will not become a burden on maintenance down the road, and will serve as a safety net in reducing technical debt. Honestly, I have not used any of TDD on my first mobile project, but, I would assume, just like with the Model classes example, doing it for one platform, would make it a straight forward effort to convert to theother. However, if there are two developers, each working on different platform at the same time, there is a natural tendency, that each person will have a slightly different view of what tests are necessary to write. This would have never happened, if the same developer would work on the same feature for both platforms.
And to wrap it up, here are few conclusions:
While it's possible to implement cross platform mobile project using special frameworks or hiring platform specific expert teams, the X-platform team approach is another viable alternative and I would encourage everyone to seriously consider it. This approach is a bit counterintuitive, just like, for instance, eXtreme programming at first. The only way to validate the claim is to give it a try. Yes, there is certain risk involved, just like with anything that requires a culture shift (eXtreme programming is perfect example), but, if it does not work for you -- you can always fall back to one of the other 2 development models. Implementing X-platform team approach does require effort, things will not happen automagically, but, things like naming convention, little bit of discipline with some passion will help to succeed. Make sure to find developers that are willing to learn at least two platforms. It’s OK if someone knows only one platform to start, but the requirement is that people should be able to work comfortably on any mobile platform at some point.
It’s always a moving target, the key is to never stop learning and improving, which is a basic agile principle.If anyone is curious about the code I’ve been working on, or for contact info visit here https://github.com/echowaves — it’s all open source.