Tag Archives: cross-platform

apple, microsoft, tech

Office 2016 now “built out of one codebase for all platforms” says Microsoft engineer

Microsoft’s Erik Schweibert, principal engineer in the Apple Productivity Experiences group, says that with the release of Office 2016 version 16 for the Mac, the productivity suite is now “for the first time in 20 years, built out of one codebase for all platforms (Windows, Mac, iOS, Android).”

image

This is not the first time I have heard of substantial code-sharing between the various versions of Office, but this claim goes beyond that. Of course there is still platform-specific code and it is worth reading the Twitter thread for a more background.

“The shared code is all C++. Each platform has native code interfacing with the OS (ie, Objective C for Mac and iOS, Java for Android, C/C++ for Windows, etc),” says Schweibert.

Does this mean that there is exact feature parity? No. The mobile versions remain cut-down, and some features remain platform-specific. “We’re not trying to provide uniform “lowest common denominator” support across all platforms so there will always be disparate feature gaps,” he says.

Even the online version of Office shares much of the code. “Web components share some code (backend server is shared C++ compiled code, front end is HTML and script)”, Schweibert says.

There is more news on what is new in Office for the Mac here. The big feature is real-time collaborative editing in Word, Excel and PowerPoint. 

What about 20 years ago? Schweibert is thinking about Word 6 for the Mac in 1994, a terrible release about which you can read more here:

“Shipping a crappy product is a lot like beating your head against the wall.  It really does feel good when you ship a great product as a follow-up, and it really does motivate you to spend some time trying to figure out how not to ship a crappy product again.

Mac Word 6.0 was a crappy product.  And, we spent some time trying to figure out how not to do that again.  In the process, we learned a few things, not the least of which was the meaning of the term “Mac-like.”

Word 6.0 for the Mac was poor for all sorts of reasons, as explained by Rick Schaut in the post above. The performance was poor, and the look and feel was too much like the Windows version – because it was the Windows code, recompiled. “Dialog boxes had "OK" and "Cancel" exactly reversed compared to the way they were in virtually every other Mac application — because that was the convention under Windows,” says one comment.

This is not the case today. Thanks to its lack of a mobile platform, Microsoft has a strong incentive to create excellent cross-platform applications.

There is more about the new cross-platform engineering effort in the video below.

c++, development, microsoft, professional, software, software development, visual studio, windows

Coding Office for cross platform: Microsoft explains its approach

4 Comments

At last month’s @Scale conference in San Francisco, developers from a number of well-known companies (Google, Facebook, Twitter, Dropbox and others) spoke about the challenge of scaling applications and services to millions or even billions of users.

Among the speakers was Igor Zaika, Distinguished Engineer in the Microsoft Office team, and the video (embedded below) is illuminating not only as an example of how to code across multiple platforms, but also as an insight into where the company is taking Office.

Zaika gives a brief résumé of the history of Office, mentioning how the team has experienced the highs and lows of cross-platform code. Word 6.0 (1993) was great on Windows but a disaster on the Mac. The team built an entire Win32 emulation layer for the Mac, enabling a high level of code reuse, but resulting in a poor user experience and lots of platform-specific bugs and performance issues in the Mac version.

Next came Word 98 for the Mac, which took the opposite approach, forking the code to create an optimized Mac-specific version. It was well received and great for user experience, but “it was only fun for the first couple of years,” says Zaika. As the Windows version evolved, merging code from the main trunk into the Mac version became increasingly difficult.

Today Microsoft is committed not only to Mac and Windows versions of Word, but to all the major platforms, by which Zaika means Apple (including iOS), Android, Windows (desktop and WinRT) and Web. “If we don’t, we are not going to have a sustainable business,” he says.

WinRT is short for the Windows Runtime, also known as Metro, or as the Store App platform. Zaika says that the relationship between WinRT and Win32 (desktop Windows) is similar to that between Apple’s OS X and iOS.

Time for a brief digression of my own: some observers have said that Microsoft should have made a dedicated version of Windows for touch/mobile rather than attempting to do both at once in Windows 8. The truth is that it did, but Microsoft chose to bundle both into one operating system in Windows 8. Windows RT (the ARM version used in Surface RT) is a close parallel to the iPad, since only WinRT apps can be installed. What seems to be happening now is that Windows Phone and Windows RT will be merged, so that the equivalence of WinRT and iOS will be closer and more obvious.

Microsoft’s goal with Office is to achieve high content fidelity and consistency of functionality across all platforms, but to use native UX/UI frameworks so that each version integrates properly with the operating system on which it runs. The company also wants to achieve a faster shipping cycle; the traditional two-year cycle is not fast enough, says Zaika.

