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

eh

[Anonymous Coward]

I'd personally call them migraines.

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

[TheCouchPotatoFamine]

well then... sounds like a problem for tool-makers (jquery mobile auto adapting, perhaps?) then app-makers...

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

[Anonymous Coward]

the tools are available, lazy programmers don't use them.

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

[Anonymous Coward]

wut?

That's not how cross-platform apps work. Cross platform apps (see Adobe) have a consistant UI, no matter what they run on. Some exception may be taken to make it align with the underlying OS's visual theme system, but that's usually limited to the "titlebar" piece of the application and not the menus.

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

[Anonymous Coward]

And nothing irks me more than users of any system expecting everything to work exactly to same with all the bells and whistles attached. F-ME for being a web developer that's had to deal with the nightmare that was (and sometimes still IS) IE 6 and the fucking "it doesn't work on my iPhone."

Sometimes, for production time purposes, and the rampant demands (re: bitching) of users, we have to take fucked up shortcuts to make things get done.

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

[adamgolding]

What are the tools?

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

[Anonymous Coward]

Do you not know how to read? He wants the UI the same across all apps of his device, meeting the UI guidelines set my Google for Android.

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

[Darinbob]

Too many youngsters who've never encountered "portability" concepts before? Are we going to get yet another push for a one-world-os just so people don't have to think so much?

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

[hitmark]

Is the back button there pr app in iOS, or OS provided like in Android (either hardware, or optionally, as one move to 4.x, software)?

If it is OS provided in both, i am not sure i see the problem. Unless one worry about putting a in app ui element confusingly close to a OS element.

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

[Anonymous Coward]

Please spare us your software entirely in future then.

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

[thegarbz]

I believe it's manually coded but all I have to base this on is that many apps implement the back button in different ways, and some don't have it at all. Not sure if it's part of a standard API.

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

[Anne Thwacks]

No! its you that that is not doing it right!. If I have an xPhone, the apps that run on it should comply with the xPhone UI. I don't give a toss If the same app works on a yPhone, or what it looks like when it does.

Hopefully, the UI is implemented in the OS in both cases anyway, and all I have to do is call an API to get/put information to the user.

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

[kaladorn]

Yes, there are some key differences.

On the other hand, when peole talk about not being able to write portable code, that's generally only true with some particular portions.

For the most part, the sorts of interactions available on touchscreen devices are similar. If your code accomodates that in a sensible fashion, the details of the particular language or smartphone API particulars should only constitute a limited portion of your app which is truly distinct from OS to OS.

If this isn't the case, you are making some architectural mistakes.

I'd also like to say apps that don't follow platform UI guidelines should be scorned. It's okay if the platforms eventually lean towards one another (much like OpenGL and DirectX did) but whatever standards a device supports should be implemented. Doing something different just because you can or its easier for the coder is a pretty crappy way to write software.

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

[mgblst]

No, it will not kill them, but it may mean it takes an unacceptable amount of time to do, and cost way to much.

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

[beelsebob]

Absolutely not, the problem is that the tools, just like cross-platform desktop UI tools can't handle this.

A layout that makes sense on one platform might be complete bollocks on another; a gesture that's entirely sane on one platform might make no sense at all on another; a widget on one platform might support more modes than a widget on another.

The solution is to stop using cross platform UI tools, code the back end dirty work of your application once, and then write several UI layers to interface onto it.

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

[beelsebob]

No, that's exactly how bad cross platform apps work. Good ones code the back end once, and have a different UI module for each platform interfacing onto it.

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

[Anonymous Coward]

Amen! If it weren't for users, software would be so much better!

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.

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

[JAlexoi]

Android devices typically have a dedicated back button on their phones.

All android devices have a back button, software or hardware.

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

[TheRaven64]

The problem is thinking that portability is an all-or-nothing proposition. The choices aren't just 'recompile your codebase for every platform with no porting required' or 'rewrite the entire thing for each platform'. Most software is 90% model, 10% UI, and you can quite easily share the model code between different systems, you just need to rewrite the UI and maybe some of the platform integration code (e.g. accessing the calendar store), which you can do from the rest of the code via a thin abstraction layer.

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

[jo_ham]

This post getting +5 insightful perfectly encapsulates what's wrong with many software developers.

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

[BVis]

No, it encapsulates what's wrong with project management in this industry. Failure to manage customer expectations and setting insane production deadlines isn't the developer's fault, it's the fault of the management layer that *should* be between the client and the developer.

Of course, in an ideal world, there would be someone there. There frequently isn't, or there's someone so ineffective there that it's *worse* than nobody being there. In those cases, the developer should be looking for a better job.

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

[Anonymous Coward]

As the sole developer and graphics artist on an iOS (both iPhone and iPad) and Android (phone and tablet) program for anesthesiologist I must agree you have to do it right for each platform. iOS folks don't want to see Android UI, Android folks don't want a back button on the screen when they have one provided by hardware on the phone and along the bottom of the screen on the tablet.

Switching between the platforms during development and testing drove me a bit nuts as I get used to buttons being in one place on the Android then someplace else on the iPhone but for an iPhone only person me moving them to that Android location would annoy the heck out of them. When I write Java on the Mac vs Java on the PC I don't do [OK] [Cancel] on the Mac to force a PC look.

I wrote the program twice, native both times. Why? It makes heavy use of SQLite and needs to cache a lot of data for CPT, ASA and Diagnosis code looks ups. Not something that HTML5 was going to be able to handle. The objects between the two are very similar. While I prefer Java over Objective C and find Eclipse a much better IDE than Xcode (please add some decent refactoring and thank {deity of choice} for AppCode) I was able to pull off both sides. I wrote some custom controls on both platforms to solve things where neither had a really good solution.

Would I like a single solution? Hell yes. One code base would cut down a ton of potential bugs and QA time. But that one solution better look right on both sides and not be some NEW look.

There were things that were really easy to do under iOS so I did them there then forced myself to solve the problem on Android. I was able to prototype and develop faster on Android and did things there that are difficult under iOS so I forced myself to come up with a solution there or to find an alternate way to do it on both each time making the program better across the board.

While they complain about fragmentation on Android I found knowing that it could run on a variety of hardware in a variety of resolutions made my code much more generic. When we first got a tablet the code ran the first time. I did my best not to hard code anything resolution dependent. Same as you code for a PC or Mac desktop. Under iOS I found so much of the on-line examples hard code resolution or the size of screen elements. I hate that. I had to adjust my universal binary to run on both iPhones and iPads. As an example the toolbar is 32 pixels tall or 44 pixels tall depending on orientation on the iPhone but always 44 pixels tall on the iPad. I had to add various special checks.

If Apple would ever decide to change the resolution of the iPhone or iPad screen - and I am not talking about retina vs. regular as to the programmer you don't get to code against the extra pixels on retina, you just get to use higher res graphic assets - there will be a TON of broken applications. On the Android side they release new devices resolutions often - probably too often - but code runs properly as nearly all developers know there is "fragmentation" so they code generically just like you do on a PC.

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

[s73v3r]

No, we're not. I think we should have a push for developers actually heeding the design guidelines of the platform they're developing for. No more of this iOS back button in Android apps bullshit.

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

[Anonymous Coward]

http://www.rhomobile.com/

http://www.phonegap.com/

what?

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

[s73v3r]

If you've got the time to make the app, you've got the time to do it right.

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

[Anonymous Coward]

Yeah, I can see why you hold this view, but it's naive. Cross platform on mobile mean that when you hit the menu button that the iOS version's menu appears where and how iOS app menus all do and that the Android version does it how all other Android versions do.

After all, most of your userbase doesn't have more than one mobile platform. You stay consistent with the platform, not your "app".

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

[santiago]

Cross platform apps (see Adobe) have a consistant UI, no matter what they run on. Some exception may be taken to make it align with the underlying OS's visual theme system, but that's usually limited to the "titlebar" piece of the application and not the menus.

Ah, yes, the "Write Once, Suck Everywhere" approach.

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

[Anonymous Coward]

Mr Kristopeit?..

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

[shutdown -p now]

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.

Why would you need GNUstep to share model code? Just write it in C++.

lol, cry more, noob

[0xdeadbeef]

It isn't hard to learn another UI API. They're all fundamentally the same.

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..)

Re:lol, cry more, noob

[Anonymous Coward]

well.. not strictly true. IIRC iOS and android are both converging on (or already have) a view-based hierarchy...

Yeah, it's taking a while though, since they have to wait until they can count all of their overlapping patents on each little trivial addition, launch a barrage of lawsuits at each other, and settle out of court.

