Long-term betting on dependencies
Years ago, when I started planning my cocktail app, I looked at options for code re-use between Android and iOS. Critically, I knew it would take me a while to get the first platform release out so I was worried any tool I expected to use might be unmaintained by then.
I found the tool j2objc and it looked really promising:
- open source
- development funded by Google
- it was being relied upon by Google for most of their apps on both mobile platforms (plus the Web)
So, I could always adapt the tool for my own needs if it did get abandoned. But the maintainers had significant motivation and resources to maintain the project so that seemed like a low risk anyhow.
I didn't imagine Android and iOS would change so much in the time it took to get my Android app completed. Both platforms even changed their primary development language in that span along with a lot of best practices and recommended components. Even though both platforms do a great job of keeping their documentation up-to-date and the most relevant pieces easy to find, learning to develop on one of these platforms is challenging. There still is a lot of outdated information out there (be it Stack Overflow posts or an incredible number of tutorials) and there are stacks and stacks of components to learn. Expectations for modern mobile apps are really high so the number of details to get right can be daunting.
Then to build your app for the other platform you get to start all over! :)
Thankfully, my bet on j2objc proved to be a good one. It's actively maintained by very helpful developers and works as expected. I've completed most of the risky work in porting the core of my app to iOS and any work I do on that core benefits the apps on both platforms.
There are very few compromises I have to make because language features in Java map surprisingly well to both Objective-C and Swift.
But one important exception remained. I'll cover that in a subsequent post.