In the past years, mobile applications took the world by storm and already changed the way we use the internet for work or leisure. Various technologies emerged to create mobile apps and development processes start to consider mobile as first class citizens. But even though mobile already seems to be omnipresent, the future is just about to start. We're facing new generations of mobile devices like wearables or lots of mobile gadgets that make up the Internet of Things. We will be confronted with new types of user interfaces for displaying data as well as accepting commands. And we will recognize more and more companies going real mobile first. All this will influence the way we design, develop and test software in the coming years.
This InfoQ article is part of a series on the fast-changing world of Mobile technology. You can subscribe to notifications about new articles in the series here.
Mobile apps are everywhere and a company can hardly ignore them as an additional or even as the primary channel to offer services. Whereas it’s clear that one has to support Android and iOS to reach a maximum of users, it’s not quite clear, what technology and tools to chose to build applications for those systems.
A lot of discussion in this field can still be found around the topics “native apps”, “hybrid apps” and “HTML/JavaScript apps”. So we got in touch with a few people and asked them to share their thoughts on app development. On our list are toolstack vendors as well as developers:
-
Chris Eidhof - iOS developer and author
-
Daniel Gallo - Engineer at Sencha
-
Brian LeRoux - Creator of PhoneGap
-
Maxim Zaks - Game developer at Wooga
-
Miguel de Icaza - CTO at Xamarin
InfoQ: Currently, there is a broad range of technologies to create mobile apps starting from native development through cross compilers to hybrid or plain HTML5/JavaScript based apps. Please let us know, what your favorite technology is and why.
Chris: We like to provide the best experience for the users of the app. For almost everything, this means working very closely with the native libraries that Apple provides us. We value smooth animations, and interfaces where the user feels at home. In many non-native apps, the user interface feels slightly off. The only good reason I see for using non-native apps is when you're building a game that's not very graphics heavy. Over the years, I've rewritten a lot of apps from customers who started out with an HTML5-app (mostly because they thought they could save money), but were so disappointed with the result that they had to rewrite it from scratch as a native app.
Daniel: I’m going to be very biased, because I work at Sencha – we develop mobile and desktop web application frameworks, so of course my answer is going to be HTML5 and JavaScript!
I believe there are many benefits this particular route brings, for example there is a huge developer market that has experience with web technologies (JavaScript, HTML, CSS).
Also, during development, the code that’s written can be debugged and tested easily in the browser due to the absence of any cross-compilers converting the HTML/JavaScript code into a native equivalent. Most HTML5 and JavaScript based frameworks also offer the advantage of being able to write the app once and target all the different platforms, saving time and money, instead of producing a native app for each device.
It’s also worth mentioning that literally every device these days has HTML5 capabilities, so it’s the only approach that can be immediately consumed on every device.
Brian: Having spent the earlier portion of my career writing, then rewriting, native apps in enterprise situations I have grown an aversion to those types of environments. I think this was, in part, a motivation for PhoneGap. The irony, we much of our time today writing native bits to achieve our goal of helping bring up the web as a first class platform.
Sometimes that surprises people. Web browsers and things that embed them are constructed of native code. The same code, usually C and C++, is what your operating system is written in. If a web technology doesn't do something it is not because it can not but rather because we have not written that bit into the platform just yet. There is no technical barrier to the web being "native".
In understanding how these things are built one realizes that contrasting them is a misinformed view. Additionally consider that dog piling into a proprietary jail to the profit of a select group of shareholders only to watch that technology get abandoned in a 5-10 year window is not the optimal business strategy for your technical investment. A better view is to build on the web commons and maybe even help contribute to making things better for all of us.
Closed GUI tech tends to spike, thrash, then fade away while the web quietly, but consistently, improves. The state of the art is light years ahead of ten years ago. With WebRTC, WebGL, various device API's, WebAudio API, and VM improvements to JavaScript the web is on the precipice of transforming yet again. These transitions in technology tend to provide significant opportunities for new businesses to disrupt the old. Broadly speaking, the mobile web is in its infancy, and these new capabilities are barely being exploited today.
Maxim: I personally favor native app development because it let’s you concentrate and focus on user experience and brings the best of the platform under your fingertips.
Building an application with many platforms in mind makes development more fragile. Specially in the beginning I like to concentrate on making the application great for one platform and not on feature set or special paradigms of platform XY.
Miguel: There is no question that I love the approach that we have taken in this space.
What we did is that we brought the core of .NET and C# to Android, iOS, Mac and PlayStation making the language as universal as it could possibly get. That said, we did not bring the user interface elements traditionally associated with .NET. Instead we created C# libraries that are specific to each platform so developers could take advantage of all the features available on each of these platforms and create applications that leveraged every small detail that Apple and Google bring to the table. This means that we transfer all the innovation and improvements that come to the native platform to our users.
While this approach is great for developers that wanted to fine tune every last detail and wanted to leverage every knob in the platform, many developers just wanted to get something working on all the platforms at once, or decided that not every element of their user interface and platform integration needed all the power of the native platform. For them we created a series of cross platform libraries (that are built on the previous technology) that give them a write-once, run-anywhere library. These include our Xamarin.Forms API, which is focused on building cross platform user interfaces, Xamarin.Mobile to access the various features in a device (like cameras, accelerometers, gyroscopes and so on); CocosSharp for cross platform 2D-games, our work on cross platform SQLite and our contribution to Couchbase to get both storage and offline and synchronized storage available with the same API.
InfoQ: There is a lot of discussion on native versus HTML5/JavaScript based apps regarding performance. Even though mobile devices and mobile browsers are becoming more and more powerful, native is said to be faster. Is this true? Or is it just a matter of using the right framework the right way?
Chris: Theoretically, there is no reason why JavaScript should be slower. In practice, however, you *always* notice. JavaScript is an interpreted language, and runs much slower than Objective-C. Using HTML for rendering, despite its optimizations, is often much slower than native UIs. I believe that it's possible to make a non-native app fast enough, but almost nobody knows how to do it.
Daniel: This discussion has been going on for a while now, but really performance all boils down to how well the app is built using a particular framework. It’s very common in web apps to just build the app without any special considerations as to how it should be structured to optimize performance. For instance, rendering too many components on screen at once, or showing too much data that could instead be batched into smaller chunks, will greatly impact performance.
If designed properly, there’s no reason why an HTML5/JavaScript powered app can’t rival a native equivalent. There are some real-world examples that prove this, including Sencha’s Fastbook demo, an HTML5 Facebook proof-of-concept app that outperforms the native Facebook app in a number of areas. This just goes to show that it is possible to obtain great performance from web apps, provided due consideration is taken to designing it as an app, as opposed to a web site.
Native apps can also suffer from poor performance due to bad architecture. For example, the Facebook app on an iPhone 4 is simply terrible - so to blankly say that “native is always faster”, is not true.
Sure, there are specific aspects in native that can be faster, for example when considering the current performance limitations of the WebView, but outside the small number of specific cases, most business applications can achieve fantastic performance using hybrid HTML5. With regards to WebView performance though, both iOS and Android have significantly improved their WebViews with recent releases, and this is expected to get even better in the near future. Therefore, many performance concerns relating to the WebView have been alleviated.
Brian: Delivering instructions to the CPU is the fastest execution hardware can afford which means we should write everything in Assembler. Except execution speed isn't always the most optimal way to achieve our software goals!
Sometimes we need to consider developer skills, happiness and API ergonomics. Onboarding a new developer or even an existing technology or content investment can inform this choice. These tradeoffs get even more blurry when we consider the permanence of a technology. Proprietary GUI toolkits do not have a good track record at staying power. Heck, even open source JavaScript frameworks seem to fall into (and out of) fashion.
You can build an app today using web technology, across all the major platforms, and have an experience indistinguishable from the native experience. Sometimes a hybrid approach is needed, such as Instagram employs, to combine webviews and native menuing . The answers are, much as in life, not so black and white but rather situational shades of grey. If you happen to have a crack team of Swift developers then, by all means, write your app for iOS8 only. Perhaps you found the Java ecosystem aesthetically appealing in which case Android could be a fine place for you and your app. Maybe you made a large investment in .NET technology in which case I would angle for Xamarin. "It depends" is a developer cliche for a reason!
Ultimately, if you want to access the broadest possible spectrum of devices and the people that run them the choice is a web technology. If you want app store discovery, and maybe early access to new web API's, Apache Cordova based projects like Adobe PhoneGap could be relevant to your interests.
Maxim: I would say it is more convenient and simple to write a native application without dealing with performance pitfalls. It is also more convenient to deal with a performance problem, when you hit it during development of a native App. Good platform ecosystem provides you with tools for profiling debugging and troubleshooting of such problems.
There are tech demos, which show performance heavy examples done in JavaScript. It is remarkable but I doubt that this is desirable. When writing an application you are facing lot’s of problems and performance tweaking is the last thing you want to deal with. In my opinion simplicity should be first priority on every software development project. If you have a performance heavy application on your hands you should evaluate technologies which proved them selves of handling this payload in a user (developer who is using the technology) friendly manner.
Miguel: There is no question that using a native compiler and the native APIs will be faster. After all, the HTML5 and JavaScript engines at the end of the day are built on top of the native primitives. But not every application needs all the power of the most low-level primitive available in the system, and in many cases it does not even matter.
But in general, the major problem with HTML and JavaScript on mobile is not that they are slow, is that they do not feel right, they do not leverage the native features, they do not behave like native apps and have odd behaviors. And this is what some users perceive as being slow, not really the speed at which the JavaScript code or the HTML page is rendering, it just seems like a collection of interconnected pieces that everyone has to fine tune.
So it is a matter of performance, behavior, interaction and just being able to leverage the vast set of mobile APIs that are just too cumbersome to emulate.
InfoQ: One of the advantages of native development is the look and feel of the resulting application. Apple uses comprehensive “iOS Human Interface Guidelines“ to make sure that most applications look and behave the same. If developers do not use native UI widgets, apps might not meet the users’ expectations. Do you think that this is a serious problem?
Chris: It really depends on the app. For most apps, it does matter. Every non-native UI widget is a new thing to learn for the user. For example, if you build a todo list, you don't want to overload your users with the burden of having to learn new UI paradigms. For games, you almost always create custom UIs. Also, big famous websites such as Facebook can probably allow a few custom widgets, as the users really want to use their app.
Daniel: This really depends on the type of app – for instance whether it’s a typical business to consumer app, or something more informal. Web application frameworks can replicate the native look and feel of components through the use of good CSS, so this isn’t usually an issue.
With Sencha’s mobile framework, Sencha Touch, there are out-of-the-box themes for each device and platform that developers can use to offer a native equivalent look and feel for all of the UI components and interactions. These themes are dynamically set at runtime based on the user’s device, and can be customized to maybe fit in with a particular color scheme or branding.
Brian: Devs that locked themselves into a particular revision of the Apple HIG found themselves re-authoring their apps for later revisions. Developers who built apps to *their* brand found their applications to not only be cross platform but agnostic to new platform releases. Uber's app is an excellent example of scaling a user experience across devices and platforms.
User experience is a serious concern. The success of software is unquestionably correlated to having a positive end user experience. Technology choice for the GUI will impact many factors but it certainly will not make or break the job of getting a great experience out the door. You can't skimp on this. Great user experiences means you have to employ great user experience professionals, and perform ongoing quantitative and qualitative research. There is no shortcut to a great app regardless of technology choice.
With that said, web technology has proven to scale well to many screen sizes, orientations, and future implementations of the platform.
Maxim: If an app does not meet users expectation it is always a serious problem. However it doesn’t mean that if you introduce a custom UI in your app, it won’t meet users expectation. You just have to make your custom UI as intuitive and delightful as native experience. This can be a very tough problem, specially if you are aiming for cross platform.
And again I would like to question the meaningfulness of lifting this extra weight on your shoulders - creating custom UI which will feel natural and intuitive to iOS, Android and Widows Phone user. Don’t get me wrong, there are meaningful examples. Games traditionally come with custom UI. And also websites are good example of custom UI running on different operation systems and different browsers.
But consumer have chosen, they rather install an app than visit a website. This is due to a better user experience and one of the big influences in user experience is UI. People want to do things in familiar environment. It is a bit different when you design a website. There is no familiar environment in Web, so the reference point is mostly another website. When building an app which should solve problem X you should ask yourself if custom UI will help the user understand and solve problem X or will it confuse the user. After all someone else can make an app solving problem X in native UI and put you out of business.
Miguel: It is only a problem if it becomes an issue for your business or impedes progress.
Many vertical applications will never face any competition, so there is no incentive to address those. This is the same reason why enterprise software is so bad, because there is no competition, or the cost of migrating is so high. When users are locked, there is really no incentive to change the application to use something more polished. In some cases, the business calculation will be one where you want to just deliver a solution, and the polish is just something that you can afford to ignore.
It is only when competition or business requirements come into play that developers tend to look for solutions outside of the simplest path to delivery.
InfoQ: App development is not only about creating code, but also about testing functionality, performance or user behavior. What are the tools you use or provide to support those different areas of testing?
Chris: We hardly have to test for performance, because we develop native apps, this is almost never a problem. For functionality, we spend a lot of time testing what feels right, together with our designers. We are very open on Twitter and via email to customer feedback, and are in touch with a lot of our customers. Because we're a small team, we all join this process. In addition to all of this, we have automated tests to make sure we don't introduce any regressions.
Daniel: Sencha developers can choose to use a variety of testing tools, but a popular one is a tool called Siesta, developed by Bryntum. Siesta is a JavaScript unit-testing tool, and also offers the ability to test the DOM and simulate user interactions. This means that large parts of an application’s functionality can be tested.
Another testing capability is offered from Appurify, which was recently acquired by Google. Appurify enables automated UI and performance testing of apps on physical devices running in the cloud. This can be particularly handy, as it means you don’t have to buy-in the many different devices, or manage the large number of different configurations they come in (such as different operating system versions).
When needing to debug particular issues or analyze performance problems, browser developer tools offer a vast array of capabilities nowadays, such as the ability to record and analyze all activity within the browser window, including layouts, data requests, memory usage, and events. Browser developer tools can be extended further by add-ons such as Illuminations for Firefox, or Sencha App Inspector for Google Chrome, which offer deeper and more intelligent insight into the use of the Sencha frameworks, beyond the more general HTML5 debugging tools offered by the native browser tools. This enables developers to quickly see what’s going on in their app, when using expansive frameworks such as Sencha Ext JS or Sencha Touch.
Brian: We still do a great deal of manual unit testing in Apache Cordova and Adobe PhoneGap. We're working towards cleaning up that architecture into installable plugins. Otherwise, the user space is coalescing on Saucelabs Appium to automate test infra. I'd also recommend taking a look at Parashuram's browser-perf package.
Maxim: As a strong believer in test driven development I write unit tests to ensure the correctness of application logic. Best indicator of performance pitfall is drop in FPS rate. Whenever a performance issue arise, I use profiling tools provided by the platform to find performance critical code and refactor it. Unit tests comes handy during refactoring as they indicate that after performance optimization application logic hasn’t change.
There is a variety of tracking services which let you get anonymous data about user behavior. Those services typically provide platform and language specific SDKs.
Miguel: Xamarin offers a wide series of services for testing. We go from the very basics to the very sophisticated.
Test Cloud is our crown jewel. Test Cloud is a cluster comprised of some seven hundred devices running all kinds of versions of Android and iOS on all kinds of different form factors which we provide to developers to run their automated tests against. When you build your application, you upload it to Test Cloud and we run the test suite against all the platforms that you want to support, and produce a detailed report of the failures encountered in the process. We routinely assist developers in spotting differences and problems on different platforms. For example, just recently we help one of our customers find that a certain class of popular OpenGL optimizations was just not supported on an entire range of devices that had a certain GPU.
On the other end of the spectrum, we provide Calabash, a system that allows developers to write test suites for their mobile applications as well as the usual unit-testing frameworks that you are able to run continuously every time you build your application.
InfoQ: Managers often state that realizing apps with HTML and JavaScript is the way to go because "we know how to do web-apps for many years now". Even though this is correct, there might be a difference in developing ordinary web-apps for desktops and mobile apps including business logic based on JavaScript. Is writing business logic in JavaScript as easy as doing it in Objective-C or Java and are there enough JavaScript developers for such tasks available in the market?
Chris: I don't think it makes a difference, all three languages are very similar (except for some minor syntactic differences).
Daniel: I would say the ease of developing web apps for multiple platforms and writing business logic largely depends on the structure of the JavaScript app and the framework being used. For instance, Sencha offers JavaScript frameworks for both desktop and mobile app development (Sencha Ext JS and Sencha Touch). These two frameworks are based on the same paradigms, plus Ext JS even supports tablets as well as desktops, so code can be very easily shared across desktop, tablet and mobile apps.
Sencha Touch and Ext JS both feature an MVC architecture, that allows the application’s code to be separated out into distinct areas: the Models (defining the data definitions), the Views (the user interface), and the Controllers (the business logic). The business logic can always be contained in the application’s Controllers, meaning it’s in a consistent place and promotes code reuse, rather than snippets of random business logic being written directly into the View. Sencha’s support of MVC is similar to that of native Objective-C or Java development patterns. So yes, writing business logic in JavaScript can be very easy as long as it’s structured appropriately.
In terms of a developer market, JavaScript is one of the larger skill bases for programming languages. IT Jobs Watch, who track the IT job market in the UK, have statistics ranking the programming language experience asked for in permanent job postings. In a three-month period (June to August 2014), the number of job postings that asked for Objective-C was around 1,000; Java was around 16,000, and JavaScript was just over 17,000.
(Sources: Objective-C Jobs, Java Jobs, and JavaScript Jobs)
Brian: Business logic is easier to express in dynamic languages but requires more rigor in testing, encapsulating functionality into discreet (ideally separate) modules. The tooling story for the native environments give developers a lot of crutches like code generation, and compiler warnings which vendors claim leads to better software. It doesn't. It leads to lazier developers that often don't test their work but throw it over the way to siloed QA department running a completely different environment. Dynamic language environments act as a forcing function for creating and maintaining better test suites lending themselves to higher quality solutions. The most trafficked websites in the world are built in this manner.
There are no shortcuts to creating great software experiences. We need to apply rigor and discipline to our code to get good results. But this has nothing to do with native or web code. Both environments benefit from comprehensive testing, continuous integration and continuous delivery.
Maxim: My last encounter with web development in HTML and JavaScript was in 2012. I was part of a team developing rich web client for mobile and desktop home automation platform. Back than I observed following fact. As a desktop web front end developer you have two tasks to accomplish:
develop the applications
make it run on old version of Internet Explorer (mostly by introducing as many shims as necessary)
As a mobile web front end developer you also have two tasks:
develop the application
strip everything down so that application is usable on bad internet connection and low end Android devices
Maybe the world changed a lot in last 2 years but if not the assumption "we know how to do web-apps for many years now" doesn’t fit. Building desktop/mobile and building HTML and native applications can be considered as orthogonal to each other. If I learned how to build desktop HTML application I still have to learn how to build a mobile HTML application. If I have experience in building native mobile applications I also have to learn a thing or two about building mobile HTML applications.
Miguel: I disagree with the premise of the statement.
Some managers are better versed on the subtle problems that come with JavaScript and prefer every time better languages with better IDEs that assist developers with the entire lifecycle of an application: from code completion, to IntelliSense, to automated tests, to refactoring tools, to long-term maintenance of the code base, to the ability to easily grow a team without finding themselves lost in an ocean of spaghetti code.
JavaScript major strength is its ubiquity, but both Google and Microsoft have long recognized that it is a poor language for building complex systems that require some or more of the attributes listed before, and they have both created languages on top of JavaScript to solve those issues (Dart in Google's case and Typescript in Microsoft's case).
The best thing that can be said about JavaScript today is that many people can put something together with it.
InfoQ: Mobile development does not only target smartphones and tablets anymore. There are new devices on the rise and also new types of interfaces. If we think of wearables like Pebble, Google Glass or Gear Fit we can find challenges in displaying data and also completely new ways of interacting with the devices. Native SDKs let developers access those specific functionalities but are HTML and JavaScript also able to cover this broad variety of devices and interfaces that might hit the market in the near future?
Chris: Initially, no, but ultimately, probably so. It all depends on the manufacturers, and which things they open up. For the foreseeable future, it'll definitely be the case that native development has strictly more possibilities than HTML.
Daniel: The trouble with native SDKs is that you are creating something specific for a particular platform. With HTML and JavaScript, there are a huge number of personal devices that have the capabilities to render web-based content.
At Sencha, we’re always looking to support new devices and platforms as the uptake becomes popular, and one of our own engineers produced a proof of concept where a traditional Sencha mobile app, packaged with Cordova, runs on Google Glass.
This goes to show that it takes very little effort to slightly modify an existing web-based application, and make it available on smaller form factors. Obviously, with something like a Pebble or Gear 2 device, you are much more restricted to the available screen space, so as a designer or developer you would need to be much more aware of how many components you rendered on screen at once, without overwhelming the device and user with too much content that’s difficult to navigate!
Brian: Oh for sure, Android Wear, and Google Glass use an embedded WebView (without JS enabled) to render their interfaces. It turns out WebViews are really great for rendering across many screens and especially great at text centric display. Pebble has a JavaScript SDK. The future of wearables is very web connected and the interfaces are following.
Maxim: When a new device is introduced and the manufacturer decides to open it up for third party developer by introducing a native SDK, the manufacturer should have some kind of the vision. In my opinion, clear vision of hardware/operation system manufacturer helps enormously to 3rd party developer. If the manufacturer envision third party developers writing web apps for his platform, than everything is fine. If he didn’t and third party developer uses browser as a back door to enter the platform, than it will become painful for application developer and also for the user.
InfoQ: Mobile apps often target private end users and it's important to provide updates with new features and bug fixes fast and regularly. Usually developers apply agile processes to achieve this and strive for continuous delivery. It seems that there is a clear advantage for HTML and JavaScript with regard to agility - are there alternatives in the native world?
Chris: If you compare mobile apps with mobile websites, it is a clear differences: mobile websites are way easier to change. If you compare native apps vs HTML5 apps (for example, created with PhoneGap or similar technologies), there is no difference, at least on the Apple platform: neither is allowed to download new code. Even though it's technically very possible to continuously update an HTML app, it's not allowed.
Daniel: During development of native apps, it’s possible to push updates to beta users using something like TestFlight. In a corporate environment, TestFlight can also be used for large-scale deployments of apps to internal users that bypass the app store, meaning there’s no delay waiting for an app to be approved before users can download a new version.
Brian: If you consider hybrid development you can enjoy the benefits of continuous delivery without App Store review wait times. Apple recently relaxed their stance on this. I'm clearly biased on this question but really that does combine the best of both models. You get the discovery of the App Store, the power of the native platform with plugins, and the freedom to push code into production at will.
Maxim: It really depends on the application you are building. I would argue that a private end user care much about frequent updates. They want apps to work. And if you nailed the user experience with first version, that’s great! It is also better for app rating in app store, as with every new version you start from scratch.
Nevertheless delivering bug fixes is important and introducing new features may also be useful :). In this regard Web have the best delivery mechanism. If you are building a web app you can release as frequent as you want, you can do partial rollouts, A/B-Testing and so on. However as you can see I say Web. HTML and JavaScript are not web. Applications delivered through Apples app store are prohibited of downloading code after approval. Meaning if you package an HTML application as a native one and publish it on the Apple app store you lose most of the benefits I mentioned before. You can still use Web for loading configurations and doing A/B-Testing for example, but it doesn’t help you much with urgent bug fixes.
Miguel: Native developers can at most ask the user to upgrade when a major flaw is discovered.
That said, like the current flaw that IBM identified where a malicious user could hijack bank information showed, while building apps with HTML and JavaScript that is entirely hosted on the server is possible, a large number of apps built with this container model would still require updates to the container itself.
There are other alternatives, where some of the content displayed to the end user is controlled by a server, either by sending HTML and JavaScript or by sending some other form of structured data.
InfoQ: "JavaScript everywhere" - usually this is said to be an advantage for using JavaScript on the server-side. Developers can re-use code and tools if they share the same technological stack on the server and on the client. Do we have similar effects with mobile apps? Are there ways to re-use code and tools in the native world, too?
Chris: I reuse a lot of my skills and code for desktop Mac programming. Also, I've written server-side code in Objective-C, and am experimenting with server-side code in Swift.
Daniel: It’s possible to re-use code, because tools like Cordova can be used to create hybrid apps, so the development process can be nearly identical to that of normal web apps.
But really the advantage here is that app developers don't have to learn the native languages across platforms. For server/web, there's only one variant (the server), but with 3 or more native platforms, HTML5 is clearly the easier approach to delivering across platforms.
Brian: Again, we enjoy this benefit implicitly with hyrbid dev. We do a tonne of templating client side and then get to reuse those on the server. Other cases that are less obvious but just as exciting are running your test suite on the client and the server. Overall having JS everywhere is a big win especially as the language is maturing with ES6.
Maxim: There is one problem with code re-use - coupling. When you use same code on server and client, you can’t change client without at least checking if it has implications on server side implementation. This can become specially cumbersome when you have a long lived product.
Same applies to mobile apps. If I write a mobile app for several platforms and re-use most of the code. I created a monolithic core. Every time I am going to change something it will affect all platforms. In the previous question we discussed delivery mechanism and that they vary a lot dependent on the platform you publish. Web is the fastest delivery mechanism, and Apple app store is the slowest. There is an old saying: "A chain is only as strong as it’s weakest link". In cross platform approach I have to concentrate on the weakest links of every platform. Means that when I am changing something critical in the business logic I can change my web application only after Apples app store rollout went through. And if I am doing some complex visual representations (UI) I have to think about the weakest Android device I want to support.
I don’t want to say that code re-use is bad. I just wanted to point out that everything comes with a price.
Miguel: Yes, use C# or C on both ends.
InfoQ: In-app analysis became more and more popular in the last months. Do you use tools like Splitforce and how important is analysis to provide a perfect product?
Chris: We have our own analytics system. We believe analytics helps to gain insight in what users are doing. We also talk a lot with our users via email, twitter and in real life. This is even more important, because we get a much better overview of the big picture, and it helps us understand where our apps fit into the user's daily workflow.
Daniel: Depending on the type of app being developed, analytics tools could be very useful in aiding the understanding of how an app is used by end users, and also which parts of the app may be utilised more than others, so as to concentrate future development efforts on popular parts of the app, rather than less-used aspects.
Brian: Well, since you asked, we have a product called Adobe PhoneGap Enterprise that integrates with Adobe Marketing Cloud. We do deep analytics, A/B testing for content optimization, and workflows for content publishing into production apps. Basically its totally sweet. ;)
Maxim: A/B-Testing and business analytics are very important for the success of your application. Last 2 years I spent in mobile game development, where it is specially important.
A person doesn’t have to play a game. Games are not crucial for our existence. We play games because we like it. Because we like the experience. A/B-Testing and business analytics helps us to find the best user experience for targeted user group. Without this tools we can only gamble on success of feature "XY". And this is unacceptable for a sustainable business.
Miguel: The space is very busy with offerings from dozens of companies like Twitter, Amazon, Google, Microsoft to deliver insights as to what people are doing with their software. It is a fairly mature space now, and it is the standard, rather than the exception at this point.
About the Panelists
Chris Eidhof is a Dutch software developer living in Berlin (Germany). He spends most of his time building iOS and Mac apps, such as Deckset. He started UIKonf, objc.io, and wrote a book about Functional Programming in Swift.
Daniel Gallo has over 9 years experience developing innovative web-based applications using a variety of technologies, and specializes in ASP.NET C# and JavaScript. In early 2012, Dan joined Sencha as one of their Sales Engineers in Europe, where he provides pre-sales technical assistance regarding the Sencha product line.
Maxim Zaks developed and consulted on several Java Enterprise projects, web projects and was lead developer of an Eclipse based IDE. Nowadays he is developing casual games at Wooga with a focus on iOS platform.
Brian LeRoux is the principal product manager of PhoneGap and topcoat at Adobe as well as VP of Apache Cordova. A passive member of the Node Firm, mobile web hacker, beer enthuist with a JavaScript problem which he and many others document at wtfjs for fun. You can catch up with Brian on his website.
Miguel de Icaza is co-founder of Xamarin, a company that produces the MonoTouch and Mono for Android libraries, which allow programmers to use C# to create mobile applications on the iPhone, iPad and Android devices. Prior to starting Xamarin, Miguel has been the creator of Gnome and Mono and was also the co-founder of Ximian.
In the past years, mobile applications took the world by storm and already changed the way we use the internet for work or leisure. Various technologies emerged to create mobile apps and development processes start to consider mobile as first class citizens. But even though mobile already seems to be omnipresent, the future is just about to start. We're facing new generations of mobile devices like wearables or lots of mobile gadgets that make up the Internet of Things. We will be confronted with new types of user interfaces for displaying data as well as accepting commands. And we will recognize more and more companies going real mobile first. All this will influence the way we design, develop and test software in the coming years.
This InfoQ article is part of a series on the fast-changing world of Mobile technology. You can subscribe to notifications about new articles in the series here.