The Future of Mobile Development
What I see as the future of mobile development is a unified native API that spans across OSes and systems from various manufacturers. Want to write an app? Great! Learn one language with one API and you can deploy your app to Android, iOS, Windows Phone, BlackBerry, Ubuntu Touch, Sailfish, etc. The problem is, how do we get there from here? It is no easy task to create such a language or such an API. Thankfully, the language already exists, and it is well known. Have you heard of C++? Yeah, that language that works across all of those platforms (and many more!) already? Well, C++ is already gaining popularity after the whole "managed languages rule!" trend of the past decade. "But Chris," you might ask, "what about the unified API?" Well, that's coming from everybody's favorite C++ framework: Qt.The Current Status of Cross Platform Mobile Development
People are already partially working in that cross platform development utopia in which one language and one API let you deploy to every mobile OS. Many games and other apps have a C++ back-end wrapped in the platform's SDK language (Java for Android, Obj-C for iOS, etc.). That wrapper creates the UI and let's the C++ core access other platform APIs. The only problem is that the developer MUST learn the SDK languages and APIs for each platform they want to deploy to. While that may be alright for big time developers, for hobbyists and self-taught programmers that can be a major roadblock in deploying apps across multiple OSes. We need a single API that we can use across all systems; a cross-platform language isn't enough by itself.Problems with the Future
Each mobile OS has a very different UX that must be catered to by the developers because of user demand. Android users absolutely hate it when the Android app uses the UI of the iOS version of an application. It makes the Android version feel cheap and like an afterthought. The mismatched theme devalues the application and it tells the users that the company doesn't care enough about them to rewrite the UI for Android. There can be other issues, too. For example, in iOS, application settings are often handled in the system preferences app. However, on Android, each application usually has it's own settings fragment within the application. What I'm getting at here is that even with the future of mobile development (one language, one API), developers cannot simply write an app once and deploy it across every OS available because the UX wouldn't be native for each platform, even if the on-screen UI elements are.How to Remedy the Problems
The solution to the problem is quite simple, really. Write a new UI for each target platform! I mean, developers already do that when they have the C++ core and SDK language/API wrapper, right? Only with a cross platform language and API, the developer can reuse more UI code, simplifying the process while retaining a native-feeling UX. Think about it. Even though the developer would have to tweak the UI/UX for each target platform, they could do so using the same set of tools and knowledge! On Android, this would mean the developer wouldn't have to know about the JNI or Java to make a native feeling Android application. On iOS, this would mean that the developer wouldn't have to know about Obj-C. All the developer would have to do is move around a few UI elements and select the target's theme.TLDR: Qt 5.2, which introduces iOS support, marks the beginning of a decent cross-platform develop suite for mobile apps. Yes, the UI/UX will have to be tweaked for each target, but it can be done using one set of tools and the same knowledge.
Thanks for stopping by!
Chris Konstad
Good points. I think Qt 5.x should integrate more features regarding QML and UX on different platforms--particularly mobile. Desktop apps have become so plentiful that there really isn't a "standard" UX theme anymore. On iOS and Android, everything just looks "different", as you said. I think some sort of build-target QML switching thing would be a cool idea. That way you could have two QML files that utilize different UI's, but you have one backend that can be used by both UI's.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteyou are so cute
ReplyDelete