Learning by Shipping

Targeting multiple operating systems has been an industry goal or non-goal depending on your perspective since some of the earliest days of computing.  For both app developers and platform builders, the evolution of their work follow typical patterns—patterns where their goals might be aligned or manageable in the short term but become increasingly divergent over time.

While history does not always repeat itself, the ingredients for a repeat of cross-platform woes currently exist in the domain of mobile apps (mobile means apps developed for modern sealed-case platforms such as iOS, Android, Windows RT, Windows Phone, Blackberry, etc.)  The network effects of platforms and the “winner take all” state that many believe is reached (or perhaps desirable) influences the behavior and outcome of cross-platform app development as well as platform development.

Today app developers generally write apps targeting several of the mobile platforms.  If you look at number of “sockets” over the past couple of years there was an early dominance of iOS followed by a large growth of Android.  Several other platforms currently compete for the next round of attention.  Based on apps in respective app stores these are two leaders for the new platforms. App developers today seeking the most number of client sockets target at least iOS and Android, often simultaneously. It is too early to pick a winner.

Some would say that the role of the cloud services or the browser make app development less about the “client” socket.  The data, however, suggests that customers prefer the interaction approach and integration capability of apps and certainly platform builders touting the size of app stores further evidences that perspective.  Even the smallest amount of “dependency” (for customers or technical reasons) on the client’s unique capabilities can provide benefits or dramatically improve the quality of the overall experience.

In discussions with entrepreneurs I have had, it is clear the approach to cross-platform is shifting from “obviously we will do multiple platforms” to thinking about which platform comes first, second, or third and how many to do.  Chris Dixon recently had some thoughts about this in the context of modern app development in general (tablets and/or phones).  I would agree that tablets drive a different type of app over time simply because the scenarios can be quite different even with identically capable devices under the hood.  The cross-platform question only gets more difficult if apps take on unique capabilities or user experiences for different sized screens, which is almost certainly the case.

History

The history of cross-platform development is fairly well-known by app developers.

The goal of an app developer is to acquire as many customers as possible or to have the highest quality engagement with a specific set of customers.  In an environment where customers are all using one platform (by platform we mean set of APIs, tools, languages that are used to build an app) the choice for a developer is simple, which is to target the platform APIs in a fully exploitive manner.

The goal of being the “best” app for the platform is a goal shared by both app and platform developers.  The reason for this is that nearly any app will have app competitors and one approach to differentiation will be to be the app that is best on the platform—at the very least this will garner the attention of the platform builder and result in amplification of the marketing and outreach of a given app (for example, given n different banking apps, the one that is used in demonstrations or platform evangelism will be the one that touts the platform advantages).

Once developers are faced with two or more platforms to target, the discussion typically starts with attempting to measure the size of the customer base for each platform (hence the debate today about whether market share or revenue define a more successful platform).  New apps (at startups or established companies) will start with a dialog that depending on time or resources jumps through incredible hoops to attempt to model the platform dynamics.  Questions such as which customers use which platforms, velocity of platform adoption, installed base, likelihood of reaching different customers on platforms, geography of usage, and pretty much every variable imaginable.  The goal is to attempt to define the market impact of either support multiple platforms or betting on one platform.  Of course none of these can be known.  Observer bias is inherent in the process only because this is all about forecasting a dynamic system based on the behavior of people. But basing a product plan on a rapidly evolving and hard to define “market share” metric is fraught with problems.

During this market sizing debate, the development team is also looking at how challenging cross platform support can be.  While mostly objective, just as with the market sizing studies, bias can sneak in.  For example, if the developers’ skills align with one platform or a platform makes certain architectural assumptions that are viewed favorably then different approaches to platform choices become easy or difficult.

Developers that are fluent in HTML might suggest that things be done in a browser or use a mobile browser solution.  Even the business might like this approach because it leverages an existing effort or business model (serving ads for example).  Some view the choices Facebook made for their mobile apps as being influenced by these variables.

As the dialog continues, developers will tend to start to see the inherent engineering costs in trying to do a great job across multiple platforms.  They will start to think about how hard it is to keep code bases in sync or where features will be easier/harder or appear first or even just sim-shipping across platforms.  Very quickly developers will generally start to feel pulled in an impossible direction by having to be across multiple platforms and that it is just not viable to have a long-term cross-platform strategy.

The business view will generally continue to drive a view that the more sockets there are the better.  Some apps are inherently going to drive the desire or need for cross-platform support.  Anything that is about communications for example will generally argue for “going where the people are” or “our users don’t know the OS of their connected endpoints” and thus push for supporting multiple platforms.  Apps that are offered as free front ends for services (online banking, buying tickets, or signing up for yoga class) will also feel pressures to be where the customers are and to be device agnostic.  As you keep going through scenarios the business folks will become convinced that the only viable approach is to be on all the popular platforms.

That puts everyone in a very tense situation—everyone is feeling stressed about achieving success. Something has to give though.

We’ve all been there.

Pattern

The industry has seen this cross-platform movie several times.  It might not always be the same and each generation brings with it new challenges, new technologies, and potentially different approaches that could lead to different outcomes. Knowing the past is important.