What then is Microsoft’s technical strategy for cross-platform Office now? The starting point, Zaika explains, is a shared core of C++ code. Office has always been written in C/C++, and “that has worked out well for us,” he says, since it is the only language that compiles to native code across all the platforms (web is an exception, and one that Zaika did not talk much about, except to note the importance of “shared service code,” cloud-based code that is used for features that do not need to work offline).

In order for the shared non-visual code to work correctly cross-platform, Microsoft has a number of platform abstraction layers (PALs). No #ifdefs (to handle platform differences) are allowed in the shared code itself. However, rather than a monolithic Win32 emulation as used in Word 6.0 for the Mac, Microsoft now has numerous mini-PALs. There is also a willingness to compromise, abandoning shared code if it is necessary for a good platform experience.

image

How do you ensure cross-platform fidelity in places where you cannot share code? The alternative is unit testing, says Zaika, and there is a strong reliance on this in Office development.

There is also an abstraction layer for document rendering. Office requires composition, animation and touch APIs on each platform. Microsoft uses DirectX on Win32, a thin layer over Apple’s CoreAnimation API on Mac and iOS, a thin layer over XAML on WinRT, and a thinnish layer over Java on Android.

The outcome of Microsoft’s architectural work is a high level of code sharing, despite the commitment to native frameworks for UX. Zaika showed a slide revealing code sharing of over 95% for PowerPoint on WinRT and Android.

image

What can Microsoft-watchers infer from this about the future of Office? While there are no revelations here, it does seem that work on Office for WinRT and for Android is well advanced.

Office for WinRT has implications for future Windows tablets. If a version of Office with at least the functionality of Office for iPad runs on WinRT, there is no longer any need to include the Windows desktop on future Windows tablets – by which I mean not laptop replacements like Surface 3.0, but smaller tablets. That will make such devices less perplexing for users than Surface RT, though with equivalent versions of Office on both Android and iOS tablets, the unique advantages of Windows tablets will be harder to identify.

Thanks to WalkingCat on Twitter for alerting me to this video.

bbc, development, mobile, professional

The cross-platform app problem. What should the BBC do?

5 Comments

The BBC released a new sports app last week. In the comments to the announcement though, there is little attention given to the app or its content. Rather, the discussion is about why the BBC has apparently prioritised iOS over Android, since the Android version is not yet ready, with an occasional interjection from a Windows Phone user about why there is nothing at all for them.

image

BBC I think you need to actually catch up on what’s happening. Android is huge now. You should be launching both platforms together. A lot of people I know have switched to an Android device and your app release almost feels like discrimination!

says one user; while the BBC’s Lucie Mclean, product manager for mobile services, replies:

Back in July, when we launched the Olympics app for iPhone and Android together, we saw over three times as many downloads of the iPhone version. Android continues to grow apace but this, together with the development and testing complexity, led us to the decision to phase the iOS app first.

BBC Technology correspondent spoke to head of iPlayer David Danker about this problem back in December. Danker claims that the BBC spends more “energy” (I am not sure if that means time or just frustration) on Android than Apple, and mainly blames Android fragmentation and the existence of more low-end devices for the delays:

It’s not just fragmentation of the operating system – it is the sheer variety of devices. Before Ice Cream Sandwich (an early variant of the Android operating system) most Android devices lacked the ability to play high quality video. If you used the same technology as we’ve always used for iPhone, you’d get stuttering or poor image quality. So we’re having to develop a variety of approaches for Android

A couple of things are obvious. One is that Apple’s clearly-defined iOS development platform and limited range of devices is a win for developers. Despite frustrations over things like the way apps are sandboxed or Apple’s approval process, it is easier to target iOS than Android because the platform is more consistent. iOS users are also relatively prosperous and highly engaged with the web and the app store, so that even though Apple’s overall platform market share has fallen behind that of Android, it is still the most important market in some contexts.

Another is that the BBC cannot win. From a PR perspective, it should probably do simultaneous iOS and Android releases even if that means a delay, but even then there will be complaints over differences in detail between iOS and Android implementations. Further, the voices of those neglected minorities, such as Windows Phone and soon, Blackberry 10 users, will grow louder if iOS and Android achieve parity.

In all this, it is worth noting that the BBC gets one thing right, prioritising the mobile web:

The decision to launch the core mobile browser site first (before either app) was itself to ensure that users got a quality product across as wide a range of devices as possible.

says Mclean.

Personally I wonder if the the BBC needs to do all these niche apps. The iPlayer app is the one that really matters, particularly when it offers download for offline viewing, but is a sports app so necessary?