Re:lol, cry more, noob

[gatkinso]

Who said it was hard?

What it is, is a royal pain in the ass. So where is your unified API that wraps all of the Android, Kindle, iOS, and Windows devices allowing a body to write once and deploy everywhere, having said app look and act like a native app?

Oh, that's right. I should have figured: up your ass. Right there beside your head.

Re:lol, cry more, noob

[shutdown -p now]

Personally i hate the signal-and-slots or win32 methods versus the DOM/events methodology

What, exactly, is the difference between signals & slots and DOM events, except for the fact that the latter require the listener to be an object implementing a specific interface, while the former can directly hook up any method with compatible signature? (i.e. less boilerplate)

It sounds vaguely like you were trying to compare signals/slots versus MVC, though of course they are largely orthogonal (in signals/slots framework, controller is what provides the slots).

And I have no idea what "Win32 methods" is supposed to mean.

Re:lol, cry more, noob

[gatkinso]

That's exactly what you get - my load in your mouth.

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.

Re:One app to make, multiple to purchase

[aaaaaaargh!]

You have a point if the app is a commercial product developed by a company with several employees, UI designers, and the resources to maintain different source trees. However, for individual developers being locked into platforms (and platform-specific languages as in iOS) is more than just a minor nuisance -- don't forget that for many applications most of the development time nowadays is spent on GUI and packaging instead of the actual functionality.

Consider it that way: If it were possible to do real cross-platform development for mobile OSs then you'd have many more apps to choose from and more of them would be cheaper or free.

Of course, large companies like Apple, Google, and Microsoft really do not want this to happen. They want to lock in their customers forever and prefer to sue each other for years to come. Just don't tell me this is to the benefit of the end consumer.

Re:One app to make, multiple to purchase

[Anonymous Coward]

I don't get it.. you are saying that developers shouldn't strive to reduce overall development overhead of trying to over-tailor to each system.. which would allow them to lower their operating costs.. which in turn may eventually lead to them offering "buy once, download for any platform" policy for specific versions.... just like some software vendors do for the PC and Mac...

Re:One app to make, multiple to purchase

[Anonymous Coward]

Except that Google's Android doesn't have to use Google, so really, they don't care too much (see Kindle Fire). Considering that some Android devices come with absolutely no Google branded software or products (asides from the base Android OS) and all system applications are written in a manner than any developer could do the same, I'd argue that you're not being locked in quite as much with Android.

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

[s73v3r]

Here's the thing: Is your thing a website, that I access through the browser, or is it an app I purchase (or just download) in the platform's market? If it's the first, then ok. If it's the second, then that will just suck ass.

Re:Advice

[Anonymous Coward]

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

Re:Advice

[Anonymous Coward]

All phonegap apps I've ever seen have looked like shit, run like shit and been voted as the shit they are. Phonegap is a crutch for people who can't code worth a damn, to help them spread their shit around.

Re:Advice

[Anonymous Coward]

Agreed. I've been hunting and hunting and hunting for an example of a truly good phone gap app. Still hunting.

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

[DaleCooper82]

So, how do I use your app/read data while offline? In airplane for example? Roaming users will kill you for extra costs, etc...

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:Advice

[Anne Thwacks]

Its simple: if you dont want to support Ford users, only market a product for GM users. Those of us that drive a Mercedes don't want your half baked products anyway!

Re:Advice

[AJH16]

Except that, as the article said, users drastically prefer native apps to web apps. If your idea of a mobile ui is to make a site and use that in a hidden browser, you are setting up a path for user disappointment. That said, implementing and managing a couple of different object view front ends on top of a solid object modeled back end is not a big deal. Are there some frustrations, sure, but I haven't really found it to be a significant issue. The bigger issue is that in general, a lot of the current tools for implementing the UIs suck hugely. (XCode, I'm looking at you.) Systems like MonoTouch and Mono for Android work wonders for making the backend go across platform smoothly though, leaving only the UI to be a nuisance.

Re:Advice

[AJH16]

My experience has been you are far better off to split the difference using MonoTouch and Mono for Android to do a common backend and then using native UI. Phonegap is an interesting idea, but it tries to map a little too directly to be able to optimize well and it sacrifices too much UI control.

Re:Advice

[shutdown -p now]

There's no fundamental reason why an app written in HTML/JS can't have native look and feel or work "incredibly slow". Most apps don't do heavy CPU-bound computations, so JS perf is not really a problem. And UI fidelity is only as good as you make it - problem is, most people using HTML for UI just don't bother to actually make it look good.

Even so, GMail app is actually pretty good and "native looking" for being HTML, and that's just one example.

Re:Advice

[thegarbz]

It's not the heavy CPU-bound computations. Its the way the OS handles the rendering of the system. One of the biggest gripes people have with Android already is the lack of 2D GPU acceleration leads to a slow and laggy UI. iOS would be a classic case here with a high priority GPU accelerated UI you'd see a massive difference, But even without 2D acceleration it's often quite easy to see which apps use the APIs provided to render their UI, and which rely on some other means. While I agree there should be little performance difference, the reality is unfortunately the opposite.

Re:Advice

[shutdown -p now]

Are you saying that iOS browser rendering is not hardware accelerated?

Re:Advice

[thegarbz]

I'm saying that the OS provides an API for rendering an interface that is both hardware accelerated and given high priority especially to ensure user interaction is fast as smooth. I'm saying that the lack of this is a major complaint on Android. I'm also saying that by distancing yourself from this API and instead use an API from an embedded app to render your UI is not going to be as fast or as smooth regardless of how good a coder you are.

Re:Advice

[FireStaRT8r]

I have been spending lots of time on Windows 8 so my response is limited only to that platform. HTML5, js, etc are all NATIVE on Windows 8. The UX feels the same whether it is XAML/C# or HTML5/JS. IOW, your web app is a local app.

Re:Advice

[AJH16]

You are confusing native and local. Javascript is not and will never be native. HTML is not a programing language and can never be native. Local means that the assets reside on the device, all the platforms support having a local interpreted app. Native means that it is using system APIs directly to render to the screen and runs much closer to iron. Native and local js/html apps are not the same at all. Native benefits from better runtime optimizations, better compiler optimizations and runs closer to the processor in any decently designed system. Bypassing the (rather ugly) layer of overhead that Javascript and HTML imposes allows for a more pleasant and responsive user experience and this is exactly why the above mention trends show that users drastically prefer native apps even though they don't understand what the technical differences are.

The past repeating itself?

[Anonymous Coward]

The splintering of the smartphone market seems to be almost identical to the splintering of the Unixes in times gone by. I wonder what it will take to "unite" them - perhaps the rise of another Microsoft? Perhaps some flavor (or flavors) of Linux will rise to the occasion. Or, perhaps right now there is a young Finnish college student writing a new OS even as I type...

Re:The past repeating itself?

[viperidaenz]

I wonder what it will take to "unite" them

Nothing. They dont want to be united. The "app" ecosystem is a competitive advantage for the OS. If all the apps are available for all the platforms, its no longer an advantage. Where do you think the "There's an app for that" slogan came from?

Re:The past repeating itself?

[Noughmad]

Or, perhaps right now there is a young Finnish college student writing a new OS even as I type...

I had high hopes in some Finnish guys, but then they sold out to MS.

However, there is still hope with Qt, as it runs on both Android and iOS. I don't know how well it runs, or how integrated it looks, but it's possible.
Android: http://sourceforge.net/p/necessitas/home/necessitas/
iOS: http://qt.gitorious.org/+qt-iphone/qt/qt-iphone-clone

Re:The past repeating itself?

[Lennie]

How do you mean an other Microsoft ? It could just be Microsoft.

Re:The past repeating itself?

[Anonymous Coward]

Where do you think the "There's an app for that" slogan came from?

Apple marketing deciding to make "apps" kewl, rather than people just going to a webpage to do the same thing.

HTML5 & Weever Apps

[Anonymous Coward]

In the meantime, cross-platform, easy-to-develop HTML5 app frameworks are showing astonishing growth. In the least week alone we've seen three new Javascript + HTML5 frameworks released. And while it take consumers some time for consumers to get wise to the AOL-like 'we are the only (mobile) web' branding that Apple has established - the marketing advantages of one app that works across all touch phone and tablets and is actually affordable is pretty undeniable today - especially as web-app technology continues to mature.

At Weever Apps (disclaimer, I'm the lead designer) that's the goal: disrupt the expensive, case by case, walled garden model and produce useful apps that actually meet the end-goals of most organizations. We started as a couple of not-for-profit oriented programmers that just couldn't stand how bad the current mobile/web/app situation was out there - our clients couldn't afford a proper mobile experience for their constituents, and that pissed us all off...

Today, we've grown. We've hooked into amazing, established open-source web technologies like Wordpress, Joomla! and Drupal, created an open API and new RSS spec (RSS3 for semantic/web relationships, find it on github) and basically proven that web innovation can outpace mega-companies - we know this, because we're doing it and winning over former native-app clients. And are *web* apps are still affordable, useful and *accessible* to the at least 3/4 of companies that haven't 'gone mobile' today because of a combination of cost, utility and just sheer confusion with all the per-platform options out there.

Check out "Why I make web apps" by our lead programmer Rob Porter:
http://webweaving.tumblr.com/post/15651092883/why-do-i-make-web-apps

Or just get a free app at http://weeverapps.com if you're interested. We're new and still adding lots of features - but I can confidently say that we're proving that there are better ways than the status quo to add value to the web and mobile - and we're not the only ones doing it. :)

The Horror: Competition

[yeltski]

This is most horrible! Interfaces are competing for usability and user experience and you target one platform at a time and pay attention to detail and nuance at that!

Re:The Horror: Competition

[Anonymous Coward]

Making money isn't as easy as it was a few years ago when you could just release your iFart app and be a millionaire overnight...

Not that bad

[t00le]

Check out LiveCode Runtime Revolution and you'll quickly dismiss this complaint, it has support for almost all desktops, tablets and mobile phone platforms. Write it once and it compiles for the platform in native code.

We use the hell out of it for the reason discussed above, not to mention that it allows you to build attractive cross platform products.

Re:Not that bad

[viperidaenz]

Can't Apple reject your app if it has been written in or translated from anything but Objective-C?

Re:Not that bad

[t00le]

Apple can reject your app for any reason they seem fit, whether right or wrong. We have written a handful of apps that are on the market with RunRev, three were approved without issue and two were rejected.

Re:Not that bad

[icebraining]

They changed that policy in late 2010. http://daringfireball.net/2010/09/app_store_guidelines

Re:Not that bad

[Anonymous Coward]

You mean the LiveCode whose Android support is pre-release? Wow, I'm sure it works awesome. And no Blackberry or Windows Phone support? Sweet!

Fucking shill. There are some decent cross platform tools out there, but Livecode is not one of them.

Re:Not that bad

[Anonymous Coward]

If you not writing you app in C C++ or Objective C then don't even bother.

Re:Not that bad

[tlhIngan]

Can't Apple reject your app if it has been written in or translated from anything but Objective-C?

It's not a rejection criterion anymore. Apps can be coded in any language (including Flash), with the exception that no external code may be downloaded. C++ was always accepted, but JavaScript, Flash, C# are all acceptable.

The general method is to stick all your core logic in a C++ module and then interface to that the UI code. Then cross platform porting involves rewriting the small UI core. Obj-C can call C++ objects trivially (native function call). For Android, it's done through JNI, but supported via the NDK. For Windows Phone, it's a bit more difficult since the core may need rewriting in C#.

iOS encourages MVC development, and doing it properly means it can be trivially ported.

Re:Not that bad

[cbhacking]

Slightly off-topic, but an interesting point:

Windows Phone 7 does actually allow C++ in apps. You have to wrap the API using COM, but that's not hard - an hour of work at worst, once you have the development environment set up - and after that the managed part just uses the ComBridge API (P/Invoke is not supported) to load your COM library and can call into it trivially.

The catch: ComBridge is not publically documented, and unless you get an exemption from MS your app will be rejected if it uses it. There are a few published third-party apps that use native code, but they're the big names and the must-have apps, not your personal run tracker or whatever. Part of that is because it's much harder to verify any kind of correctness with native code - things like memory leaks and security vulnerabilities are a real risk - and partially because the phone's security model doesn't entirely encompass native code (for example, using native code you can create an app that screen-scrapes other apps, or reads potentially sensitive device information).

Re:Not that bad

[shutdown -p now]

For Windows Phone, it's a bit more difficult since the core may need rewriting in C#.

There is a trick you can use for that - this basically entails writing the core logic in a subset of C++, such that it can be compiled both with C++/CLR in /clr:safe mode (giving you verifiable assemblies that'll work on WP7), and with any C++ compiler to native code on all other platforms. You need platform-specific macros for classes and structs, and template adapters for object references, arrays and strings to make that work. And this won't let you compile pretty much any pre-written C++ code (so you can't use external libraries), so it's not nearly as useful in practice - but it may help for simpler apps.

Of course, given the current market presence of WP7, few people actually bother to do anything - and I suspect it will remain that way unless and until native code is properly supported on the platform.

Re:Not that bad

[shutdown -p now]

You may also find this interesting. It's much more narrow in scope (not just any C++ would work), but it gives some semblance of code portability, and it can be used in apps submitted to the store.

Why don't...

[uranus65]

...Google and Apple merge already and get it over with.

Re:Why don't...

[Anonymous Coward]

That would be awesome news for Google, but what will Apple get from that merger?

Re:Why don't...

[Anonymous Coward]

A lot of spyware!

Just do it!

[Anonymous Coward]

Shirley, we can just get together to agree on an abstracted standard api to sit on top of each platform or the compiler or ide or writing bindings for a few languages or something?

When we have the standard, the community will help write any code needed, mostly starting with the most popular urgently needed stuff.

Everyone wins. All the consumers get more apps. The businessés get work done for free and the developers can work more efficiently.

The beautiful open source world of computing is really enabling exiting new technologigal advances for all of humanity at an impressive rate!

Oh, wait...

Re:Just do it!

[Lennie]

Ofcourse not, just look at Apple for example. Apple marketshare would decline. They have expensive devices than Android. But more apps.

So?

[slapout]

Success requires effort. Nothing new here.

Re:So?

[Herkum01]

... and standards do not define success only consistency!

Re:So?

[thegarbz]

And success is often dependant on consistency. People favour apps that are predictable, familiar and easy to use.

Re:So?

[GauteL]

I hear you. But it would be preferable if we could spend our effort on something more constructive than dealing with idiosyncrasies of different platforms. This could be a solved problem if the different platforms weren't more interested in vendor lock-in than advancing the state of the art.

If I can only see the back of the dude in front of me, it is because I'm standing on the shoulder of a midget.

SENCHA TOUCH or JQUERY MOBILE

[genemang]

I like Sencha Touch because it's a true "application" and has a full robust architecture. JQuery Mobile is not as robust, but it too is a good alternative. I've already written two mobile apps using Sencha Touch, and didn't have to pay these OUTRAGEOUS 30% fees to these greedy walled garden monopolies. Mobile Web Touch Application Javascript HTML5 frameworks are the way to go for applications that can feasibly be written using them. For games, you are SOL. For LOB apps, it's a no-brainer to use Sencha Touch.e

yeah, and...?

[DynamoJoe]

So platform diversity is great until you have to code for it? I'm not seeing a problem.

srsly

[Anonymous Coward]

Numbnut UI designers get paid good money to put together some interfaces, and then complain that "it's too hard"?

Have some cheese with that whine. Or, even better, quit your job: start living an honest life and stop taking your bosses' money, you lazy boob.

You mean I have to actually WORK??!

[Anonymous Coward]

Sounds like a lot of Generation Y whining.

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.

Re:Follow proper MVC development and save time

[Anonymous Coward]

Thank you! This is the right way to do it.

Re:Follow proper MVC development and save time

[darthium]

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.

Could you comment about the tools (IDEs, DB) you used? Thanks in advance.

Re:Follow proper MVC development and save time

[cerberusss]

Only the UI? Your app on iOS was coded in Objective-C, or so I presume. You can abstract data and business layers, but still, it's written in Objective-C.

Now how did you use that code on Android, which requires you write your app in Java?

I can think of some solutions, such as compiling your Objective-C to object files, then use JNI to call the methods, but I wonder if you took this or another route.

Re:Follow proper MVC development and save time

[GauteL]

"Only the UI? Your app on iOS was coded in Objective-C, or so I presume. You can abstract data and business layers, but still, it's written in Objective-C."

You are not required to use Objective-C for everything on iOS, only the GUI interaction (Cocoa). You can develop libraries in C or C++ and reuse these from Objective-C using Objective-C++.

Re:Follow proper MVC development and save time

[hsmith]

For iOS I obviously stuck with XCode. All the business code was in ObjC and the database was SQLite. So, in .NET (since I can write things quickly in that) I wrote a simple lexer that converted almost all the ObjC business code to Java. After that, it was a matter of fixing some compile errors, but a much better time savings than rewriting all the code from scratch. With this approach, there were no new bugs (well limited) introduced since I was able to use proven code.

Re:Follow proper MVC development and save time

[hsmith]

I converted the ObjC to java utilizing a home grown tool, it doesn't spit out perfectly compilable code, but good enough that a few hours of tweaking and fixing a few oddities (grand central dispatch) it was all working flawlessly. Using SQLite as the data store and avoiding CoreData was a big help, just custom data type objects and custom reader code (I did have to write a custom class to map the cursor reading the data in java). Process would be the same for Windows phone as well. Now, the trouble is, you make a change to business logic on one platform you need to make sure it is representative across all of them...

Re:Follow proper MVC development and save time

[shutdown -p now]

So why not rather convert it to C++, and then use that on both platforms?

Welcome to the internet 20 years too late.

[Anonymous Coward]

Think "crossplatform-moblile-development" is the first to deal with competing businesses? Never developed actual HTML for the web then?

Duhhhhhh....

[theshowmecanuck]

It's a pain in the but to write code for two different operating systems that have their own look and feel. Duh! And I suppose the guy who wrote TFA thinks he's a boy genius for figuring this one out. And what is this fucking Einstein going to hit us with tomorrow? Newsflash: The Sky Is Blue! Must be a slow news day. Oh, and send the boy genius back to journalism school till he figures out what 'news' is.

It's ALWAYS been this way...

[Anonymous Coward]

I've been doing mobile development for 11 years starting with Palm and it's always been this way. Although there are some third parties who say they have development platforms that work across multiple devices, the truth is if you want a real native app that looks right for the mobile platform you have to code the UI from scratch for every platform. You can try to do something more generic like a generic web interface, but it just isn't going to have the pizzaz an avid user of the platform expects. This is simply the way it is.

Re:It's ALWAYS been this way...

[Anonymous Coward]

The money must really be good. As a mobile developer you must know that all your blood, sweat and tears will become irrelevant within a few years, if not months. Why not spend your limited lifespan on something which will hold its value for longer?

And you know what else irks me?

[R3d M3rcury]

All these people speaking different languages. I mean, like, the French have a different word for everything! It means I have to have hire somebody who speaks some stupid language if I want to sell my software to them. Why can't we just have one language--English, obviously, since that's what I know? It would make my life a whole lot easier and I wouldn't have to spend money translating my software and adjusting dialog boxes for those damn foreigners!

And don't even get me started on Unicode!

In case you're missing it, the above is sarcasm. But it leads into an interesting point. How many times have you heard someone complain about having to deal with someone on the other end of a support line for whom English is not their native language? About having to dive through some weird accent in order to understand what they're saying? It makes customers not want to call their support line, right?

Similar thing here. I want an application that speaks the language that the OS developers have defined and that I have learned by using countless other apps. While, ultimately, it's about what your app does, if I have to choose between an app that has a native interface and one that does not, I will choose the native interface. Just like if I have choice between speaking to Ken in Minnesota or Pruthvij in Delhi, I'd probably choose Ken (at least until I discover that Ken doesn't know his ass from his elbow).

Want a write-once run anywhere app? Make it a web app. I use plenty of those on my iPhone.

Re:And you know what else irks me?

[shutdown -p now]

All these people speaking different languages. I mean, like, the French have a different word for everything! It means I have to have hire somebody who speaks some stupid language if I want to sell my software to them. Why can't we just have one language--English, obviously, since that's what I know? It would make my life a whole lot easier and I wouldn't have to spend money translating my software and adjusting dialog boxes for those damn foreigners!

You know, I'm not a native English speaker, but even so I would agree that life would be so much better if we all spoke the same language. I would even be willing to accept something as abominably inconsistent and irrational as English - poor standards are better than no standards (but, of course, Lojban would be superior for that purpose). ~

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.

Re:Thank You

[Microlith]

Ah look. It's the Apple Zealot who refuses to acknowledge that it is entirely possible to have good software that is cross platform.

Re:Thank You

[t00le]

A huge portion of our applications now are enterprise class crm solutions, so easy portability to multiple platforms is something we offer as a courtesy. There is always an officer or VP that must be that special snowflake that requires Apple support, even though the other ten thousand people use Linux or Windows.

We have Amazon EC2 services and simply need front ends for access, manipulation, reporting, etc. We have little to no need to have really amazing, shiny and pretty interfaces. Between ICS and iOS 5.x we have almost identical user interfaces with nice transitions and pleasant looking graphics. The thing that matters is speed of access to S3 buckets and read/write access to EC2 clustered databases. The nice thing is we can compile to Linux, Windows, almost all mobile platforms and have almost identical user interfaces. Instead of spending copious amounts of time on one platform, we create portable interfaces that are nice, fast and compile on just about anything, even the magical over hyped/marketed products. :)

Cheers

Re:Thank You

[jo42]

it is entirely possible to have good software that is cross platform

BULL*cough*SHIT!

Re:Thank You

[Microlith]

Well that's cute. Show me how it's impossible?

I think expecting a rational, well explained response from you is asking too much.

Re:Thank You

[Anonymous Coward]

The only cross platform apps I've seen that I'd consider "good" are games, and they're unique because they typically have entirely custom UIs.

Re:Thank You

[ceoyoyo]

If it's possible I haven't seen it. Got any reasonably common examples?

A non-trivial app(lication) is worth customizing the UI for each platform - it's not that difficult compared to the value of the app. Microsoft does it for Office, Adobe does it for all their applications. If your app is so trivial that it's not worth redoing the UI... well, it's probably crappy anyway.

CODE can certainly be cross platform, and very good. Entire applications can be cross platform and decent, but they're never as good as the real thing.

Re:Thank You

[Penguinisto]

You can get away with it if you build a custom UI with a solid cross-platform language/API geared for UI work (Qt stands out as an example on desktops - not sure how good it is in the mobile realm), or you can get away with good results if you write your own UI from scratch.

OTOH, trying to write for one platform's little UI esoterics (even if you're trying to avoid them), then trying to graft all that onto another platform? Yeah, that'd end up leaving a gap 10 miles wide in most cases.

Like you said - it's possible, but the vast majority of developers - both amateur and pro alike - don't frickin' bother beyond 'good enough', and the results usually leave plenty of room for improvement, which a single-platform native developer can take advantage of.

Re:Thank You

[darthium]

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.

Wouldn't this kind of tool be a rebuttal? Check the video, a full fledged ERP developed originally for Windows, executed on Android (also on Linux and MacOSX, iOS is next, AFAIK and with the same ease for the developer) without need of rewriting, using a tool called 'Velneo'. http://www.youtube.com/watch?v=iXluV5jvmc0

Re:Thank You

[GauteL]

It is impossible to prove that something is impossible, but I'd you're right, it should be easy for you to find examples of cross platform mobile apps that are as good as natively developed ones.

Re:Thank You

[Anonymous Coward]

Given the amount of crap apps, it's fairly trivial to make a coss-platform app that is better than natively developed ones. If you want to make a real test, select an app that you consider a good use of native development and challenge a cross-platformist to match it.

Re:Thank You

[jayesel]

It's about the e2e experience not just about the software. I for one would not want to run most of the apps avail on Android due to how they behave or misbehave as you would have it. I like the Apple way, not really interested in other attempts as they would ruin the overall ue. Just because you can do something, doesn't mean you should.

Whatever

[cshark]

We've been doing cross browser development for years. This is pretty much the same thing. Only without the ability to copy and paste things in the ui itself. I'm still waiting for these mobile platforms to catch up to where webtv was a year after microsoft purchased them.

Time for a third party to step in...

[paxundae]

Adobe is trying to do this with Flashbuilder 4.5+. Write once, compile native for all platforms. They'll even take care of trying to make basic art assets (buttons, etc.) look appropriate. Does it work yet? Eh...sorta. But it's a good idea in the current mobile environment, and a potentially lucrative niche to be in.

Re:Time for a third party to step in...

[dredwerker]

I thought flash was about to die for the mobile.

This is is why i used phonegap for my app. Then a previous comment suggests that phonegap is a liability. arggggh

And?

[gman003]

Cross-platform desktop development is no picnic either. I once had to write a simple computer hardware check script - figure out what's in the machine, check against a list of programs, then spit out some XML. Came out to ~200 lines of Perl code for the Mac version, and ~150 lines of C for the Windows one. Not a single line of code was the same. Did I complain?

Well, yeah, I did complain, but more about how retarded Microsoft's APIs are than about having to rewrite stuff.

I'm also working on a video game in my free time. Currently runs on Windows and Linux, may add Mac to it soon. Had to do quite a bit of tweaking to make stuff work, even though I was using cross-platform libraries. Didn't really mind - making it run on Linux actually forced me to fix several potential problems (Arch's GCC seems to default to more warnings and errors than Cygwin's GCC).

Re:And?

[antifoidulus]

Of course Microsoft must be incompatible for the sake of being incompatible, for instance the only one of the "big 3" OSs that doesn't support pthreads(and thus a whole bunch of otherwise cross platform C code) is....drumroll please....Microsoft!

Now that C support in Android is getting better and better, it is completely possible to write the bulk of your program in cross platform C/C++, and only have to add in the UI hooks for the individual platforms. Of course this leaves out WP7, but really, with a comically low market share, who gives a shit out that ugly, buggy pile of puke? (i.e. a Microsoft product)

Re:And?

[hitmark]

Never mind things like ALT+number is tab change in Linux Firefox, but CTRL+number is what is needed in Windows...

Solving the same problems three different ways

[gsiarny]

Slashdot's designation - "from the hard-stuff-is-hard dept" - and some of the comments here suggest that it's trivial, whiny, or both to complain that writing good code for multiple mobile UIs is difficult. Perhaps that's so, but that's hardly the whole story.

Some programmers may see the UI as the necessary-but-uninspiring gloss over the more interesting, more important core functions of a program, and resent having to apply the gloss more than once. But even if a well-designed UI is an integral part of your vision, having to solve the same set of UI problems in multiple incompatible ways may not be as interesting as solving a conceptually fresh problem. Since UI libraries include some of the more fiddly and arbitrary portions of a platform's API, it's not surprising that programmers would dislike having to code more than one. It's not the difficulty that frustrates, but the multiplication of idiosyncratic difficulties which admit only of incompatible solutions.

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.

Re:Mobile?

[FlyingGuy]

ahhh yes do I reply or do I mod... Damit!

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

You may pray but your prayers wont be answered. Well they might, but I seriously doubt it. The problem with whole web thing is that it is stateless. It is really as simple as that. There are tons of kludges to try an imitate a statefull connection but they are all hap hazard and only barely effective. The other problem are actual data aware components. Sadly even html5 does not address this. There should be a control type that accepts a mask like almost every U/I control built into every OS be it, windows common controls or its equivalent on a mac. There should be grid controls that handle data sources directly.

Sadly none of what is really needed is there. There should be a mode to simply ignore CSS and have things all X,Y addressable and don't act like you are trying to re-paginate a word processing document every time the window is re-sized. The most successful company thus far at leveraging every bit of the capabilities of a browser is sales force and I am here to tell ya there stuff looks pretty rough around the edges.

What needs to happen is that the DOM needs to be fundamentally redesigned to a true object api that instantiates controls and what not. A great example is the OWL api.

Re:Mobile?

[Anonymous Coward]

Wrong, Slashdot is my favorite shitty web app

Re:Mobile?

[TheCouchPotatoFamine]

You know, I'm not ready to go public, but I've made a solution for html that does present an actual stateful app feel while keeping all the best of css, etc. And just what you outlined. It is possible. Out soon...

Re:Mobile?

[aztektum]

Until wireless carriers stop nickle and diming for data, apps are going to be the way of the foreseeable future.

Install all you want on wifi, it keeps data tx/rx needs smaller while on the go.

Re:Mobile?

[GauteL]

"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."

True, but for desktops, cross-platform development is considerably easier, and is, in many ways a solved problem. I.e. Qt. However, for Android and iOS development, you have to deal with different programming languages for the UI.

For Windows Phone 7, this is even worse. On both iOS and Android you can at least develop a core engine in C++ and write native UIs in Objective-C on iOS and Java on Android. This is not possible with Windows Phone 7. In their infinite wisdom, MS decided that Silverlight and .NET/C# was your only alternative.

Given the absolutely minuscule market share that Windows Phone 7 has, the added effort may simply not be worth it.

Re:Mobile?

[Anonymous Coward]

That's nice, but I built a time machine. Just not quite ready yet...

Re:Mobile?

[shutdown -p now]

The problem with whole web thing is that it is stateless. It is really as simple as that.

You're confusing "HTML" with "web", where they are not the same thing. You can use HTML5 as the UI markup language, JS as a view backend language, and some way to call C for computationally heavy things, in a regular stateful app that does not utilize the web at all. That's exactly how webOS apps work, for example. It's also how Win8 Metro apps work if you write them in HTML/JS (as it's only one of the options). It's also how some existing cross-platform iOS/Android frameworks work.

Re:Mobile?

[FlyingGuy]

Wow that great! All the utility of an actual piece of software with 10 tons on pure garbage behind it.

HTML / CSS just really don't work. You can make flashy pretty things but the problem is they are brittle. Come to think of it I would rather have my eyes boiled out of their sockets with live steam then try and write an actual business app that needs:

• A rendering engine that will change based upon the whims ( yes whims ) of a bunch of academics who have more then likely never written production code to do actual work in their entire lives.
• An interpreter for JavaScript which is a pretty screwed up language in and of itself and is implemented differently by different browser makers.

The combination of the DOM and JS which has such a fucked up development path that we cannot get the god damn committee to change the spec so that a checkbox returns a simple true or false value instead simply not existing if it is not checked or to get them to classify a text area as an actual text element.

The syntax of CCS is so utterly fucked up that you can create CSS and are quite often forced to, this is so unreadable that it is just as fucked as a regex string that is 300 characters long written by a strung out junky who somehow managed to grok perl and left no documentation and had variables names like $a, $a1, $aa, $aa1.

And people wonder why business is starting to shy away from the whole fucking balls of worms. Standard U/I elements are fine for business and X.Y. positioning works just great as well and that is where we are going back to.

Just give me cross-platform libraries, and be done

[Anonymous Coward]

Seriously, how hard is it to just offer cross-platform APIs?
OpenGL ES is a shining example.

And those J2ME APIs for location, sound, input, etc. (Somebody should keep the API but make them native.

That’s the trick: Don't try to develop your application cross-platform. Abstract that into proper platform-independent APIs .
(That doesn't mean minimalism. It means feature detection, and offer the choice to not run the thing if the hardcare can't do it, or emulate the missing parts if it still can. Like: If it doesn't have a compass, you can't use it. But if it doesn't have EAX but the CPU/GPU is strong enough you could just emulate it.)

Xamarin Monotouch and Monodroid.

[Anonymous Coward]

This seems to work pretty well across platforms. Fast native compilation to binary same as C++ (NO JIT) via LLVM on both Android and iOS. Full access to the native API's. A pretty nice generational partially copying gc. XNA and OpenGL across all platforms. Full source debugging and profiling on all devices and simulators.

Only problem is that full binary compilation breaks some standard libs that depend on using the JIT, some occasional bugs, and I'd personally prefer to see the device API wrapping fully open sourced along with the rest of the base platform. Overall not bad though.

Re:Xamarin Monotouch and Monodroid.

[Anonymous Coward]

(posting AC since I moderated a couple earlier posts)

Indeed, using MonoTouch and MonoDroid sound attractive. Even if it isn't perfect or you don't get full API coverage, at least (most of) your core app functionality could have a single codebase for most platforms (from mobile to desktop and web), and then just code the UI/platform specifics.

MS would be wise in helping the Mono project grow, increase the level of API support on more platforms (ie, at least to the level of the Compact Framework), so they can outgrow Windows, and embrace and extend most mobile platforms nearly overnight. They would still benefit from controlling the main framework on Windows, but would provide a viable interoperability path with other platforms (for better user experience).

Re:Xamarin Monotouch and Monodroid.

[JAlexoi]

Yeah... But you still end up writing 2 different UI implementations that require design considerations and knowledge of the UI to fit in.
Monotouch and Monodroid are in no way interchangeable, beyond C#(or whatever Mono language they can use).

A big pain for vertical and enterprise app guys

[Anonymous Coward]

If you work for a company that sells apps to non-small businesses (say 20 + employees/seats), you want to have a mobile feature so that the boss can keep an eye on things (sales, cash, purchasing, etc) from his phone. Only you gotta allow that there are lots of different phones and you can't tell all those people what kind of phone to buy. So you want to do them all, but your programmers are mostly old COBOL guys or such who are just discovering that there is anything beyond run-of-the-mill business app UIs.

1. Create cross-platform mobile gui development tools

2. Profit!

The Heart Of The Problem

[Anonymous Coward]

The heart of the issue is that our current software landscape on smart phones, tablets, PCs and pretty much everything is incredibly fragmented. Having to cater your programming to each platform is wasteful and while it might employ a lot of young people looking for programming work today is an unacceptable long term solution.

There are some things Apple does right and one of them is enforcing a uniform standard across their platforms. However, their method of locking down this standard is not acceptable.

We need the uniformity of the cathedral with the heart of the bazaar. In practice I think this means constantly creating OPEN STANDARDS (as opposed to Apple's closed standards) and refining standards not just for things like HTML but for interfaces of phones, software applications, operating systems. POSIX is a good example but was never taken into the modern age. You might say that there is a great resistance by companies about this and I would agree. It wont happen overnight be we need to start talking about it and talking about why our current situation is shitty instead telling someone that they're a noob for using an inefficient cross-platform solution (I'm looking at you 0xdeadbeef)

Oh please

[trevdak]

I work at a mobile technology company. While our focus is more on WAP and shortcode stuff, we do a number of applications for iPhone, android, windows mobile, and blackberry. You know why it's not a headache? Because everyone involved knows to treat each version for each OS as a whole new piece of software. You rewrite the UI from scratch according to what works best with the phone, recycle the web services, and charge the customer for each app on each platform.

No, you want a nightmare? Imagine you had to write one app that compiled and worked on an Android, iPhone, windows phone, and blackberry. Then you're dealing with the headaches of a web developer.

More platforms, more jobs.

[Anonymous Coward]

As a computer science student, I think this is good news. More platforms, more jobs.

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

Re:My experience differs from yours.

[xombo]

PhoneGap still imposes the security model that other applications support. For instance, you can inform users that it collects GPS data and Address book or forgo support for that plug-in entirely. They support this both with manually building it via the Android tool chain as well as through PhoneGap Build service. Reason being is that the API for PhoneGap is just communicating with native code underneath to access things like GPS and address book, requiring the permissions model all other Android apps use.

Re:My experience differs from yours.

[Mithent]

I don't know PhoneGap myself, but it sounds like the problem being stated here is with the remote server aspect. Normally you're choosing to trust the executable code you're installing, and that's the end of the story. With PhoneGap you might trust the executable code running on your phone, and the intended app running on the remote server, but the remote code could change and a useful program turned into an attack vector without any notification that anything has changed. Third parties can't change the code of an application distributed through Market without having the original developer's certificate, which would make turning a genuine app into malware much more difficult.

There might be some controls for this in PhoneGap though, I don't know.

Re:My experience differs from yours.

[xombo]

Android: This is a potential problem with pretty much any Android application, regardless of how it's built.
iOS: Any app caught trying to update itself without going through the approval process will be pulled, again regardless of how it's built.

There is nothing substantially different about the security model of a PhoneGap application than that which can be imposed upon a traditional app. I say this as a developer who has spent some time with PhoneGap producing applications for both platforms.

Re:My experience differs from yours.

[jnelson4765]

Actually, without hacking Phonegap, at least on iOS, the first time you access geolocaiton, it pops up the standard 'APP_X would like to use your location' message - we had to rework our Phonegap app to do that properly, instead of having a trainwreck of a URL in that notification.

Android had a better model for security, frankly, in how you build an app - as part of the configuration, you can indicate with a fair degree of granularity what rights you want your app to have, and our upcoming app will only have GPS and network access. We don't care about your contacts, or pictures of cats, or what porn you watch on your phone. Too busy to dig through that crap, and it's not worth anything to us anyway. A similar capabilities-based model for iOS would be great - and I'm not spending the time learning enough Objective-C to do that natively. I have 10 other projects we had to put aside to do this mobile crap, that still need to get done.

The fact is, for web shops tasked with doing a "mobile app" because it's the next f**king Web 2.0 buzzword-compliant "we're serious - we have an app and everything", being able to do a shovelware mobile app without having to learn 2 new languages is great. Our customers go away happy, we don't have to spend the time becoming experts in yet more arcane single-use dev frameworks, and we can go on to the next project.

You want it safe? Go after the OS vendors, and let those of us who write apps define the capabilities we should need, and sandbox the rest. And make it easier in the IDE to select capabilities you need, and default them to 'off', That way, the "I was a designer, but now I do teh mobile apps!" people won't inadvertently bunch a big hole in your phone's security.

Re:My experience differs from yours.

[Anonymous Coward]

A similar capabilities-based model for iOS would be great - and I'm not spending the time learning enough Objective-C to do that natively.

If your not going to do it right don't bother doing it at all. Your piece of shit app isn't worth anything if it's not natively coded.

Re:My experience differs from yours.

[cduffy]

Android: This is a potential problem with pretty much any Android application, regardless of how it's built.

Not as much as you indicate. Updates distributed through the Android Market still have to be signed by the appropriate developer key. It's easier to hijack a website than it is to hijack a code-signing key. (Also, updates which change permissions are presented to the user, and I've seen more than once that an app's marketplace rating has taken a nosedive when users objected to a new permission being requested).

Re:My experience differs from yours.

[Anonymous Coward]

Really, the fart app needs to be natively coded? There are a lot of "apps" that are so minimal in functionality that natively coding for each mobile os is just overkill, especially when the budget is $300.

Re:My experience differs from yours.

[s73v3r]

The fact is, for web shops tasked with doing a "mobile app" because it's the next f**king Web 2.0 buzzword-compliant "we're serious - we have an app and everything", being able to do a shovelware mobile app without having to learn 2 new languages is great. Our customers go away happy, we don't have to spend the time becoming experts in yet more arcane single-use dev frameworks, and we can go on to the next project.

Great for everyone, but the users. The majority of apps that use these frameworks are very lazily done, and will typically make the app match the iPhone look and feel, and then push that crap out to everyone else. Nothing tells me quicker that an Android app is going to be absolute shit than seeing a title bar with a Back button in it, lifted from iOS.

Re:My experience differs from yours.

[xombo]

You fail to recognize that there's nothing stopping Joe Developer from putting a web view inside some other application and doing the exact same thing. Trying to attribute this potential attack vector exclusively to PhoneGap or cross platform mobile apps using HTML is intellectually dishonest. It's a non-starter for anyone familiar with the product.

Re:My experience differs from yours.

[cduffy]

Trying to attribute this potential attack vector exclusively to PhoneGap

And, speaking of intellectual dishonesty, where did I do that?

I didn't say it wasn't an issue for native apps, I said "not as much as [the parent] indicate[s]", ie. less of an issue for native apps than for PhoneGap apps. Certainly, a native application developer can jump through hoops to use a web view and provide JavaScript access to (address book data and other) content which would otherwise be both privileged and only available through the native API... but I don't think it's a stretch to say that a problem which exists out-of-the-box is a larger issue than one that exists only when hoops are explicitly jumped through to make it so.

evolution

[Anonymous Coward]

Difference means evolution. Developer should understand that any sandard means halt for development. We need living market which means there are many different platfroms. We need standards too but not monopoly like MS. If we need a standard platfrom, it should be open because that allows some market economy. Now MS is using its closed Windows monopoly to kill competition from mobile too.

...users continue to favor...

[Anonymous Coward]

[...], especially as users continue to favor native over Web-based apps on mobile devices.

http://xkcd.com/285/

Write (nearly) once

[oever]

At the moment the best alternative is the write the application in OpenGL ES or HTML5. The choice depends on the type of application. Both will need a small wrapper on each platform. PhoneGap is a good choice if you go with HTML5.

I'm not sure how viable the OpenGL ES option is for Windows Phone, but then I personally loathe that platform anyway.

As for look and feel consistency, look at Angry Birds to see that that is not needed at all.

Re:Write (nearly) once

[shutdown -p now]

I'm not sure how viable the OpenGL ES option is for Windows Phone

There's no native code for third-party apps there to begin with, so...

fail = not designing correctly to start with

[ardiri]

cross-platform development is not hard.

the issue is when a developer focuses on one platform; utilizes special functionality and then says "oh.. i need to support that platform to". this is purely a design problem; not an industry problem. if you know, you need to support multiple platforms - one key word.. ABSTRACTION. separate platform code from business logic. that way; when you need to add a new platform, you have a small layer of abstraction to implement appropriately.. games are easier, as UI isn't an issue - but you can do the same with business applications (hint: standards, HTML5 et al).

i've been doing cross platform development for years, always laugh at comments on how difficult it is. if developers were not so trigger happy to get coding; they could simply design/architect their solutions better and there wouldn't be a problem at all. the great thing about my games/apps - i can add a new platform without modifying a single line of the application code itself. implement abstraction layer - select target.. compile.

dealing with complexities of distribution models on different platforms (ios, mac, windows, linux, webos, playbook, windows phone 7).. thats a PITA.

Re:fail = not designing correctly to start with

[Shados]

There's absolutely no technical challenge in doing crossplatform development for mobile, relatively speaking, so abstraction won't help. As said in the summary, the problem is the user expectations are different, and no amount of technical solutions will help.

You said it yourself: "its a design problem". Thats just the thing: 99.999% of the challenge is the design. Coding is the trivial part that anyone can do.

Re:fail = not designing correctly to start with

[tellter2000]

i'm curious. how do you propose total abstraction when the underlying technologies are different? (i honestly don't know. school me). thanks

HTML5 is not for small resolution computer

[narucy]

HTML5 is good for Desktop PC, Standard note PC or 10 inch Tablet Computer. It's enough free web browsing. But, I more small computer (7 inch table, also any phones) require integrated user interface. HTML5 is NOT good for smart-phone, 7-inch tablet. that need big resource and big resolution. Small computer need more tight consistency for user experience.

Re:HTML5 is not for small resolution computer

[FireStaRT8r]

Why, exactly? It's HTML5 with SVG.....works fine. It's UI markup.

Stop bitching.

[Anonymous Coward]

Only amateurs whine about the situation. A pro does the job, no matter the situation. That's why they are hired, because they are pros. If it were easy, ANYBODY could do it.

Re:Just give me cross-platform libraries, and be d

[Plouf]

Sure, so do you prefer a Javascript, C#, Java or Objective-C cross-platform library?

Cross-Platform 'Native' Development can work

[awjr]

I'm not particularly interested in native development, maybe I should be, but I've looked at a number of technologies, initially Flex with deploy via Air, then Phonegap and finally settling on Appcelerator.

Particularly for slower Android phones, Phonegap HTML5 apps really suck with many reviews having the classic "really like the app, but it was just too slow to be use-able". This is a killer and this issue will go away in the first world, but will never go away in the developing markets, just look at Aakash.

So at the moment, if you are careful with your component solution, Appcelerator offers (IMHO) the 'best' cross-platform native compile solution (it even has a webKit plugin so you can deliver HTML5 apps) for iOS/Android. Blackberry is in beta and I have no idea when WP7 will be supported.

One downside....you need to buy a Mac.

Cross-platform UI development

[Anonymous Coward]

Seems that the biggest headache here is the cross-platform UI development that is what the user sees, even though the application is much more than just the UI. That can be solved by using some cross-platform UI-kit but creating the UI separately for each platform and keeping the base application same for each platform. Simple, really: http://www.codinghorror.com/blog/2007/02/non-native-ui-sucks.html

Different paradigms

[ripdajacker]

I've done a few ports from iOS to Android, and the problem most certainly has been that my customers did not use Android phones.

The navigation bar for one is a thing Android does not need. The tabs in the bottom, well let's just say it took some hacking to make it work.

Someone should make an overview of the platforms for business managers etc.

The ports would be easy if the ui was redesigned to fit Android better, but then again, it's just business as usual. As a startup we have a hard time complaining that much to our only customer.

COTS: Commercial Off-The-Self

[Anonymous Coward]

For lesser headaches, they shouldn't reinvent new things, only COTS of existing public domain technologies.
JCPM

Die JS, Die!

[WilyCoder]

Web apps will never become the best platform as long as they are built on javascript.

What a piece of shit language. I have used it and I truly hate it.

I'm not the only programmer who feels this way either. Google is trying a few things to reduce or even eliminate programmer usage of JS. Have a look at their Dart language or their Native Client initiative.

If a web browser could be properly sandboxed (like native apps are right now) and the webview widget could run native code instead of JS in the sandbox, then I would love to make webapps (especially with WebGL being developed).

This looks like a job for a car analogy!

[cyberfunkr]

So.. We need a way to design one car that works everywhere and follows the guidelines of the country, state, region while still feels natural.

1) Since the car will be driven in both American and European areas, the steering wheel must work whether you drive on the left or the right side of the road, and automatically know whether to display miles or kilometers.
2) Not every road is the same size, so we need to compensate for when you go down long, narrow roads, or if the road is wide so you can see more, what I call, "land-scape".
3) Cars need to react quickly, so even when we reconfigure the break pedal placement for each country, there can't be a lot of overhead or extra framework in between the driver's action and the car's reaction.
4) Since we have a brand to uphold, the design must be recognizable as ours. By the same token, every area has a certain look and feel to be accepted so it must be designed with that in mind too.
5) Certain states (I'm looking at you California) have emission standards, while other areas could care less. So we should design to the lowest common standard, then charge for Internal Natural After-market Permission Parts, or "In-App", so that no matter where you go, the car can actually work.

Simple, right?

Of course it's possible to have GOOD software

[SuperKendall]

Ah look. It's the Apple Zealot who refuses to acknowledge that it is entirely possible to have good software that is cross platform.

Look, it's the Apple Hater who knows squat about mobile programming.

In fact I would say for enterprise development, where there's basically no competition and the bar for standards is low, that makes a lot of sense and you can have a good app.

However in the general market given a cross-platform tool and ANY native toolset (Android or iOS) I can always build an application that will be better than yours.

Warren Buffet often talks about successful companies having a "moat" of sorts, some kind of barrier that prevents competition from easily reaching the position you hold. When you create an application to compete in the general market, you have drained your moat. It does not mean you cannot have success, it's just that if anyone notices you have let an opening for someone to take that success away from you.

For Enterprise, yes

[SuperKendall]

I was just trying to keep my original method sort and pithy and trap the Apple Haters into a response (success! Not you of course).

You are right though that for enterprise use cross-platform tools can work - although I think enterprise developers should be looking at what the internal target market is using and build to that - i.e. sales forces are in fact just using iPads pretty much and it really makes sense to build a better tailored application that takes full advantage of the iPad.

Re:For Enterprise, yes

[darthium]

I was just trying to keep my original method sort and pithy and trap the Apple Haters into a response (success! Not you of course).

You are right though that for enterprise use cross-platform tools can work - although I think enterprise developers should be looking at what the internal target market is using and build to that - i.e. sales forces are in fact just using iPads pretty much and it really makes sense to build a better tailored application that takes full advantage of the iPad.

Did you watch the video? Did you understand the functionality shown there? Would you say it'd survive just because of 'lack of competition'? Do you think the best under100 U$ app sold in the app store is more complex than the ERP shown there wroking on Android and updatign a remote DB in realtime?

I use the tool (Velneo) myself, and it's really powerful (I'm a very seasoned developer, used heavily Java and MS tools in the past), and I had such kind of functionality without being an expert on Android, with my same source code I developed on my Windows box. As said, in the video, you see a full fledged ERP (consider how complex an ERP can be), with realtime update of a remote database (I do this with a DB hosted several thousand miles far from my Android phone).

