LaTeX Workflow on iPad | Hacker News Reader

LaTeX Workflow on iPad

supertachyon.wordpress.com

151 pointstaxyovio90 comments

I was an early adopter, I got an iPad back in the summer of 2010 and have used various models ever since. I've read quite a few of these "replacing a laptop with an iPad" articles and pretty much all of them involve a lot of bending over backwards to make it all work.

I've tried it a few times and it's not just worth it (to me). What I do instead is that I embrace the platform for what it is and don't do any of this remote machine kung fu to mimick a real computer. What I do instead is that I setup applications that sync data through the cloud, so that I can do draft work on my iPad (mostly text, some very light programming), but I never worry about runtimes, compilation etc. Ever since I stopped worrying and just used one of the many text apps (I mostly use iA or Google Keep), I've been much happier - I can focus on text, not on complex workflows.

Some years ago I read an article through HN by someone who did their programming on an ipad through SSH (and bluetooth mac keyboard) and ditched the laptop. Pictures of croissants in the sun outside in Munich. Got me very inspired. But in the end I decided on a stationary box at work/home, and a MB Air for when not at the desk (or on the sofa). Works great and doesn't weigh much anyway. The main problem with the tablet was that were always things I was missing that I hadn't thought about when moving to iPad. Maybe it'd be better with another brand, but I'm not bothering now.

I read the same article and felt the same way. But, like you, I couldn't get past the "why should I bother doing this when what I do works pretty well and I can autobackup a paranoid extra backup to usb?

Is this the article?

https://yieldthought.com/post/12239282034/swapped-my-macbook...

I remember when it came out and a few coworkers at the time had seriously considered swapping to an iPad because of it, but ended up getting MacBook Airs instead.

It’s surprising how 7 years has gone by and using an iPad for development is still facing the same problems.

>using an iPad for development is still facing the same problems.

I don't know if the App Store customizes what it shows people based on the apps they have installed, but for the past few weeks they've been showing me "Get starting with programming" apps and stories on the App Store and it's always the same "Scratch for kids" or "Swift playgrounds" or Udemy videos or something. Apple seems to be pushing programming on an iPad quite hard, but they're not doing anything to make it any easier or more productive. It's weird.

I read that series of articles every now and again because it sells a wonderful dream. The idea of being a highly mobile outdoorsman hacking code across the city is appealing. I also love the single-minded workflow of iOS, only one application is vying for your attention at a single moment. Anything else just pops in to let you know and then pops out. And working on a remote server is awesome, since the hardware doesn't matter anymore. I can bring whatever terminal I need, so I'm not tethered to my desk anymore.

Unfortunately most of my programming is web apps, so while it works for his C++ with long compile times, it doesn't work the same for me.

The one thing I did take from it long term is moving my dev server to the cloud, AWS Cloud9 specifically. I often find myself working on two or three website codebases plus two phone apps, and my personal laptop just doesn't have the RAM or disk space to hold all of that. So I use Cloud9 for the web apps and keep the phone apps on my local machine and it works out pretty well.

To be honest if Cloud9 worked on an iPad I'd probably leave my laptop closed more often.

What are the benefits of this limited, paying cloud system over just RDP to your workstation?

As I mentioned in my original post:

>my personal laptop just doesn't have the RAM or disk space to hold all of that

TeX Writer developer here. Very flattered to be included in the author's workflow. Sitting at the core of this process is WorkingCopy, which has the most sensible integration with Files app that it simply keeps all files local. After one or two emails with its developer, we managed to get the coordination working rather quickly. The intersection of LaTeX & git & ipad users are very small, but it is a joy to see that apps can work well together with just a little bit of effort.

For iPad to function as a real computer, I think what we need most is a shared file system that can be accessed by all apps alike, with some sort of access control.

btw: Never expected that someone would dump the TeXLive tree into texmf-local. Nevertheless, glad that it works.

Since iOS 13 ships with "full" Safari, how realistic is it to just use Overleaf / ShareLaTeX for typesetting on the iPad?

If you don't need offline solution, I think you can use them even without iOS13.

I'm on a 9'7 right now and use Working Copy and Kodek to write and Overleaf to "test" the LaTeX code and see if it will produce the .pdf I need. For full time use it might be a bit harder, but it's not impossible.

This is great to see, but also really frustrating. I see Apple pushing to make iPadOS feel more 'real computer', but these sorts of basic Unixy workflows still feel very hacky, particularly when it comes time to save things to the 'File system', as it were. I look forward to a day when I can someday actually use things like XeLaTeX and Pandoc on an iPad to accomplish my actual work, but for now, I'm finding myself editing Markdown and TeX now, and compiling later. Not great, but good enough.

I've often wondered whether Apple could do well by doing something similar to Crostini on ChromeOS, to allow these things to actually work as intended, but without impacting security. But that also probably doesn't sell software as effectively, as free software doesn't pay Apple's cut.

Apple doesn’t care about minuscule lost revenue because some people would want to run containers of free software. Drop in the bucket.

The number of iPads bought by those users might be just a drop in the bucket, but that is too shortsighted to look at those users. Those users are the ones who might push development of more advanced apps on the iPad, be it as developers themselves or because they would attract new app development to the iPad. Engineers and scientists might be a small market, but I think it was vital for OS X, that early on Apple laptops started to appear at conferences, slowly growing in share.

I said the lost revenue if the feature were offered wasn’t important. I didn’t say anything about the value of the users.

But you cannot reasonably look at the one without considering the other.

Clearly I’m not explaining myself well.

The point I objected to comes at the end of this quote:

> I've often wondered whether Apple could do well by doing something similar to Crostini on ChromeOS, to allow these things to actually work as intended, but without impacting security. But that also probably doesn't sell software as effectively, as free software doesn't pay Apple's cut.

The implication is that Apple wouldn’t develop such a feature because it might cut into their profits. I don’t buy that reasoning: Apple wouldn’t lose much if any money by offering that.

Update: and I also don’t believe that Apple would deprioritize it because would cost them some money. Far more likely they’d decide it isn’t sufficiently useful, or would cause other problems, be too confusing, etc.

If those users are so unimportant, why did Apple bother to introduce the Hypervisor framework on macOS? If there's a big, important market for virtualisation on macOS, surely it would be worthwhile to also address that market on iPadOS? Especially since Apple is trying hard to convince all kinds of professional users to adopt the iPad.

I think Apple has a different vision for needs of people who use Macs and iPads for work.

For example the new Sidecar feature (use iPad as a screen) supports the pencil but not touch. Apple believes that touch on macOS interface is not a good experience. I suppose that they feel that text entry and chaining CLI tools on iPad is not one either.

Apple has been trying to pull people away from writing kernel extensions for a while, so I don't see why the introduction of Hypervisor.framework (and with it, another user-space way to do something which previously required working in the kernel) is noteworthy as anything other than this.

I said the lost revenue if the feature were offered wasn’t important. I didn’t say anything about the value of the users.

The file manager improves but not by a lot.

I think iPadOS is only usable as an actual computer when they finally make the Terminal app on iPad and a much better File app

in the meantime you can take matters into your own hands and jailbreak if possible

But why not use some of those fancy tablet devices that aren't locked in the first place? Much more options here. Sure, Apple hardware is good, but there are alternatives. Not suggesting to switch to chrome OS or android here.

So all Macs up to OS X weren't usable it seems.

While I never used a Mac before OS X, they probably were quite usable, and your question was both rethorical and snarky. There is more than one way to use a "computer". Incidentally, I only switched to the Mac after they added a shell to it with the switch to OS X. And one of the reasons I disliked Windows was the crummy shell and lack of a terminal. Also, it is 2019 and it is no problem to get a full Linux installation on a smartphone, while Apple sets up artificial limitations to prevent that.

There are certainly other ways to make the iPad a computing device - like the Macs before OS X, but Apple steps into the way of that in many places too. An app like Termux would not only make a lot of potential users happy, it would be something which could provide this in a way which could be nicely sandboxed in the iPadOS/iOS.

Naturally it was snarky, because having a CLI to be an usable computer is not something that one can generalize and largely proven in the market that consumers don't give a damn about it.

Which phone is sold with a full Linux distribution, with any kind of market relevance?