Should it not concentrate instead on first, the mobile web site, and second, APIs that third-party developers can use, enabling developers on each platform to create high quality apps?

Another option would be to make cross-platform a religion, and cover all significant platforms while giving up some of the benefits of native code. High quality video is a problem; but in many scenarios the quality of the video is not such a big issue provided that it works and is intelligible.

Perhaps the BBC could make Cordova (an open source framework for cross-platform mobile apps) video work better. Having the BBC invest its publicly funded resources into open source cross-platform development is better PR than developing expensive apps for single platforms.

apple, delphi, development, software, software development

Delphi XE2 FireMonkey for Windows, Mac, iOS: great idea, but is it usable?

19 Comments

I am sure all readers of this blog will know by now that Delphi XE2 (and RAD Studio XE2) has been released, and that to the astonishment of Delphi-watchers it supports not only 64-bit compilation on Windows, but also cross-platform apps for Windows, Mac OS X and even iOS for iPhone and iPad (with Android promised).

I tried this early on and was broadly impressed – my app worked and ran on all three platforms.

image

However it is an exceedingly simple app, pretty much Hello World, and there are some worrying aspects to this Delphi release. FireMonkey is based on technology from KSDev, which was acquired by Embarcadero in January this year. To go from acquisition to full Delphi integration and release in a few months is extraordinary, and makes you wonder what corners were cut.

It seems that corners were cut: you only have to read this post by developer and Delphi enthusiast Chris Rolliston:

To put it bluntly, FireMonkey in its current state isn’t good enough even for writing a Notepad clone (I know, because I’ve been trying). You can check out Herbert Sauro’s blog for various details (here, also a follow up post here). For my part, here’s a highish-level list of missing features and dubious coding practices, written from the POV of FireMonkey being a VCL substitute on the Mac (since on OS X, that is what it is).

Fortunately I did not write a Notepad clone, I wrote a Calculator clone, which explains why I did not run into as many problems.

Update: See also A look at the 3D side of FireMonkey by Eric Grange:

…if you want to achieve anything beyond a few poorly texture objects, you’ll need to design and write a lot of custom code rather than rely on the framework… with obvious implications of obsolescence and compatibility issues whenever FMX finally gets the features in standard.

There has already been an update for Delphi XE2 which is said to fix over 120 bugs as well as an open source licensing issue. I also noticed better performance for my simple iOS calculator after the update.

Still, FireMonkey early adopters face some significant issues if they are trying to make VCL-like applications, which I am guessing is a common scenario. There is a mismatch here, in that FireMonkey is based on VGScene and DXScene from KSDev, and the focus of those libraries was rich 2D and 3D graphics. Some Delphi developers undoubtedly develop rich graphical applications, but a great many do not, and I would judge that if Embarcadero had been able to deliver something more like a cross-platform VCL that just worked, the average Delphi developer would have been happier.

The company must be aware of this, and one reading of the journey from VSCene/DXScene to FireMonkey is that Embarcadero has been madly stuffing bits of VCL into the framework. Eventually, once the bugs are shaken out and missing features implemented, we may have something close to the ideal.

In the meantime, you can make a good case for Adobe Flash and Flex if what you really want is cross-platform 2D and 3D graphics; while VCL-style developers may be best off using the current FireMonkey more for trying out ideas and learning the new Framework than for real work, pending further improvements.

On the positive side, even though FireMonkey is a bit rough, Embarcadero has delivered a development environment for Windows and Mac that works. You can work in the familiar Delphi IDE and code around any problems. The Delphi community is not short of able developers who will share their workarounds.

I have some other questions about Delphi. Why are there so many editions, and who uses the middleware framework DataSnap, or other enterprisey features like UML modeling?

There appear to be five editions of Delphi XE2: Starter, Professional, Enterprise, Ultimate and Architect, where Architect has features missing in Ultimate – should the Ultimate be called the Penultimate? It breaks down like this:

  • Starter: low cost, restrictive license that is mainly non-commercial (you are allowed revenue up to $1000 per year). No 64-bit, no Mac or iOS. $199.00
  • Professional: The basic Delphi product. Missing a few features like UML diagramming, no DataSnap. Limited IntraWeb. $899.00.
  • Enterprise: For more than double the price, you get DataSnap and dbExpress server drivers. $1,999.00
  • Ultimate: Adds a developer edition of Embarcadero’s DBPowerStudio. $2999.00
  • Architect: Adds more UML modeling, and a developer edition of Embarcadero’s ER/Studio database modeling tool. $3499.00

The RAD Studio range is similar, but adds C++ Builder, PHP and .NET development. No Starter version. Prices from $1399.00 for Professional to $4299.00 for Architect. The non-Ultimate Ultimate is $3799.00.