What 'native' app can match this functionality as easily as you imply?

Re:For Enterprise, yes

[SuperKendall]

Did you watch the video? Did you understand the functionality shown there? Would you say it'd survive just because of 'lack of competition'? Do you think the best under100 U$ app sold in the app store is more complex than the ERP shown there wroking on Android and updatign a remote DB in realtime?

I used to be an enterprise developer, for over a decade - working on all kinds of similar very heavily data-driven systems, many with lots of complex forms as well.

YES I understood what was going on in that video. Between understanding that AND understanding now from working full time as a mobile developer since the release of the iOS SDK, also on many heavily data-driven applications on the iPhone/iPad, the application demonstrated in that video is AWFUL. Not even good mind you; I would say that monstrosity sucks and for every screen I saw there are easily 10 ways you could improve the UI and in the end possibly even make it useful for the poor bastards that have to use it every day. That's not even taking into account the myriad of ways you could make it better just because it's running on a tablet and not a PC (which the application obviously had little understanding of) or taking advantage of tablet hardware....

But that's what glorified form designers do for you - they give you something functional that works, very quickly. Well it sort of works, since every single freaking enterpriseapp I've worked with has ended up with a TON of customization that in the end the tools either made impossible or very hard, so I had to tell the business owners I couldn't do the thing they were asking for.

