The Headaches of Cross-Platform Mobile Development

snydeq writes "Increased emphasis on distinctive smartphone UIs means even more headaches for cross-platform mobile developers, writes Fatal Exception's Neil McAllister, especially as users continue to favor native over Web-based apps on mobile devices. 'Google and Microsoft are both placing renewed emphasis on their platforms' user experience. That means not just increased competition among smartphone and tablet platforms, but also new challenges for mobile application developers. ... The more the leading smartphone platform UIs differ from one another, the more effort is required to write apps that function comparably across all of them. Dialog boxes, screen transitions, and gestures that are appropriate for one platform might be all wrong for another. Coding the same app for three or four different sets of user interface guidelines adds yet another layer of cost and complexity to cross-platform app development."

Comments

If you're gonna do it, do it right

[s73v3r]

If you're gonna do cross platform app development, at least make the effort to follow the platform's UI guidelines. As an Android user, nothing irks me more than having an app with the iOS icons and navigation buttons simply copied over. I'm sure the same is true for users of other platforms.

Re:If you're gonna do it, do it right

[s73v3r]

No, I want people writing apps for my platform to be following the platform's guidelines. It's not going to kill them, and it makes the experience better for everyone.

Re:If you're gonna do it, do it right

[thegarbz]

In theory maybe, but in practice the phone's UI is an open canvas for developers.

There's no way of writing code that is portable between iOS and Android. If for no other reason than the different programming languages, there's also capabilities and methods used on one system which are not appropriate for the other. I.e. iOS typically places a back arrow on the top left of the screen, Android devices typically have a dedicated back button on their phones.

The problem is we expect apps to perform consistently on our platform. This requires the design guidelines for the platform are followed.

Realistically given how you need to recode your app in a different language there's no reason a developer shouldn't simply adjust their app in the process to meet the design guidelines.

Re:If you're gonna do it, do it right

[TheRaven64]

There's no way of writing code that is portable between iOS and Android

There are several ways. If you want something using exactly the same codebase, companies like Adobe will sell you development platforms that wrap the native APIs and give you something that doesn't quite look or feel native on either. A better approach is to use GNUstep-base to provide an implementation of the Foundation framework on Android and then rewrite your UI for each platform but share the model code.

We've been through this before with desktop apps. If you want a good cross-platform application, make sure that your code uses a very clean MVC separation and rewrite the UI part for each platform. Otherwise you end up with something that, at best, only behaves well on one platform, and at worst feels wrong on all of them.

One app to make, multiple to purchase

[phikapjames]

The one thing that irks me a bit about this whole situation is them complaining that they just can't write the code once and have it work across the different platforms, yet I'm still required to buy the same software separately on each platform. In my mind, you justify the cost to make it work for that platform by selling it on the specific platform. My opinion would probably be different though if I was able to buy the app once and not have to pay on each separate platform.

Advice

[ackthpt]

Keep it simple, Stupid

I'm developing an app which can be run cross-platform and/or mobile. Turned out to be a giant nightmare when looking at user experience on a tablet or smartphone. So .. I bailed on anything whizzy and went back to finding the basic html and javascript to get things done -- look and work consistently on multiple platforms and also be visible in sunlight (something a lot of apps fail miserably at.)

Re:Advice

[thegarbz]

So you're coding in the most inefficient way for each device to run your app then?

I feel for you. Your problem has been experienced by many who don't wish to rewrite that Objective-C app in Java, don't want to maintain two packages on different platforms without common bugs, and don't want to re-design your app so that on iOS it has a back button in the top left while on Android it obeys the hardware back key.

However before you continue I suggest you look at the ratings of apps on each market that are written in the way you're suggesting. Inconsistent with the native UI of the platform makes the app look .... cheap. An app that runs in HTML / JS is inherently incredibly slow compared to a native app which further upsets the user experience.

If you want to write a 5star app you'll likely need to abandon any hope of cross platform compatibility and simply code from the ground up for each platform.

Re:Advice

[xombo]

HTML5 supports offline caching of files as well as the SQLlite datastore, so you can provide a fully offline experience for users and even sync back with the server when a connection is available.

Re:lol, cry more, noob

[TheCouchPotatoFamine]

well.. not strictly true. IIRC iOS and android are both converging on (or already have) a view-based hierarchy... the way god intended. Personally i hate the signal-and-slots or win32 methods versus the DOM/events methodology - even if HTML's take on it is a little sprained... however, when i look at iOS, i see the DOM/event pattern, just without the xml (for the programmer, anyway, it's right there in the NIB..)

So?

[slapout]

Success requires effort. Nothing new here.

Follow proper MVC development and save time

[hsmith]

I built a rather extensive commercial App on iOS. By abstracting the data/business layers well, when going to android it was as simple as writing a lexer to convert almost all the code. What took me 1000 hours of development took 8 hours to port over.

The only thing that was really required was writing the UI, which was targeted for Android.

Thank You

[SuperKendall]

As an iOS developer, I heartily thank you for continuing to use cross platform development solutions that leave such a wide gap for someone to come along and write a better native app.

Mobile?

[slasho81]

This should have been: The Headaches of Cross-Platform Development. It's not just a mobile thing. Today, if you're developing any kind of client-facing software then it's not just Android vs. iOS vs. WinPhone vs. BlackBerry. It's also PC vs. Mac vs. Linux. with IE vs. Chrome vs. Firefox vs. Opera. And of course, all of these on different devices with difference capabilities, most notably different screen sizes and input methods, and deployment options. So much wasted time and effort.

We were on the right path with webapps for a while, but then suddenly native apps became all the rage. The worst "feature" by far of native apps is they have to be installed - the deployment issue is practically gone with webapps, but contained apps let you charge people for installation, so we went back to that.

I pray HTML5 manages to become a capable and dominant platform for the sake of both users and developers.

Re:Mobile?

[ceoyoyo]

Webapps are like cross platform apps, but on top of that they're crammed into a medium that was never meant for them, so instead of being just non-ideal they truly suck.

The only people who like web apps are the ones who don't have to use them (managers) and people who liked the idea of being able to get their e-mail anywhere, before everyone started carrying smartphones with... a native e-mail app.

My experience differs from yours.

[tlambert]

It's been my experience that you have a lot more control if it's a phonegap wrapped native app, than a browser app.

My experience differs from yours.

In my experience, phonegap provides JavaScript extension based access to information local to the phone without any controls on its use by a third party, by subclassing UIView and then going to a web page. This includes but is not limited to location information, any history files you have, your contacts, and anything else available to a sandboxed application.

If the software isn't intentionally malicious in the first place, the app developers tend to suck off all your information into their database with no malice, but with about as much thought to security as you would expect from someone who was unable to limit themselves to uploading only the information relevant to the running of the application. That is to say, very little.

Given the lax security already apparent, the sites that show up in the UIView are typically changed by malicious third parties in order to trigger redirection to a site that does then pull the information off for malicious reasons. Whether that's because the originating site's phonegap App web page was attacked through one of any number of security holes which the app developer already proved themselves incompetent to protect against through their use of phonegap in the first place, or it's done via DNS cache poisoning, links in forums in the applications, or a dozen other ways isn't important. What's important is that everything that phonegap exposes to JavaScript is now exposed to the malicious third party.

I understand the reasoning behind phonegap. It unfortunately doesn't apply in an unsafe world.

I hope that people who would perhaps want to use phonegap understand the security implications, and the fact that if you're caught using it, you get kicked off the Apple App store for exposing those APIs to third parties whose URLs happen to get displayed in the UIView on your web site, for whatever reason.

-- Terry