Which ecosystem to build an app for first: iOS or Android?

We are building an app that caters to the B2B crowd, and our initial research has shown that our audience is split evenly among the platforms.

Both of us are non-technical co-founders so we will be outsourcing development.

Our budget is limited and just enough for starting with one mobile eco-system.

Which one should we go with and why? (iOS or Android)

Don't pick one, you can support both pretty easily.

Most applications don't require a native application. You can essentially make the "app" nothing more than a webpage, and then have a small shell that renders this webpage in the platform specific app. Android would probably use WebView (which is WebKit based) and iOS would probably use a WebKit implementation as well.

The specifics of it should be known, or at the very least, should be minor implementation details, to any competent development shop that you outsource it to.

The advantages of this are that you only have to pay for one application. When you first start, they spend a little time configuring the iOS app, and a little time configuring the Android app, and I'm not exaggerating when I say they will almost without a doubt have that working the very first day they begin development. After that, they work on the web, and whatever they do works in both cases.

Another clear advantage is that you get to push updates without them needing to go to an app store and manually update. Because it is a web page on your server (and you can easily get free hosting for this server on, say, Heroku) you can update it whenever you want. No waiting to be approved by an app store, no waiting for it to propagate to the app store's content servers, and no waiting for users to upgrade their app. You release the update to your server, and the next time they request a page, they get the updated page.

The offshoot of that last advantage is that you can do very small updates. With a lot of apps, you only want to update once a month at the most because people don't like updating apps. So if you have a couple small bug fixes, they'll have to wait until the next release. With the web-based model, you don't have to worry about that.

Another advantage is that they could use the 'app' from a computer as well, or I suppose from their mobile browser if they were incredibly sadistic like that.

Another advantage is that if they change devices they don't have to worry about losing their data.

Another advantage is that because you, as a responsible application owner, perform regular backups, customers don't have to worry about their phone falling in the toilet and their latest and greatest business data going to crap as well.

Now I'm certainly trumping this up, because it's a great model. There are some downsides.

A disadvantage is that there can be performance losses doing this. If you have a lot of processing, you'll either do it on the client (slower than you would with a native app) and it will be slow, or you'll do it on the server which might not scale, and will probably have a delay in it as well. In a lot of business cases, these delays are small enough that it doesn't matter and becomes an acceptable parameter of user experience. However, you'll need to ask yourself if the user is okay with a few seconds of delay on a regular basis. If they aren't, obviously this approach isn't for you.

Another is that it mandates a network connection. It can be a corporate network and be run completely internally if the client desires. Naturally they'd have to host the server in their corporate network for that to happen, but it can totally be done. But if you're dealing with field technicians who go to middle-of-BFN forestville, then it might not work for them because they just don't have cell or network capacity. It is possible to set up roaming stations on their laptop to connect to in an effort to mitigate this problem, and the laptop can fool the phone into thinking it's storing data (it probably wouldn't be able to retrieve data) which can be useful for data collection. When the laptop gets on a network again, it can proceed to upload the data to the central server. Your development consultant will be able to provide more information on this approach. If you're in an entirely urban environment this is almost never a problem.

I'm sure there's some pros and cons I missed, and you'll want to discuss the details of your application with whoever you choose to do the development. But in this case, I think we can agree with the young taco girl and say "Why not both?"

In case you've decided that you need a native app I can briefly outline Android and iOS strengths and weaknesses. You can also check this article: Native vs crossplatform: Which one do you need? to figure out whether you really need a native app. Remember, that native functionality is always more advanced, but mobile web is easier to develop and support. So your choice should be based on the number of factors.

Well, starting with overall statistics, Android is a more popular platform, but since you found out that your target audience is split evenly among the platforms, I think that main Android advantage doesn't matter for you. In terms of development and deployment, Apple would be more advisable: iOS apps take less time and money to develop. Android development is more complicated due to high fragmentation.

It's always easier to start with one platform and then develop for another. You can collect feedback and enhance overall UX before going any further. More details you can find in the original article.

Source: Android vs iOS: which platform to develop for first?

Android development complexity lies in its' widespread. Every company that wants to launch a device on Android make some changes in OS so developers have to create applications in the way they will work on ALL Android devices. Another thing is that Android devices cover a lot of screen sizes and resolutions so designers have to work according to them too.

A story with IOS development is a bit simplier. Just all IPhone and IPad screen sizes no OS subterfuges.

You can also read this and this for some more details