There's lots of cross-platform development frameworks for writing iOS and Android apps. I don't like any of the existing ones too much. Some I passionately don't like, some are OK-ish, but none are good, I feel. I'm working on a new approach to writing cross-platform mobile apps. I want to write a few posts about my thinking on this topic. And remember: I'm curious to learn about your thoughts as well, so please leave your comments and let's learn from each other! Important note: I'm explicitly excluding games and the like from the scope. I'm not in that business, and in that business completely different reasoning applies. For lack of a better term, let's say I'm talking about "business apps".

Priorities

Choosing the right cross-platform development toolkit is all about priorities. Are you trying to make an app for Android and iOS as fast and cheap as possible, for example for a marketing app? Or are you going for an awesome user experience? Do you want the iOS and Android app to be as similar as possible, or do you want them to align the the particular OS that they are running in as much as possible? Do you think "user experience" includes performance? Matching users' expectations? And of course: what skills do you(r developers) have?

Let's start by laying out some of my priorities. I'll talk about both sides of this coin: user experience and developer experience.

User Experience

In my previous post about continuous integration I explained that I always quickly setup continuous integration for any project. In that post I explained that it gives safety, allows for easier collaboration, and gives more confidence that things keep working the way they should.

In this post I'll tell you about a nice trick that I have used a few times to get insights from your continuous integration. There are many third-party services that facilitate this of course, and they do so in a much nicer way than I'll be describing here. But the thing is: you're not allowed to use most of those for commercial purposes or private repositories. And sometimes you just don't have the money to spend on things like this. So read on if you want to know how you can easily gain insights with all the tools that you already have, for free.

The end result

Let's start by showing an example of what we're going for. Below is a graph that shows two code coverage measurements over time. Each data point represents a build on the CI server. The graph is interactive and the CI server automatically causes the graph to be updated. After you have set everything up, there are no manual steps anymore.

In my daily work, I have the good fortune to work with many very talented people. Some are professional software developers, like myself. Others are for example researchers, scientist, project leaders, and so on. Is that you? Do you also write software, but not as your main activity? Do you have some experience but maybe no formal training? In this series of blog posts I will explain the best practices that I use, so that you may be able to benefit from them. So that writing software hopefully takes you less effort and gives you more pleasure.

The second thing for new code

The very first thing I always do when starting something new, is git init. Potential new hobby project? git init. Sample code for a blog post? git init. Doing programming exercises on something like Exercism.io? git init. And then I start using git the way I described in the first post of this series. There are virtually no exceptions to this; it hardly costs me anything and it has helped me plenty of times.

The second thing that I do, I do just slightly less often, but still very often: set up continuous integration. Obviously I won't do that for things that I never push to a remote. And some things that I push to a remote don't need it either, for example those Exercism coding exercises. But for anything that I suspect may have a longer life than a few weeks, including for that sample code for a blog post, I'll set it up.

What is continuous integration

In my daily work, I have the good fortune to work with many very talented people. Some are professional software developers, like myself. Others are for example researchers, scientist, project leaders, and so on. Is that you? Do you also write software, but not as your main activity? Do you have some experience but maybe no formal training? In this series of blog posts I will explain the best practices that I use, so that you may be able to benefit from them. So that writing software hopefully takes you less effort and gives you more pleasure.

A Creative Pursuit

A decade or so ago, I had the good fortune to work with a group of extremely smart scientists. Without going into details, their job was to conceive algorithms for image processing, and improve them. They had huge volumes of data, and the ability to create more. The algorithms had to be robust in the face of all kinds of variations in that data. Much like software development, their work was a creative pursuit.

They would have regular meetings to discuss progress, results and challenges. In those meetings, I remember being surprised now and then. For example, you might hear a conversation like this¹:

Betty: Say, John, didn't you have some progress on «some algorithm feature» a few weeks ago? I'm running into some issues and I think your findings may help me here.

John: Yeah, that's right, I remember having some results when I was working on «something else». I'm not sure which algorithm variant I used exactly though, or which test data for that matter. If it's important to you, we can sit together and see if we can reproduce that.