With a native application I can do ANYTHING. If they want text in a cell alternating colors, or pulling up a map, or zooming an element to full-screen by God I can do it. I generally do build out a lightweight framework that makes form definition simpler but then I can attach native functionality anywhere instead of being gated by the tool.

That video is pretty much the DEFINITION of what I was thinking of with my original post. If I saw an application like that and I knew it was making any kind of money I would cry with joy at the opportunity presented to me.

Re:For Enterprise, yes

[darthium]

Did you watch the video? Did you understand the functionality shown there? Would you say it'd survive just because of 'lack of competition'? Do you think the best under100 U$ app sold in the app store is more complex than the ERP shown there wroking on Android and updatign a remote DB in realtime?

I used to be an enterprise developer, for over a decade - working on all kinds of similar very heavily data-driven systems, many with lots of complex forms as well.

YES I understood what was going on in that video. Between understanding that AND understanding now from working full time as a mobile developer since the release of the iOS SDK, also on many heavily data-driven applications on the iPhone/iPad, the application demonstrated in that video is AWFUL. Not even good mind you; I would say that monstrosity sucks and for every screen I saw there are easily 10 ways you could improve the UI and in the end possibly even make it useful for the poor bastards that have to use it every day. That's not even taking into account the myriad of ways you could make it better just because it's running on a tablet and not a PC (which the application obviously had little understanding of) or taking advantage of tablet hardware....

