Slashdot Mirror
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."
I'd personally call them migraines.
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.
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.
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.)
A feeling of having made the same mistake before: Deja Foobar
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. :)
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!
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..)
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
Success requires effort. Nothing new here.
Coder's Stone: The programming language quick ref for iPad
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?
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.
When the only tool you have is a hammer, every problem looks like a nail
So platform diversity is great until you have to code for it? I'm not seeing a problem.
bah.
They changed that policy in late 2010. http://daringfireball.net/2010/09/app_store_guidelines
Dilbert RSS feed
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.
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.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
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.
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.
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.
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
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.
I am very small, utmostly microscopic.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley