Tor Lillqvist

LibreOffice was ported to run on macOS on Apple Silicon during summer and autumn of 2020. Most of it was very straightforward, just a recompilation. This talk will describe the details that required more effort.

After several years of only occasional progress but mostly stagnation, resources have now been available for work on a LibreOffice-based app for iOS. This talk will describe the history and technical aspects of the effort.

Collabora Office for iOS is based on the C++ server-side code for Collabora Online (based on LibreOffice Online), and JavaScript code for the same (browser-side). Plus the core of Collabora Office (i.e. LibreOffice). Plus, finally, a rather small amount of glue code in Objective-C++. In the app all this code runs on the device, there is no server involved.

Work on enabling compiling the LibreOffice core for iOS (cross-compiling, on a Mac, as all iOS development is done) was started originally back in 2011, by me. Initially this was mostly done in spare time, for fun.

There was initially no clear product plan and no technical exact plans how, once the core code works on iOS, it can and would be used in an actual app. No work on any user interface. But just making the functionality needed to even load and save documents on iOS, for instance, was challenging enough, given the somewhat obscure and complex internal plumbing of LibreOffice with its long history.

Some year later, for Collabora Online, the concept of “tiled rendering” was introduced by Michael Meeks. In this approach a client requests the core to render a document as “tiles”, rectangular pixmaps. The user interface in Online, in JavaScript, requests and displays these tiles and provides the user interface that send user input and edit request as necessary to the core.

Also in the same timeframe, the CloudOn company needed an iOS app with the ability to load and edit office documents natively on an iOS device. We started working on making the LibreOffice core useful for that, based on my earlier work, and using tiled rendering for this, too. One major challenge here turned out to be the massive size of the LibreOffice core code, which was problematic as Apple at that time restricted the size of the executable code in an iOS app quite severely. Anyway, various workarounds were found, and this was progressing nicely, but then CloudOn was acquired and lost interest. No public iOS app code was released from that.

As a test so see that the code works at least to some extent, I had written a minimal test app (without any actual editing UI), “TIledLibreOffice”, in the LibreOffice core code.

Then no iOS work happened until a few years later when Jan Iversen got interested. He was at the time working for TDF. He worked on an iOS app, LibreOfficeLight, which is still present in the LibreOffice core code. He also worked on keeping the iOS functionality working in LibreOffice. Jon Nermut also helped. The LibreOfficeLight app as such worked but did not contain any actual editing functionality.

Then half a year or so later, Michael started toying with the idea of re-using the by now quite substantial JavaScript UI we have in Online in an iOS app. And then a customer turned up that took part in funding it, Adfinis SyGroup.

I started working on that, and it turned out to be surprisingly straightforward to get it working. Sure, there were lots of technical issues involved. Some of the iOS code in LibreOffice had bit-rotted over the years. The Online server code normally runs as multiple separate processes on a Linux machine. That had to be combined into code running in just one process (the iOS app) which was challenging.

The JavaScript code in the iOS app is the same as that in Online. There are very few places where the JavaScript needs to know that it is running in an iOS app and not in a browser.

All the code is Open Source and publicly available, in the LibreOffice “core” and “online” git repositories.

During the Google Summer of Code in 2012, Gökçen Eraslan implemented digital signatures for LibreOffice's PDF export. There were some glitches left in the feature, for instance it did not really work well on Windows, which is where most of our users are. Because of that, the functionality was marked as "experimental" and was thus not easily available to users. Recently, thanks to a crowdfunding effort, we had the opportunity to improve this feature. The presentation will describe that work and show how to use the feature.

In this presentation, I will present a summary of the peculiarities of LibreOffice internals on iOS and Android, and tell about some recent advances like running as 64-bit ARM64 code on the newest iOS devices.

Note: I am intentionally using the term "LibreOffice code", not "LibreOffice".

Porting the LibreOffice codebase to iOS and Android was quite fun and many interesting issues had to be worked on. Some tasks were expected, like having to create new C++/UNO bridges for the two new platforms (not from scratch, but borrowing code from appropriate existing ones of course). Other issues were unexpected, like discovering the arbitrary and (relatively) low limit on the number of dynamic libraries loaded into a process on Android.

In general the restrictions placed on iOS apps that would require significant changes to some part of LibreOffice internals were well documented and known in advance, while restrictions in Android were undocumented, often presumably coincidental (or even simply bugs), and thus came as a surprise.

The porting efforts, and cross-compilation support in general, started back when we were still using a hybrid of old and new build mechanisms, which brought its own charms. But luckily dmake is dead now.