But that's what glorified form designers do for you - they give you something functional that works, very quickly. Well it sort of works, since every single freaking enterpriseapp I've worked with has ended up with a TON of customization that in the end the tools either made impossible or very hard, so I had to tell the business owners I couldn't do the thing they were asking for.

With a native application I can do ANYTHING. If they want text in a cell alternating colors, or pulling up a map, or zooming an element to full-screen by God I can do it. I generally do build out a lightweight framework that makes form definition simpler but then I can attach native functionality anywhere instead of being gated by the tool.

That video is pretty much the DEFINITION of what I was thinking of with my original post. If I saw an application like that and I knew it was making any kind of money I would cry with joy at the opportunity presented to me.

Not everything is about beauty, if so, Nobel or Fields Medal laureates would be beauty pageants, in fact, mostly shallow dumb people is the one who place beauty over complexity.

You make me remember a Mac supremacist and how I embarrased him when he bragged about his new macbook G4 back then. A very ugly and old wrecked Pentium3 with just 192 MB of RAM beat the hell out of the G4 in a Chess game, cause the intel laptop used Hiarcs, and 'ugly' chess software, while the G4 had a very beauty but weak Chess app

.

BTW, If you brag about so heavily about your work and mock other people's work, backup your bragging with FACTS, if you are a so superior developer, show your very complex iOS expert system in a youtube video, as these guys do, to see how your iOS ERP-Expert system is far better (better, not just prettier). If you don't youre just hot air. It's easy to brag, more difficult is to accomplish.