Android certainly not, as regular Linux APIs aren't part of the NDK stable API list, which Termux actually needs to work within the constraints of ISO C, ISO C++ and NDK APIs.

I still don't understand why you felt it necessary to make a snarky comment. Yes, there are tons of users who never use command lines on their computers. I guess no small amount of the Mac users don't know what "Terminal" is for. But do I really on hacker news have to argue what the value of a command line for an advanced user is, especially the hacker news audience?

Maybe because REPLs are more powerful that an plain old command line, and specially the HN news audience should be aware of it, given that it is built on top of a Lisp variant?

Being a developer is not a synonym for being stuck with a PDP-11 concept of how a computer is supposed to be used.

The commenter you answered on was talking about a terminal app for the iPad in general, how do you get to repls from that? And if you want to talk about repls, why don't you do that in your original comment? You should look at the Hacker News guidelines, which in the very first item cover your post specifically.

And you don't need to teach me about repls, I am a full time Lisp programmer :).

Because something like Swift Playgrounds, but in the context of iPad automation is from my point of view the ultimate goal, lets call it the Dynabook Smalltalk transcript, not just replicating a green phosphor VT-100.

I am not saying that something like that wouldn't even better.

What defined a usable computer in 1999 is very different to what defines a usable computer in 2019.

Having a CLI isn't surely part of it for 99% of the consumers, neither in 1999 nor in 2019.

I always think this is such an odd sentiment. That 1% builds 100% of the software for the other 99%. Doesn't that make them disproportionately more important?

No, because many developers are part of that 99%.

Being a developer is not a synonym to be enamored with an UNIX CLI.

In fact, a graphical REPL is much more powerful.

So no, that 1% does not target the other 99%.

Liking using something is a bit different than having to use something. Are you saying you don't think the majority of developers need to use the command line for things like git, npm/general dependency management, running local web servers, compiling apps, continuous integration, etc...?

Yes, that is a tiny portion of what being a developer is all about.

Not everyone is writing UNIX daemons, stuck in UNIX workflows.

As I said, a graphical REPL for scripting languages is much more powerful.

If you're talking about web developers, then the majority literally are writing Unix daemons[1]

[1]: https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...

Again, I'm not talking about what's more powerful, and I'm not saying that everyone works this way, but I am suggesting the majority of developers do need the command line to do their job.

Unfortunately, I'm not aware of any usage statistics for the command line in isolation. But if you look at the most popular technologies, e.g., Node[2], then you can most likely extrapolate that the majority of developers are working with the command line.

[2]: https://insights.stackoverflow.com/survey/2019#technology-_-...

Since we are speaking about Apple ecosystem here, most devs live in XCode.

Just like we used to live on MPW and Metrowerks before.

Scripting is perfectly doable from macros and IDE callable scripts.

CocoaPods, Carthage, Fastlane, git, all require the command line, and most teams use some combination of those. Not to mention Xcode literally is just a wrapper around Unix processes like `xcodebuild` and `SourceKitService`. Then there's a whole host of other support command-line utilities for doing Cocoa development like `codesign`, `xcrun`, and `xcode-select` off the top of my head.

Again, I wasn't making argument about where developers spend most of their time. Just that they need the command line as part of their workflow.

How many processes an IDE uses is an implementation detail.

The large majority of Apple and Microsoft developer communities live on their IDEs as part of our workflow.

Scripting and automatization can be easily done from the IDE as well, thanks to macros, REPL and build integration points.

Dropping down into a UNIX like CLI is the exception, not the norm for a large community.

Ah, but what about WSL? Well, Microsoft saw a market opportunity to win developers that buy Apple computers to do Linux work, instead of buying laptops from the likes of Dell/Asus/Tuxedo/system76 to start with.

So they are making UNIX devs comfortable on a foreign platform, just like NeXT was built on top of UNIX to take a piece of the pie from the UNIX workstation market being lead by Sun.

Using the shell was never a thing for NeXTSTEP nor classical Mac OS development workflow.

