Cross-Platform Development Decisions

Screen Shot 2015-02-17 at 5.14.01 pm

I’ve started to port Show and Hide to Android. There’s still a lot to do, but I hit a milestone of having it working end to end on the emulator last week, which was exciting.

One of my friends asked if I was using any libraries to make it easier, and the short answer is no. But I think the long answer is potentially interesting so here it is.

 

1. I want to learn Android

I don’t think there is a better way to do that than building an app from start to finish on that platform. The more libraries and bits and pieces you work with, the more you learn the intricacies of that system, rather than the platform itself.

Sometimes that is exactly what you should be doing. There’s often no point doing something that has already been done. But cross-compiling isn’t re-implementing something that exists already, it’s choosing to write something a third way and hope it works well enough on both platforms (more on this later). At this point, if I haven’t written an entire app already, I don’t think I can really have the information to  just decide that cross compiling is the way to go. How could I compare the experience to a problem that I haven’t solved?

 

2. UI Code

Fundamentally there are two reasons why I don’t think we will ever have a good cross-platform UI solution. The first is that with major releases every year, it would be a huge amount of work to maintain such a thing. Almost no-one has the resources to run such a project, and of those that do even fewer have the incentive. The second is that the UI patterns on iOS and Android are different enough that what is “right” on one platform won’t feel “right” on the other.

 

3. Non-UI Code

Here I think there can be a good argument for a cross platform solution, depending on what you’re doing. Libraries like Parse are interesting, making it easier to abstract persistence and networking out and share it.

But – the core of Show and Hide on iOS is about 400LOC of optimised C code that is tied to the way that the platform represents images. I don’t even know if that would be possible to share x-platform, and the chances of it being performant enough for my purposes is vanishingly small.

Because it’s a relatively small amount of code and I deeply understand it, moving it to Android took only 1-2 days. I’ve yet to see whether it is performant enough, but this way I’m also in a much better position to optimise it.

 

Porting the Architecture

Instead of using cross-platform compilation what I’ve been doing is:

  • Building the UI according to Android best practises (or trying to).
  • Keeping (initially) the same function definitions for non-UI code.
  • Changing the implementation to make sense on the platform – e.g. the way that iOS and Android represent images are completely different.

This means that:

  • The two apps have very similar architecture – the same objects, with similar methods on them.
  • The unit tests are near identical: given this input expect this output.

It’ll be some time before I can declare success on this as a strategy, but I’m cautiously optimistic.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.