How does Offline Twitter work?
This page is somewhat technical. If you don’t care how the app works, you can skip this page. It’s just for people who are curious to know about the guts of it.
A lot of developers have historically complained that Twitter’s API is annoying to use and bad because it rate-limits you. So, Offline Twitter bypasses the official API, and instead scrapes from the same public API that the web UI uses. This has pros and cons.
Pros:
- it’s not subject to rate-limiting
- there’s no keys, credentials, or accounts required (you don’t even need a Twitter account)
- people can’t block you unless they make their entire account private
- you can’t get banned
Cons:
- every time Twitter changes their public API, the app breaks. This happens occasionally
- lately, Twitter is starting to restrict what you can see without logging in, which directly affects what this app can collect
The “engine” and the “GUI”
Offline Twitter is actually two different applications: the engine, which scrapes tweets from the Twitter API, and the GUI, which is… a GUI. The GUI is intended to look-and-feel visually similar to the Twitter web UI.
Strictly speaking, the GUI is optional. You can download all the tweet content you want by only using the engine. However, unless you’re a developer who wants to interact with those downloaded tweets programmatically, you probably want some graphical way to look at them. That’s what the GUI is for.
The GUI connects (shells out, actually) to the engine whenever you try to open something that you don’t have a saved copy of yet. If you don’t have the engine, the GUI will behave weirdly (and probably crash) if you navigate to content you haven’t downloaded.
The engine is written in Go; it’s a binary called twitter (lowercase). The GUI is written in C++ using Qt5, and is a binary called Twitter (uppercase). The names are different on Windows, but let’s be honest, is any Windows user reading the “technical” page?