You seem to be saying that because developers spend 90% of their time in an editor or IDE and 10% of their time on the command line, that they don't need the command line? I think that's what you are saying with this "dropping down into a UNIX like CLI is the exception, not the norm for a large community"? Because I'm not aware of any "large community" of developers that don't use the command line at all? So the exception is when they actually have to use it? But using something a small percentage of the time of course doesn't mean it isn't important (humans spend a small percentage of time eating and if we don't we die).

Regarding Xcode being implemented by managing processes, my point is that IDE's and text editors have moved to a model of using external processes to implement features. E.g., language server protocol, linters. That iOS bans this type of application is why iOS for programming is a wasteland. The tragedy of that fact is my whole point in this thread.

We happen to live in different developer communities, it seems.

Yeah, but I'm not arguing whether developers exist who don't use the command line, of course they do. The question is simply whether the majority of programmers use the command line? I'm proposing that they do, unfortunately there's no available data for this point specifically, so we end up falling back to anecdote. But I am still super curious about your perspective on this. From what I've observed anecdotally, and from the most relevant data I've looked at, I'd guess the percentage of professional developers that rely on the command line is at least 80% (I am giving a lot of leeway for Microsoft-stack developers, which I'm not really familiar with, excluding developers using Microsoft technologies, I'd say well over 90% of professional developers rely on the command line). Do you disagree with these estimates? And if you don’t mind answering, where would you put the percent? (I'd also be super curious which technologies developers that don't use the command line are on.)

The thing you are missing that what UNIX devs rely on the command line for, is easily achievable by scripting, REPLs, and IDE integration.

For example I can do everything I need from Python or PowerShell from inside Visual Studio, just like Xerox PARC devs used to do with their REPLs on Lisp, Smalltalk and Mesa/Cedar workstations.

Naturally I am forced to drop down to old style command line every now and then, but that is forced upon me by tools I don't create, and most of the time they are ports from UNIX tooling.

Got it, yeah as long as we agree most programmers do use the command line. I actually agree that there are hypothetical ways a command line could almost always be replaced, but to me the important part is that most developers choose not to replace it. (And I’d argue that dependence on the command line is actually increasing overtime, with package management, version control, continuous integration, and modern editor features being implement on top of it.)

The question I pose then, is if these things are possible to do in other ways, and those other ways are better, why don't professional developers choose to use them? For example, why isn’t programming on an iPad popular? I.e., where these other methods are literally the only way to do programming on device? Using SSH to program entirely in a terminal is almost certainly more popular for professional developers than any other approach of programming on an iPad (using blog posts about how professional developers develop on an iPad as an indicator).

Because those blog posts are from UNIX devs trying to use iPads for UNIX like work.

This is how Apple devs actually do development on iPads.

- Swift Playgrounds

- Pythonista

- Continuous for C# and F#

- Lisping

- Raskell

- GLSL Studio

I’m only interested in whether the majority of professional developers are able to ship software to their users. Is your stance that you can do that just fine with just the tools you listed and therefore professional developers don’t need the command line on iOS?

I guess that I am not a professional developer, apparently.

Haha, not sure about that, but you most certainly aren't the "majority of professional developers". Neither am I, that's a whole bunch of people who couldn't care less about how you or I want to work.

Professional MacOS developers, before OS X was born, did not use a command line at all, so Photoshop was created by amateurs?

Same applies to developers on Amiga and AtariST, also less professional?

Or what about Windows developers, that hardly bothered with cmd.com, doing their scripting via VBScript/JSCript and everything else via Visual Studio, as it was common practice until PowerShell, with its PowerShell IDE sprung into existence, also a bunch of amateurs?

Don't judge professional developers on other platforms with UNIX glasses on.

This comment is hilarious. Apple switches from Classic Mac OS to OS X, the defining difference being that OS X has Unix underpinnings.

Apple then goes from almost going out of business to being one of richest companies in the world (sometimes the richest).

And this is supposed to be evidence that the command line isn't important?

Sure, as if Steve Jobs had nothing to do with it.

The original comment argues a different claim: a terminal is not required to be considered usable.

As for success, I'd say that what brought Apple back to making money was iTunes and iPods, followed by iPhones.

They could very well steal the WSL idea from Microsoft and make something similar. Currently there is iSH which runs certain Linux utilities unmodified, but I'd love to see first-party support.

A shell based on [WASI] would be a pretty cool option to provide

[WASI]: https://github.com/WebAssembly/WASI

It may be worth noting here that iOS 13 adds support for external USB sticks and network Samba shares to the Files app.

I love my iPad. Compared to windows at work it's way more reliable and polished. I've been shifting over my computer interaction to the iPad with good results and improvements in convenience, independence and efficiency. Migrating rss, mail, web browsing and content consummation has been successful. I too started using the calendar, to do list and notes app to great effect.

Only programming I wasn't able to change yet. An attempt was made with a ssh app, but it wasn't able to compete with a proper ide/text editor yet. For unix as an ide fans it would be enough though. I want to learn that, but sadly I still have to write native apps, though I'll change that when I have the chance.

The best thing about iPadOS is control. It feels so relaxing not having to worry about discord scanning all your processes and files just because you want to chat with your friends. I hope they'll never go back to allowing unsigned code.

We are obligated to use iPads for external colleagues and it is a catastrophe for productivity. There are some nice apps but everything is restricted. Well, our CRM and ERP system use Windows, but even without that the iPads remain a toy for meetings.

Chatting with friends is ok though. But the ergonomy is still crap.

> The best thing about iPadOS is control. It feels so relaxing not having to worry about discord scanning all your processes and files just because you want to chat with your friends. I hope they'll never go back to allowing unsigned code.

It felt like a loss of control when I learned recently that facebook uses a loophole to exchange data with Whatsapp... https://medium.com/@gzanon/no-end-to-end-encryption-does-not...

>It felt like a loss of control when I learned recently that facebook uses a loophole to exchange data with Whatsapp... https://medium.com/@gzanon/no-end-to-end-encryption-does-not....

That's not what the article is saying - the linked article says that there may be a way for Facebook to do this, but there is no proof that they are. That still leaves room to say that maybe there should be user controls against these app extensions, though.

> The best thing about iPadOS is control.

Are you serious? It is not about control. It is about only Apple can "control". You and your software cannot "control" anything.

I very much like the sandboxing of apps and the control I have over what they can access (e.g. location, contacts, photos). It also helps contain any security bugs in apps. But this seems orthogonal to allowing unsigned code. You could just as easily run an unsigned app in the same sandbox.

So personally, I'd like to keep that model - but I'd like to be able to load my own apps (within appropriate sandboxes).

To address some of the issues I've seen discussed here, I'd also like to see the ability to create a "volume" (a shared directory tree) and explicitly grant access to a volume to a subset of apps. (E.g. keep all of you document workflow in a volume and expose it to your TeX tools and git tools, but Uber/Facebook doesn't get to touch it.) I this is already addressed in OSX sandboxing - I believe you can grant access to a directory tree to a sandbox app via the open file dialog.

I don't see TeXPad mentioned anywhere. An iOS LaTeX environment, featured here a few years ago: https://www.texpad.com/blog/latex-ported-to-ipad

https://www.texpad.com/ios

Just adding to this: TeXPad is what I use on both my laptop (when working on a big screen, though I mostly use Vim when working from battery) and my iPad mini 5 (+ a little bluetooth keyboard) on flights and before meetings.

Honestly, using that + iCloud syncing (+ Git, on my laptop) has been great: all of the changes I do sync across all of my devices, as do the PDFs, which I can easily bring up in meetings, while also having the plus side of git (diffs, general VCS niceness) once I get back to my computer and commit the changes to the remote repo.

Of course, unlike the OP, I'm not aiming to completely replace my laptop... I'm trying instead to augment my workflow to not carry my laptop to meetings, while waiting for people, etc.

+1 on Texpad. It also integrates extremely well with File Providers. You can clone a repo of your TeX project on Working Copy, and then link the entire checkout folder in Texpad. Then, just edit and compile in Texpad, and switch back to Working Copy to commit and push the changes.

Actually Texpad is mentioned in the article briefly.

But, unlike its MacOS version, on iOS it’s not as very good. For example, there is no multitasking support on iPad. The package managing relies on installing pre-defined “bundles”, which don’t tell what packages are included. On the Mac version of Texpad, we can choose between its own compiler or an external one like tex live. But on iOS, the former seems to be the only option.

Oh that's weird, I missed it when I searched for it.

Thanks for your feedback :)

My Stellar Astrophysics prof wrote his textbook in TeXPad back in it's early days. Between that, his iPad, and a bluetooth keyboard case, he wrote the entire book over the course of 2 years I think. Aside from some final polish, diagrams, and various references, all text was written on the go.

This is the book itself: https://www.springer.com/us/book/9781441999900#aboutBook

Good write up, thanks.

I wrote three books using LaTex, but I now use markdown with leanpub, otherwise I would immediately clone the author’s setup. I also find that an iPad Pro is great for writing wherever I happen to be. I recently gave my large iPad Pro to someone and bought the smaller one. My new iPad Pro is so small it is always ready at hand.

This is a tangent, but I just wanted to thank you for making that move away from LaTeX. As I explained elsewhere [1], PDF (the primary output format of LaTeX AFAIK) is not very accessible to blind people via screen readers. The structured formats that can be easily produced with full fidelity from Markdown (HTML, EPUB) are much better. I'm sure this isn't the reason why you made the switch, but it's a nice side benefit.

[1]: https://lobste.rs/s/dhjp6r/what_are_you_doing_this_weekend#c...

Or you can just get a ThinkPad X1 (a generation or two behind) for sub-$1k, install Linux on it, and work in comfort with almost the same weight and battery life. I'm really pleased with mine.

Well, I just use Overleaf to do my LaTeX work on my iPad.

Well. I’m glad that works for you.

It seems the author wanted a solution that would work offline as well.

Overleaf's fine, but lack of offline editing, and more crucially, trusting my main working copy to live only on somebody else's computer, is a bit of a non-starter for me.

Plus, call me an idealist, but it feels like a huge step back when a device requires a paid web service to do something that's completely free on a real computer. I don't know that "pay somebody else" should be hailed as the solution to "good software doesn't work on this device".

You made a good point about offline editing but Overleaf's main reason for existing is precisely TeX software not being so good.

The collaboration and sync tools are very useful, including performant editing by multiple authors at once.

Overleaf has excellent offline support through its git interface (or Dropbox, if you prefer).

The Overleaf website is a bit painful to use on an iPad. Hopefully, this will change with the "desktop-grade" Safari announced for iOS 13. Maybe someone already running the beta could test this?

I imagine it will be identical to Safari running on desktop. The Beta also gives you things like page scaling that you have on desktop so you can play with sizing if you like too.

I find Texpad to work great in principle, although I get frustrated by any text editor that is not vim. If you have the ability to sideload (that is, you have a developer account), there is a fork of iVim (https://github.com/holzschu/iVim) that supports running TeXLive locally on the iPad. I wrote up some notes on how to make this work some time ago: https://michaelgoerz.net/notes/editing-latex-on-the-ipad-wit...

When I don't need offline editing, another workflow I've used is to do the editing on my linux server: edit via Blink/tmux/vim on the left, and see the compilation result on the right via Screens/vncserver/evince (with auto-reloading).

I actually came across your setup when figuring out mine. Thanks for sharing!

I have another (albeit more expensive) workflow. I use texpad[0] on my Mac and iPad, with the files stored in Dropbox and iCloud. Works like a charm and almost no overhead setting up.

[0] https://www.texpad.com

This actually used to be my setup too. But Texpad on iOS is not very good (e.g. no multitasking support). Its Dropbox sync is not very reliable in my experience.

Then I moved to TeX Writer and Dropbox, which worked better. Then I wanted more (code completion, version control). So I ended up with the workflow mentioned in the article.

I just run myself a docker container with pandoc and a flask endpoint on heroku.[1] Doesn't work offline, but with an iPad with cellular service I basically am never offline, and I have a Siri shortcut set up to share documents from any app, or markdown from clipboard, straight to the endpoint. Full latex, markdown, conversion to word... and on free dyno time no less.

[1] https://github.com/paultopia/miniapi

I just use Overleaf, way simpler. Needs a keyboard with the iPad though. Almost a one button click setup.

I hate IOS. I don't understand why people try to turn a consumer device into a serious developer workstation.

Reply on news.ycombinator.com