All prices discounted by around 40% for upgraders.

The problem for Embarcadero is that Delphi is such a great and flexible tool that you can easily use it for database or multi-tier applications with just the Professional edition. See here, for example, for REST client and server suggestions. Third parties like devart do a good job of providing alternative data access components and dbExpress drivers. I would be interested to know, therefore, what proportion of Delphi developers buy into the official middleware options.

As an aside, I wondered about DataSnap licensing. I looked at the DataSnap page which says for licensing information look here – which is a MIDAS article from 2000, yes Embarcadero, that is 11 years ago. Which proves if nothing else what a ramshackle web site has evolved over the years.

Personally I would prefer to see Embarcadero focus on the Professional edition and improve humdrum things like FireMonkey documentation and bugs, and go easy on enterprise middleware which is a market that is well served elsewhere.

I have seen huge interest in Delphi as a productive, flexible, high-performance tool for Windows, Mac and mobile, but the momentum is endangered by quality issues.

.net, apple, cloud computing, google, internet, iphone, microsoft, mobile, professional, silverlight, software development, visual studio, web authoring

Appcelerator CEO on Titanium, Aptana and the future of mobile development

I met with Aptana CEO and co-founder Jeff Haynie at the Mobile World Congress in Barcelona last month.

Appcelerator’s main product is Titanium, an SDK which takes HTML and JavaScript source files and compiles them to native apps for several platforms, including Windows Mac and Linux on the desktop, and Google Android or Apple iOS for mobile. RIM Blackberry support is in preview. Appcelerator has recently acquired the Aptana IDE for HTML, JavaScript, CSS, Ruby on Rails, Python and Adobe AIR. The company has also partnered with Engine Yard for cloud-hosted Ruby on Rails applications to deliver web services to clients built with Titanium.

Haynie says that mobile is currently a three-horse race between Apple iOS, Google Android, and RIM Blackberry; but he expects further diversification. Microsoft Windows Phone is under consideration, and he says that cross-compiling to Silverlight would be possible for Titanium:

It’s a .NET SDK, we would have to build a translation into Silverlight. That’s how we do it for iOS, we translate code into Objective C. We don’t think it’s technically insurmountable.

I asked about the Appcelerator Freemium business model. Titanium is open source and you can download and use the SDK commercially for free. Haynie says it works well because companies can do a full evaluation and get to understand the value of the software fully before deciding whether to purchase. However he emphasised that larger companies, other than non-profits, are expected to take out a paid subscription.

This point could do with clarification. Indeed, the Appcelerator Plans and Pricing page shows Titanium Indie which is free but for companies of less then 25 employees, and other editions which are paid-for. But as far as I can tell there are no restrictions on the SDK. See the FAQ which says:

Can I use Titanium for a commercial application?

Yes. You can use Titanium in both a personal and commercial application regardless of what your license or price is.

What is your License?

The Titanium SDK is licensed under the Apache Public License (version 2).

I also took the opportunity to ask about Adobe AIR support in Aptana. It strikes me that this is under threat following the acquisition, since AIR competes with Titanium. Haynie was just a little evasive, but at the same time impressed me with his attitude:

Obviously we have a competitive platform from Adobe AIR. But we want developers to have the best choice, the best tools possible. So competitively we need to build the best product. If AIR is a better product and people want to use Aptana to build AIR apps, then fine. That means we need to continue to work to make a better runtime for the desktop.

Nevertheless, Haynie implied that AIR support will only continue if Adobe supports it; I am not sure what support means in this context but I think it includes a financial contribution:

We’re with Adobe on trying to figure out where we go from here … we have to spend a lot of money to support that, so we’re making sure that we’ve got Adobe’s support behind that.

I am not sure what Adobe gains from Aptana support, given that it has its own Eclipse-based IDE called Flash Builder, so I would not bet on there being significant updates to the current AIR 1.5 plug-in.

Finally, Haynie emphasised what to me are familiar themes in talking about the direction for Titanium and Aptana. Cross-platform visual design tools; designer and developer workflow; and integration in a single IDE of rich client and cloud back-end. This integration has long struck me as one of the best things about Microsoft’s Visual Studio, so it is interesting to see the theme reappear in a cross-platform context.

What I enjoyed about the interview is the way Haynie communicates the huge change and volatility that has arrived within the software development world, thanks to the impact of cloud and mobile. Times of change mean new opportunities and new products. Titanium has plenty of competition, but if Appcelerator is able to deliver a robust, cloud to device, cross-platform toolkit, then it will have a bright future.

I have posted a transcript of most of the interview.