This isn't unique to Mobile

[Anonymous Coward]

Game developers have the same problem and they seem to deal with it just fine. It does cost them, but then they reach more customers and sell more units. The same should be true in mobile: more platforms means more paying customers. The real problem, as I see it, is how to monetize all the platforms to justify the expense. From what I've read, the iOS platform makes developers money, and for the most part the other platforms don't. That's not to say there's no money there, but just nowhere near the dollars as the Apple AppStore generates.

Kony and LUA

[Anonymous Coward]

Kony with LUA is a tool that does cross platform development while keeping the platforms UI.

Cross platform is easy!

[Mabhatter]

Apple makes cross platform development easy. Their tools work for iPhone , iPod touch, and iPad ... What more do you want?

Re:Cross platform is easy!

[shutdown -p now]

Why, OpenBSD, of course!

I don't care about BEAUTY

[SuperKendall]

Not everything is about beauty

I don't care a whit about beauty. What I care about is USABILITY. That app (like so many other enterprise apps have worked with) was built by a bunch of people who didn't have to use the damn thing day to day. I didn't say anything about the widgets or color or anything. I just said it was not a very usable application and that could be improved.

I, like so many other enterprise developers, had to work with what people were trying to design but also listen to the complaints of the people on the front line really using the software. It's amazing how little THOSE two groups end up really talking, even when in theory there is someone in part of the development process representing their interests... but it's almost always a manager who again doesn't REALLY know where problems are or what would make things better.