Today’s cross-platform challenge can be viewed differently primarily because of a few factors when looking at the challenge from an app developer / ISV:

• App Services.  Much of the functionality for today’s apps resides on software as a service infrastructure.  The apps themselves might be viewed as fairly lightweight front ends to these services, at least for some class of apps or some approaches to app building. This is especially true today as most apps are still fairly “first generation”.
• Languages and tools.  Today’s platforms are more self-contained in that the languages and tools are also part of the platform.  In previous generations there were languages that could be used across different platforms (COBOL, C, C++) and standards for those languages even if there were platform-specific language extensions.  While there are ample opportunities for shared libraries of “engine” code in many of today’s platforms, most modern platforms are designed around a heavy tilt in favor of one language, and those are different across platforms.  Given the first point, it is fair to say that the bulk of the code (at least initially) on the device will be platform specific anyway.
• Integration.  Much of what goes on in apps today is about integration with the platform.  Integration has been increasing in each generation of platform shifts.  For example, in the earliest days there was no cross-application sharing, then came the basics through files, then came clipboard sharing.  Today sharing is implicit in nearly every app in some way.

Even allowing for this new context, there is a cycle at work in how multiple, competing platforms evolve.

This is a cycle so you need to start somewhere.

Initially there is a critical mass around one platform. As far as modern platforms go when iOS was introduced it was (and remains) unique in platform and device attributes so mobile apps had one place to go and all the new activity was on that platform.  This is a typical first-mover scenario in a new market.

Over time new platforms emerge (with slightly different characteristics) creating a period of time where cross-platform work is the norm.  This period is supported by the fact that platforms are relatively new and are each building out the base infrastructure which tends to look similar across the new platforms.

There are solid technical reasons why cross-platform development seems to work in the early days of platform proliferation.  When new platforms begin to emerge they are often taking similar approaches to “reinventing” what it means to be a platform.  For example, when GUI interfaces first came about the basics of controls, menus, and windows were close enough that knowledge of one platform readily translated to other platforms.  It was technically not too difficult to create mapping layers that allowed the same code to be used to target different platforms.

During this phase of platform evolution the platforms are all relatively immature compared to each other.  Each is focused on putting in place the plumbing that approaches platform design in this new shared view.  In essence the emerging platforms tend to look more similar that different. The early days of web browsers–which many believed were themselves platforms–followed this pattern.  There was a degree of HTML that was readily shared and consistent across platforms.  At least this was the case for a while.

During this time there is often a lot of re-learning that takes place.  The problems solved in the previous generation of platforms become new again.  New solutions to old problems arise, sometimes frustrating developers.  But this “new growth” also brings with it a chance to revisit old assumptions and innovate in new ways, even if the problem space is the same.

Even with this early commonality, things can be a real challenge.  For example, there is a real desire for applications to look and feel “native”.  Sometimes this is about placement of functionality such as where settings are located.  It could be about the look or style of graphical elements or the way visual aspects of the platform are reflected in your app.  It could also be about highly marketed features and how well your app integrates as evidence for supporting the platform.

Along the way things begin to change and the platforms diverge because of two factors.  First, once the plumbing common to multiple early platforms is in place, platform builders begin to express their unique point of view of how platform services experiences should evolve.  For example, Android is likely to focus on unique services and how the client interacts with and uses those services. To most, iOS has shown substantially more innovation in client-side innovation and first-party experiences. The resulting APIs exposed to developers start to diverge in capabilities and new API surface areas no longer seem so common between platforms.

Second, competition begins to drive how innovation progresses.  While the first mover might have one point of view, the second (or third) mover might take the same idea of a service or API but evolve it slightly differently.  It might integrate with backends differently or it might have a very different architecture.  The role of voice input/reco, maps, or cloud storage are examples of APIs that are appearing on platforms but the expression of those APIs and capabilities they support are evolving in different ways that there are no obvious mappings between them.

Challenges

As the platforms diverge developers start to make choices about what APIs to support on each platform or even which platforms to target.  With these choices come a few well known challenges.

