Learning by Shipping

products, development, management…

Juggling multiple platforms and the bumpy road ahead

with 22 comments

Cross-platform cycleTargeting 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

# # # # #

Written by Steven Sinofsky

July 8, 2013 at 5:00 am

22 Responses

Subscribe to comments with RSS.

  1. I don’t even know the way I finished up right here, but I thought this submit was once good. I do not realize who you’re however certainly you’re going to a well-known blogger when you are not already. Cheers!

    ihnflthr@gmail.com

    November 13, 2014 at 8:30 am

  2. There is a difference between today platform war and previous years platform war: user base size.
    When windows won the user base was in millions, this year iOS will pass one billion users target and Android passed the target last year.
    App developer do want to reach as many users as possible, but a user base of one billion is enough to allow an app to thrive, the effort required to have a two billion users target can be made once the app has lift off, there is no need to target two or more platforms from the start.
    If you concentrate to get the most from your first platform and have success than porting will follow. Usually the platform with the most spending users is chosen, iOS, but really the size of the installed user base is not a issue, both iOS and Android have won and have enough users to remain effective in the future.

  3. pycve diumd 2012 ダウンジャケット モンクレール ダウン レディース knvwj eaylwo Blogger: 小倫角落 – Post a Comment mekegum moncler 新作 モンクレー セール aarrhyt xzkic モンクレー 新作 ダウン モンクレー hkhxoerf ef bottes ugg origine bottes ugg made in australia uoqomxbq

    Soledad

    October 23, 2013 at 2:41 am

  4. I pay a quick visit day-to-day a few sites and information
    sites to read posts, but this blog presents quality based articles.

    Florine

    October 9, 2013 at 9:34 am

  5. BB:I must say I enjoy re-reading your article. As to my fandig memory bank …. well I still couldn’t tell you a thing as to what I was going to say a-year-and-a-half ago.Anyway, here are my belated comments :PAt the beginning of your article, I think what you were defining “governance” – how a tribe / community / society /country organizes its functions and manages its members.However, towards the end of the article, you were talking about something else.In my humble opinion, governance 治理 is not the same as government政府, which is related to but not the same as politics 政治.

    Deyse

    August 2, 2013 at 5:11 pm

  6. Very nice perspective on developing apps for multiple platforms.

  7. Whether Windows 8 was/is great is irrelevant. The consumer has not embraced the product and the stock market has now voted. A $32 billion decrease in value cannot be ignored. From a manufacturing and feature standpoint, the Edsel was a great car. But as we all know it was not embraced by those spending the money. MS will need to change it’s vision to match end user taste or the future will not be a bright one. Windows 8 may be a developers dream, but your market does not seem to like it.

    Brian

    July 20, 2013 at 9:01 am

  8. Great Blog, but doesnt MEAP are trying to address this cross platform issues to an extent?

    Shammy

    July 18, 2013 at 11:55 am

  9. Sweet blog! I found it while browsing on Yahoo News. Do you have any tips on how
    to get listed in Yahoo News? I’ve been trying for a while but I never seem to get there! Appreciate it

  10. Superb blog! Do you have any recommendations for aspiring writers?
    I’m planning to start my own blog soon but I’m a little lost on everything.

    Would you recommend starting with a free platform like WordPress or go for a paid
    option? There are so many choices out there that I’m totally overwhelmed .. Any ideas? Thank you!

    Mario

    July 12, 2013 at 9:12 pm

  11. I shipped my first (intended for tablets) app on Windows Store last month by way of learning. Learning because I’m pretty certain my understanding is closer to DOS1.0 than WindowsMillenium end of the scale.
    For grasping native experience to be felt by users, I consumed applabs. I’m bootstrapping tablet app development business so let me particularly thank you for enumerating your as an experienced products developer insights in this post which I find most valuable.
    I’ve to raise some points that I wish you to touch in the next post on apps marketplace.
    1. You’ve enlisted some mobile handset OSs namely Windows Phone, iOS as modern sealed-case platforms. Is Windows RT so different from Chrome, MacOS, or any other PC OS?
    2. You’ve mentioned cloud computing, that as per my comprehension is modern morph of primitive time sharing commercialized by IBM Series 360 mainframe during 60’s, now making use of advances in hardware virtualization with the very same goal: scalable resource provisioning. The most lovable part is the data center carbon footprints. Online search (or more correctly) advertising giant with support from government intermediary agents particularly love the network is the stalker (was it Java CEO who said that?) cloudy aspects. Users were in control of clipboard content with drag-drop copy-paste, so if notepad will not understand Powerpoint, unlike cloud-sync amongst devices, user is well trained with specific device. This is analogous with post-man will use any (cross-platform) pen, but CEOs signing bank demand drafts might use specific (native) pen with great comfort.
    I raised this point with regards to wanting development build-chain of framework library toolkits and end result apps to be native vs. cross-platform. Phones being ubiquitous may need to be cross-platform, but if tablet will run Windows Phone/Android instead of native experience oriented Chrome_RT/MacOS_RT, then to which extent will it be PC-capability-disabled idiot box+oversized phone+overpriced low-end gaming console?
    3. On history, sockets and cross-platform: One role which may be implemented by an OS is Virtual Machine Manager allowing to administer tightly coupled hypervisors, for e.g.. one hypervisor will run rival platform of POSIX, say SilverJVM; another (hypervisor) is Web Browser running W3.org platform such as Boot2Gecko (B2G). Engineering exams allow scientific calculators- and with cloud tablet (mobile calculator) as de facto handheld computation device’s (sales & marketing) promotions, should military network jammers be dispatched on sites like MIT and other academic+research institutes that hosted the earliest ARPAnet DNS servers, to compel continued use of archaic systems that users will find annoyingly holding them back as world technologically advances.. Maybe client socket reserves shall be made for dead tree log tables and so forth.. The unseen delights nee biased reservations held by future! :P
    4. ISV/language/integrator: To begin with observe ISO C++ has templates (that supports) meta-programming and templates come with their own standard library, so generic programming paradigm librarian (shortened library developer) sees vector (container), while the coder/developer/architect sees bank accounts clubbed together. The trouble here is more with syncing the (diploma) coder, (bachelor’s graduate) developer, and (masters post-graduate) architect who tend to advance out-of-step with each other while improvising the next iteration of products. For simpler apps this is as simple as pick the latest framework version available from you. For sophisticated (costly) ones, its heavy-lifting to deliver updates without breaking early implementations (IE6 was supported around when IE9 was paraded as current version). And that’s difficult, I’d hate to be in your shoes overlooking the huge responsibilities you did.. but then I’ve long way to go.
    My point here is invest in framework once to alleviate the tough situations that are clearly in-sight. ISO C++ was just my pick to highlight the path on map.
    5. Challenges/cross-platform libraries/”shadow meta API”: Games are just tip of the ice-berg. When I aimed to make native modern UI app that might consume Portable Class Library from F#, I never imagined to bother with CX, but it was either that or wheel reinventions. Now that I’ve successfully complied with Store requirements (initial battle), the war (usability guidelines applicability) related with apps domain-specific (Productivity category of the store in my case) features has just begun. Over dependence on meta APIs might be poor choices, still very thin layer APIs (like C++/CX has thin wrappers, namely, Platform::Vector or Platform::String) have to be identified early on to save from unpleasant developments later.
    This is my job as an architect for my product line choice of productivity apps.

    I’ll answer one of your questions: What’s next? 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?
    These difficulties will bifurcate the smart and honorable (sometimes flamboyant) soldiers from the punk (jerk) bullies at least.
    The other regarding billions spent, that’s some CEOs concerns who know when to discontinue successful products citing branding difficulty or go on buying spree.

    Finally, I’ve hardly opened my eyes in the development business world, so if my views exhibit lack of awareness of some hard-pressing issues or are not well-formed in some way, forgive me- laugh at my expense and cover anything of relevance in some other interaction elsewhere for us newcomers to follow..
    Regards.

    Vipul S. Chawathe

    July 10, 2013 at 10:06 am

  12. Hi Steven, thank you for the thoughtful and insightful post.

    The challenges of cross platform are great, especially for my world in the mid-sized enterprises space. Companies with few developers, limited budget (under $10m per year) and limited time to make the biggest bang for the buck.

    I actually enjoy the challenges in this emerging platform landscape. And this fast pace will only continue, in my opinion. Wearable/portable devices are disposable…giving ecosystem providers many more opportunities to grab consumers than in the past. Many of us change devices (and ecosystems) every 2 years.

    For the most part, I encourage a bare minimum client that solves the business need…and back-end (cloud) all that is not device specific. Event client-side logic can be downloaded once and stored locally to save data minutes and keep the app agile.

    Being in the mid-sized business world, we keep our programming languages to a minimum. MVC .Net for web and XAML for native are our choice, thanks to cross platform tools that integrate directly into Visual Studio. In some limited cases, we code natively in a device-specific language…but those situations are rare.

    On a personal note, I cannot speak highly enough about you and your team’s Windows 8 “Metro” architecture and implementation. The horizontal ecosystem (apps sharing data & functionality with other apps via contracts) is unmatched in any platform. The security and power performance introduced by the “If you see the app, its running. If you don’t see it, it is suspended” also has no equal. The app integration with Windows via Share, Search, etc. is a dream for developers. Not to mention all of the non-app revolutions.

    Thank you for your work and hope you are enjoying your new callings in life!

    Robert J. Good

    July 10, 2013 at 9:41 am

  13. Thank you for the kind words DavidI — I will be in touch.

    Steven Sinofsky

    July 9, 2013 at 11:22 am

  14. Excellent post. Got me thinking about how the platform concept might be evolving.

    Today you can broadly say that a ‘platform’ is the software layer bound to a particular hardware device or family of devices that enables it to support a variety of apps. The idea being to make it general purpose and of course to sell a gazillion units (or mine the analytics of their use!).

    But, I can envision a world where increasingly devices will proliferate and narrow in purpose. So rather than being a generic app host, they become narrow-purpose devices. When hardware is cheap (and wearable), this isn’t so far-fetched. I can imagine my phones, glasses, watches, TVs, game consoles, fitness sensors, go-pro cameras, tablets, car, and ski goggles all being app enabled (but largely used or suitable for only one or a few apps).

    Who knows, but maybe eventually the morphing of devices into specific use scenarios makes the cross-platform app development problem moot. Of course the new problem then is how do you train your ObjectiveC and Java devs to use soldering irons and 3d printers!

    Ed English

    July 9, 2013 at 10:29 am

  15. Add me to your list of fans Steven. Have always loved the level of insight you provide and your willingness to share details.

    Lionel Menchaca Jr.

    July 9, 2013 at 7:12 am

  16. Steve – thank you so much for the great blog post. We are shipping support for Windows(32/64), Mac OSX and iOS with our Embarcadero Delphi XE4 product. We use our FM Component Framework to encapsulate all of the common capabilities of Desktop and Mobile platforms. We have refactored and updated the components over 3 generations (now) of product releases. Using native code optimizing compilers for each platform we can also give developers access to the operating system APIs and to the hardware. We have also built multi-platform Device, Sensor and Platform Services into the component framework to provide single source code project access across the platforms.

    Next up is Android support using the same component framework. I agree that in shipping products we learn each time how to provide a visual design IDE, rapid software prototyping workflow and the ability to build components and extend components in the FM Component Framework. Adding support for services via SOAP and REST helps connect to the interfaces of server and cloud functionality. We also ship all of the source code to the FM Component Framework and RTL for all platforms we support, so that developers can see how we do it and also can learn how to build in additional components. We also have Windows (32/64) and Mac OSX support in our C++Builder product.

    We definitely learn by shipping. The great thing about developers is they will tell you 24×7 what they like and don’t like. Using component based development allows us to keep the same interfaces while continuously implementing and improving the underpinnings.

    On a personal note, I still have a copy of the video I shot of you, Bill Gates, Richard Hale Shaw, Paul Gross and a Waggoner PR member in our Borland booth at Comdex when you were Bill’s technology advisor. I was video taping Bill watching a Borland C++ presentation in the booth. After a few minutes Bill said something to you and then you came over to me and asked me to stop taping. Of course I did. Maybe you remember that day in our Comdex booth?

    I have always been a Steve Sinofsky fan! Keep up the great work now in your educational and industry perspectives roles.

    David Intersimone “David I”
    VP, Developer Relations and Chief Evangelist
    Embarcadero Technologies
    davidi@embarcadero.com

    David Intersimone

    July 9, 2013 at 6:31 am

  17. Hi Steven,

    Nice read..

    Primarily I feel that the debate for supporting multiple platform falls on the costs for developing and maintaining the applications across all platforms. Additionally the reach each platform has, plays a important role in determining if the investment is wise or not.

    More importantly, My belief is there is no winner or losers in this. Its who delivers a compelling developer experience that allows platforms to accomplish more, and design improved products/apps for their customers. As you said, its a cycle and it all boils down to how a given platform provider leap frogs to give a more complete/feature rich development experience from its predecessor.

    For each player (app platform provider) who intends to enter this playing field to make an impact, gather the market attention and share, shouldn’t the goal be to create an engineering ecosystem that is easy to develop for and provide compelling features so that the developer community takes a active interest in developing apps.

    Now obviously the million dollar question. What should the engineering strategy be to provide a compelling developer experience. Times are changing and virtual services are becoming more prominent. What would be your take on reworking a platform to take advantage of the horsepower the virtual processing power offers to develop more feature rich platforms.

    Would be nice to hear (follow up blog may be!) your take on what should be the engineering strategy to build a developer experience that developers naturally take to writing apps on or code.

    Just curious, When at Harvard and working with the student -startups what was your advice to competing with more established competitors.

    -ash

    ash

    July 8, 2013 at 4:05 pm

  18. Steven. Great description on the competing voices for what directs native vs. cross platform development. I still have the siren song from Sun ringing in my ears from 1994 “Java = write once, run everywhere”. Having spent 12 years at a major platform provider (in Cupertino), I understand the business pressure developers have to be one as many screens with abbreviated effort. While in the short run, that goal may be achieved, long term, the developer is painted into a corner (API changes, etc) Whether its Windows Mobile, Android or iOS, build native . . . always.

    A much better description of this is found at the excellent blog post by Twitter engineer Ben Sandofsky, titled “Shell Apps and Silver Bullets”

    https://sandofsky.com/blog/shell-apps.html

    – Erik

  19. Hmm…that doesn’t sound like Windows has much of a shot in mobile then.

    Bob

    July 8, 2013 at 12:51 pm

  20. Thank you Mr. Sinofsky for this excellent analysis of the subject of cross platform development. Most interesting, even from a non programmer perspective.
    Claude Filimenti

    macmaitre

    July 8, 2013 at 10:37 am

  21. thanks naveen

    Steven Sinofsky

    July 8, 2013 at 10:25 am

  22. Very nice article. I am fan of yours. Hope to work with you someday.

    Naveen.

    Naveen

    July 8, 2013 at 8:13 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s