You make me remember a Mac supremacist and how I embarrased him when he bragged about his new macbook G4 back then

You remind me of every wanker I ever worked with who didn't care about people who used the software we wrote. God I detested those people. Utter wastes of a chair.

BTW, If you brag about so heavily about your work

It's not bragging asshole. It's telling you what real life experience I have had with the issues at hand. I am passionate about this because in any context (mobile or not) the software industry COULD be doing a way better job designing software built to meet users needs but instead all to often is merely the bitch of business groups who have total say over how something comes out, and your video frankly brought out PTSD style flashbacks of some of the horrors that came out of that process.

You can defend it all you like but every single person on earth who has developed software for the enterprise more than a year knows I am correct.

You may have the last reply; I see no need to someone hell bent on pushing people into using unusable software even when better could be had.

As for examples that prove my case, simply look at any large data visualization or data entry app like Salesforce Viewer on the iPad... SInce all of my work is pretty much client work (I am an iOS consultant) I cannot point to it directly, either because it's not public or it's not polite to build and tell.

Re:I don't care about BEAUTY

[darthium]

Not everything is about beauty

I don't care a whit about beauty. What I care about is USABILITY. That app (like so many other enterprise apps have worked with) was built by a bunch of people who didn't have to use the damn thing day to day. I didn't say anything about the widgets or color or anything. I just said it was not a very usable application and that could be improved.

I, like so many other enterprise developers, had to work with what people were trying to design but also listen to the complaints of the people on the front line really using the software. It's amazing how little THOSE two groups end up really talking, even when in theory there is someone in part of the development process representing their interests... but it's almost always a manager who again doesn't REALLY know where problems are or what would make things better.

You make me remember a Mac supremacist and how I embarrased him when he bragged about his new macbook G4 back then

You remind me of every wanker I ever worked with who didn't care about people who used the software we wrote. God I detested those people. Utter wastes of a chair.

BTW, If you brag about so heavily about your work

It's not bragging asshole. It's telling you what real life experience I have had with the issues at hand. I am passionate about this because in any context (mobile or not) the software industry COULD be doing a way better job designing software built to meet users needs but instead all to often is merely the bitch of business groups who have total say over how something comes out, and your video frankly brought out PTSD style flashbacks of some of the horrors that came out of that process.

You can defend it all you like but every single person on earth who has developed software for the enterprise more than a year knows I am correct.

You may have the last reply; I see no need to someone hell bent on pushing people into using unusable software even when better could be had.

As for examples that prove my case, simply look at any large data visualization or data entry app like Salesforce Viewer on the iPad... SInce all of my work is pretty much client work (I am an iOS consultant) I cannot point to it directly, either because it's not public or it's not polite to build and tell.

Blah blah blah, when youre so arrogant, you must have VERIFIABLE EVIDENCE to backup your arrogance, you failed to provide any.

Again, do you know SAP? Did you check its UI? Do yuo know what SAP is?

And then, you claim that such apps are not usable, despite million of people using them (Windows apps have A LOT MORE of marketshare than fancy Mac apps), theres not rocket science using them, unless people is too dumb (perhaps your case, that why the arroganse without backup?) to understand what 'Insert, Update, Delete' buttons are, or that clicking on an icon will do this thing indicated in the popup help when you place over the control you want.

And hey, scientific R&D work in any subject is the most important thing, there are UI specialists that can be hired in any project, but most of the value of an app, comes from innovative approach to solving a problem, not from how more usable is an UI. From a basic level of usability, the rest is fine, but not critical.

Sounds like a rehash of the 'fragmentation` issue

[microphage]

This sounds like a rehash of the 'fragmentation` issue. There are only so many ways you can configure the look and feel of the platform itself. Besides the real money is not in the handsets but in the apps and online services.

"Because Metro-style apps are written using .. .Net-managed code, it may even be possible to run the exact same apps on any Microsoft-powered device".

As I suspected this is a disguised advert for the Microsoft mobile platform.

"yet another way in which the mobile development market is becoming increasingly fragmented"

Yep, without even reading this far I could even see 'fragmented` coming ..

Multi platform development and deployment

[Anonymous Coward]

Check out Application Craft + Phonegap, may help some you guys - http://phonegap.com/case_study/phonegap-application-craft-pain-free-mobile-app-development/