• Tools and languages.  Initially the tools and languages might be different but things seem manageable.  In particular, developers look to put as much code in common languages (“platform agnostic code”) or implement code as a web service (independent of the client device). This is a great strategy but does not allow for the reality that a good deal of code (and differentiation) will serve as platform-specific user experience or integration functionality.  Early on tools are relatively immature and maybe even rudimentary which makes it easier to build infrastructure around managing a cross-platform project.  Over time the tools themselves will become more sophisticated and diverge in capabilities.  New IDEs or tools will be required for the platforms in order to be competitive and developers will gravitate to one toolset, resulting in developers themselves less able to context switch between platforms. At the very least, managing two diverging code bases using different tools becomes highly challenging–even if right now some devs think they have a handle on the situation.
• User interaction and design (assets).  Early in platform evolution the basics of human interaction tend to be common and the approaches to digital assets can be fairly straight forward.  As device capabilities diverge (DPI, sensors, screen sizes) the ability for the user interaction to be common also diverges.  What works on one platform doesn’t seem right on another.  Tablet sized screens introduce a whole other level of divergence to this challenge. Alternate input mechanisms can really divide platform elements (voice, vision, sensors, touch metaphors).
• Platform integration.  Integrating with a platform early on is usually fairly “trivial”.  Perhaps there are a few places you put preferences or settings, or connect to some platform services such as internationalization or accessibility.  As platforms evolve, where and how to integrate poses challenges for app developers.  Notifications, settings, printing, storage, and more are all places where finding what is “common” between platforms will become increasingly difficult to impossible.  The platform services for identity, payment, and even integration with third party services will become increasingly part of the platform API as well. When those APIs are used other benefits will accrue to developers and/or end-users of apps—and these APIs will be substantially different across platforms.
• More code in the service.  The new platforms definitely emphasize code in services to provide a way to be insulated from platform changes.  This is a perfect way to implement as much of your own domain as you can.  Keep in mind that the platforms themselves are evolving and growing and so you can expect services provided by the platform to be part of the core app API as well.  Storage is a great example of this challenge.  You might choose to implement storage on your own to avoid a platform dependency.  Such an approach puts you in the storage business though and probably not very competitively from a feature or cost perspective.  Using a third party API can pose the same challenge as any cross-platform library. At the same time, the platforms evolve and likely will implement storage APIs and those APIs will be rich and integrate with other services as well.
• Cross-platform libraries.  One of the most common approaches developers attempt (and often provided by third parties as well) is to develop or use a library that abstracts away platform differences or claims to map a unique “meta API” to multiple platforms.  These cross—platform libraries are conceptually attractive but practically unworkable over time. Again, early on this can work. Over time the platform divergence is real.  There’s nothing you can do to make services that don’t exist on one platform magically appear on another or APIs that are architecturally very different morph into similar architectures.  Worse, as an app developer you end up relying on essentially a “shadow” OS provided by a team that has a fraction of the resources for updates, tooling, documentation, etc. even if this team is your own dev team. As a counter example, games commonly use engines across platforms, but they rely on a very narrow set of platform APIs and little integration. Nevertheless, there are those that believe this can be a path (as it is for games).  It is important to keep in mind that the platforms are evolving rapidly and the customer desire for well-integrated apps (not just apps that run).
• Multiple teams.  Absent the ability to share app client code (because of differing languages), keeping multiple teams in sync on the same app is extremely challenging.  Equally challenging is having one team time slice – not only is that mentally inefficient, maintaining up to date skills and knowledge for multiple platforms is challenging.  Even beyond the basics of keeping the feature set the same, there are problems to overcome.  One example is just timing of releases.  It might be hard enough to keep features in sync and sim ship, but imagine that the demand spike for a new release of your app when the platform changes (and maybe even requires a change to your app).  You are then in a position to need a release for one platform.  But if you are halfway done with new features for your app you have a very tricky disclosure and/or code management challenge.  These challenges are compounded non-linearly as the number of platforms increases.

These are a few potential challenges.  Not every app will run into these and some might not even be real challenges for a particularly app domain.  By and large, these are the sorts of things that have dogged developers working cross-platform approaches across clients, servers, and more over many generations.

What’s next?

The obvious question will continue to be debated, which is if there is a single platform winner or not.  Will developers be able to pick a platform and reach their own business and product goals by focusing on one platform as a way of avoiding the issues associated with supporting multiple platforms?

The only thing we know for sure is that the APIs, tools, and approaches of different platforms will continue to evolve and diverge.  Working across platforms will only get more difficult, not easier.

The new platforms moved “up the stack” and make it more difficult for developers to isolate themselves from the platform changes.  In the old days, developers could re-implement parts of the platform within the app and use that across platforms or even multiple apps.  Developers could hook the system and customize the behavior as they saw fit.  The more sealed nature of platforms (which delivers amazing benefits for end-users) makes it harder for developers to create their own experience and transport it across platforms.  This isn’t new.  In the DOS era, apps implemented their own printing subsystems and character-based user models all of which got replaced by GUI APIs all to the advantage of developers willing to embrace the richer platforms and to the advantage of customers that gained a new level of capabilities across apps.

The role of app stores and approval processes, the instant ability for the community to review apps, and the need to break through in the store will continue to drive the need to be great apps on the chosen platforms.

Some will undoubtedly call for standards or some homogonization of platforms.  Posix in the OS world,  Motif in the GUI world, or even HTML for browsers have all been attempts at this.  It is a reasonable goal given we all want our software investments to be on as many devices as possible (and this desire is nothing new).  But is it reasonable to expect vendors to pour billions into R&D to support an intentional strategy of commoditization or support for a committee design? Vendors believe we’re just getting started in delivering innovation and so slowing things down this way seems counter-intuitive at best.

Ultimately, the best apps are going to break through and I think the best apps are going to be the ones that work with the platform not in spite of it and the best apps won’t duplicate code in the platform but work with platform.

It means there some interesting choices ahead for many players in these ecosystems.

–Steven

# # # # #