The "Markdown / HTML reader for mobile" I teased earlier is finished, and it's called Jilan.
It solves a small but increasingly annoying problem:
When someone sends you an AI report, a web-based PPT, or a Markdown document via WeChat, the Files app, or a group chat, opening it on your phone usually results in a blank screen, raw source code, broken styles, or total confusion about which app to use.
Files like .md, .markdown, .html, .htm, .txt, and even packaged web ZIPs can now be opened directly on iPhone and iPad using Jilan.
Local rendering, local storage—no uploads required, and no need to register an account.
There is a TestFlight link at the end; you can apply directly if you want to try it. I've opened 8,000 slots.
But I didn't make Jilan just because we lacked a reader.
The more direct reason is that I've been feeling more and more clearly lately that as AI participates in content production, the formats we use to exchange content are changing.
A lot of text content is starting to land in Markdown, and a lot of presentation content is landing in HTML.
Jilan is just a small tool that fell out when this change reached the mobile side.
Markdown is not just a text format; it is becoming the data layer for AI
A few days ago, I saw a quote from the author of Obsidian that I think is very accurate: .md is becoming a Schelling point in AI file interaction.
A Schelling point is a choice people naturally gravitate toward without any forced regulation.
Markdown is a bit like that now.
No one mandated that AI should use Markdown, and no standards committee came out to announce anything.
But in real-world use, whether it's humans writing to AI or AI writing for humans, it often ends up as a .md file.
The reason is simple.
It's plain text, so it's lightweight for models to read and write.
It has enough structure to express headings, lists, tables, code blocks, and links.
And it doesn't get wrapped in a complex format like .docx.
Humans can open it directly, AI can process it directly, and version management and diffs are clean.
But I think more importantly, Markdown can no longer be understood only as "text in an editor."
It's more like the underlying data in an AI workflow.
That's how I use it in CodePilot.
It doesn't have a particularly complex memory mechanism; many memories are actually just a set of Markdown files.
AI writes to them, AI reads from them, and I can open and edit them myself.
Furthermore, widgets in CodePilot can use these local Markdown files and memories as data sources.
When the file changes, the component display changes with it.
At this point, Markdown is no longer just "an article to be read."
It becomes a very light local data layer: humans can see it, AI can read it, and tools can generate new interfaces and interactions based on it.
This is also why I feel that the direction many people are taking by continuing to grind out Markdown editors might be a bit narrow.
The truly interesting thing isn't making a prettier edit box, but treating Markdown as data to build new ways of reading, managing, and human-computer interaction.
HTML is becoming the display layer for AI content
On the other end is HTML. This trend has also become increasingly obvious lately.
Last month, I open-sourced a PPT Skill that generates presentations in web format.
It hit 10,000 stars in 25 days, and later, in offline defenses, exhibitions, and sharing sessions, I repeatedly saw people using PPTs made with it.
This confirmed one thing for me:
In many scenarios, what people want isn't a standard .pptx file, but a presentation that can be presented, understood, and shared quickly.
Coincidentally, the Claude Code team has been talking about the same thing recently.
They have an article specifically about why more and more output is starting to use HTML instead of Markdown.
The reason is direct: HTML has higher information density, is easier for visual hierarchy, is better for displaying charts, layouts, and interactions, and is easier for others to open and read.
This is very close to my own experience.
Markdown is good for consolidating content, but it becomes hard to read when it gets long. A report of thousands or tens of thousands of words piled into a .md file is hard for a human to actually digest, even if the structure is correct.
HTML is the opposite. It can use layout, space, color, charts, and interaction to organize information into something that feels more like "something to be consumed." It's not better for storing facts, but it's better for helping people understand facts.
So I'm increasingly inclined to look at these two things separately:
Markdown is the data layer, HTML is the display layer.
Keep the underlying content in Markdown—clean, readable, and version-controllable.
When it needs to be shown to people, presented, or shared externally, render it into HTML.
This isn't some grand new standard; it's more like a division of labor that has naturally grown out of AI workflows.
But this chain is broken on mobile
The content is there, the files are sent, but the problem occurs at the last step: people often open them on their phones.
Desktop is fine. You have browsers, editors, and if all else fails, VS Code.
But mobile is different.
Especially when you receive an AI-generated report, a web PPT, or a Markdown document in WeChat, the common experience is that it won't open, shows source code, has broken styles, or requires jumping between several apps. It's a small thing, but very annoying.
An IM like WeChat is essentially not a file reader.
Its priority is chatting, previewing, and forwarding, not seriously opening a Markdown or HTML file.
Browsers aren't designed for this scenario either.
By default, browsers handle "you give me a link, I'll open the webpage for you."
But what others send you is often a local file, not a link. You can certainly jump through hoops to throw the HTML to a browser, but the whole chain is long and awkward.
Many Markdown tools are also geared toward editing and note-taking, and aren't necessarily suitable for temporarily opening a file sent by someone else.
Not to mention that some tools require you to import, sync, build a library, or register an account.
HTML has an extra layer of security issues: a strange file might contain scripts, and you don't necessarily want them to execute by default.
So I've always felt that a very simple thing was missing:
A way to safely and conveniently open these common AI workflow files on a phone.
That is Jilan.
Jilan is very focused: Open, Read, Keep
Jilan was not made into an editor, nor was it connected to AI. By the way, I must praise the App icon drawn by CodeX; it's so cute.
I was very clear from the beginning that it only does three things: Open, Read, Keep.
When you receive a file, select Jilan from WeChat, the Files app, or the system share sheet to open it. It supports .md, .markdown, .html, .htm, .txt, and .zip files packaged from web resources.
All files are processed locally—no uploads, no account registration.
When reading Markdown, I mainly tuned it for long-form reading.
Font size, line spacing, and background can be changed; long tables can be scrolled horizontally; documents with heading structures can use a table of contents to jump.
Common Obsidian syntax, such as task lists, Callouts, footnotes, Frontmatter, and tags, are also compatible as much as possible.
It also supports switching between dark mode and color themes.
When reading HTML, I care more about "control."
It uses the system WebView for local rendering, supports zooming, switching between portrait and landscape, and switching between mobile and desktop modes.
Dynamic scripts are turned off by default. You usually don't know if there are scripts in a strange HTML file.
So Jilan doesn't assume script execution by default; if you encounter a page that really needs JS to be viewed, you can turn it on manually.
ZIP support is also made for real-world scenarios.
Many web pages exported by AI are not a single HTML file, but an index.html plus an assets folder.
Jilan will automatically find the entry point after decompression, and local images and CSS can load normally, so styles aren't lost and images aren't broken.
Files you've opened will automatically stay in your local history. If you want to look back next time, you can find them in the app.
Importing the same file multiple times won't create duplicates, and important ones can be favorited.
This is its current boundary.
It doesn't do cloud sync, accounts, editing, or AI integration.
Not because these features aren't important, but because a viewer should first do the job of "opening and finishing reading" cleanly.
Jilan follows the first two things
Looking back now, Jilan is not an isolated little tool.
Last month I made PPT Skill because I believe HTML will become a very natural form for AI to generate presentation content.
It won't necessarily replace PowerPoint, but for "quickly generating something that can be presented," HTML is light enough, open enough, and suitable enough for models to generate directly.
I made CodePilot because I believe Markdown will become a very natural data and memory carrier in AI collaboration.
It's not the prettiest format, but it's the easiest for humans, models, and tools to use simultaneously.
Jilan handles the third step:
These formats can't just stop at being "generated"; people must be able to actually open, read, and keep them.
The first two are about production; Jilan is about consumption.
AI can already generate Markdown and HTML.
But if these files break as soon as they reach a phone, then no matter how smooth the generation experience was, it hasn't truly reached the person's hands.
Jilan fills that last mile.
But this is far from over
Jilan currently only fills the shallowest layer: receiving a file and opening it.
Going forward, there are still several problems to solve.
For example, management.
A lot of people already have a large number of Markdown and HTML files scattered across their phones, cloud drives, chat records, and various app caches.
They aren't without value; they're just too scattered to find or manage.
For example, sharing.
Jilan solves "how do I view what others send me."
But conversely, "I made an HTML file, how do I let others open it conveniently" is still a hassle.
If you send the file, the other person might not be able to open it; if you send a link, you have to find a place to deploy it yourself.
For example, cross-device.
Reading halfway on a phone and continuing on a computer, or generating a report on a computer and pushing it to a phone to read, are all very natural.
But as soon as you do sync, you run into accounts, the cloud, privacy, and complexity.
Jilan is still very small—so small that I don't really want to package it as a big product.
But it fits right into the gap I encounter every day:
AI has generated the content, but I just want to take a good look at it on my phone.
If you're also frequently bothered by Markdown, HTML, and web PPT files, give it a try.
TestFlight:
I'd also love to hear your thoughts on this: after AI's involvement, what will documents, presentations, and reading actually become?
