A team making programming tutorials once ran the numbers for me.
Posting ten videos to Douyin, from picking assets to hitting publish, takes under half an hour. Publishing the same ten pieces to Bilibili takes forty minutes each.
I asked where the forty minutes went. Uploading and waiting, he said. Waiting for transcoding, waiting for review, and filling in category, tags, cover, and description along the way. Actual hands-on time was under five minutes. The other thirty-five were spent waiting.
That arithmetic says a lot. The hard part of batch publishing on Bilibili is not the operation. It is the waiting, and it decides where Apple Cluster Control is worth using.
1. Break the flow down first
To understand why batch publishing is hard here, count the steps one submission takes.
Uploading is step one, and it already forks. Short clips are tens of megabytes. Long-form video runs into hundreds of megabytes or several gigabytes. On the same connection, upload time can differ by two orders of magnitude.
Transcoding is step two. Bilibili converts the video into its own formats, outside your control, with duration depending on length and current queue.
Review is step three. Machine review takes minutes, but manual review can take hours to a day. This is the least predictable step and the most troublesome for batching.
Submission configuration is step four: category, tags, cover, description, and parts. Bilibili is stricter than short video platforms about categories and tags, and wrong choices hurt recommendation.
Only then comes publishing.
Of the four, the first two are bandwidth and time problems, the third is an uncertainty problem, and only the fourth is genuinely standardisable. That tells you where tooling belongs.
2. Multi-part is a variable that needs its own handling
Multi-part is a structure specific to Bilibili: one submission holds several video segments that viewers watch continuously on one page.
For tutorials, course series, and collections, it is a practical format. It also adds work to batch publishing.
What you manage is not one file but a parameter set: part order, each part title, which segment becomes the cover, and how the description reads. Filled by hand, a single submission can take several minutes.
There is a real trade-off. If your content suits multi-part naturally, such as a twenty-lesson course, the parameter set is worth templating. For an ordinary single-segment video, forcing it into parts adds complexity for nothing.
3. Asset distribution: Bilibili is not short video
Short clips are small, so cloud sync or bulk push from central control handles distribution easily.
Bilibili is not. Pushing a few hundred megabytes to several gigabytes across dozens of devices multiplies time and bandwidth quickly.
Two approaches work in practice.
Push in batches. Do not send everything at once. Prioritise devices and push five, then run, then push the next batch, which avoids saturating the network in one go.
Or let devices download. Host the video at an accessible address and have the script trigger downloads on each device. This spreads bandwidth across devices, at the cost of waiting on each one and handling failures individually.
Which to choose depends on file size against device count. Small files and few devices favour sync; large files and many devices favour download.
4. Review cannot be automated
Review is the most troublesome step because two things are outside your control.
Timing. You cannot know how long a submission will take, and you cannot hurry it.
Outcome. Rejection reasons are sometimes vague, whether copyright, category, or the content itself.
The consequence for process design is that you cannot manage batch work by publishing and verifying immediately.
A workable approach is asynchronous checking. Log the submission first, recording time, title, and ID. Then run a check periodically, comparing status changes and acting only on those that moved. Your time becomes predictable, and one submission stuck in review no longer blocks the queue.
5. How well multi-account works on Bilibili
I would be more cautious here than on short video platforms.
The Bilibili ecosystem rests on individual creator brands. Viewers follow the person, not the account. That inherently discounts the value of an account matrix. Ten interchangeable accounts can be worth less than one with a loyal audience.
Bilibili also judges reposted content and originality more strictly, so duplicate material across accounts is more likely to be identified and penalised more heavily.
If you proceed, split by content direction rather than piling up accounts. One for technical tutorials, one for product reviews, one for industry commentary. Clear positioning keeps audiences from confusing them and avoids being flagged as a matrix operation.
6. Where scripts fit
Stating the position clearly avoids mismatched expectations.
Suited to scripts: submission status checks to see what is in review, approved, or returned; data collection across plays, comments, and danmaku; batch preparation of assets and parameters such as titles, descriptions, and tags that can be templated.
Less suited: fully automated uploading. Large files, long durations, and uncertain review compound into a poor return, with expensive troubleshooting when something goes wrong. Manual upload with scripted logging is steadier.
Off limits entirely: bypassing review, reposting other people content, or faking originality. Those are rule questions rather than efficiency questions.
Tooling standardises what can be standardised. It cannot fold the whole pipeline into a script. On Bilibili, less is standardisable than on short video platforms, and that follows from the content format itself.
How to configure devices for multiple accounts
Bilibili warm-up cycles are long. An account takes weeks or months to carry normal weight, so the hardware needs to run reliably over time. Do not scrape this together from whatever machines are lying around.
On the Apple Cluster Control route, iPhones carry an immediate advantage: one model has identical resolution and system behaviour, so screen size parameters, coordinates, and wait times all carry over between devices without re-tuning. Android fragmentation is worse here, and mixing models visibly increases debugging work.
Match device count to the accounts you intend to run seriously. As noted earlier, the value of multiple Bilibili accounts is limited, so concentrating hardware on two or three beats spreading it across ten half-dead accounts.
Further reading
- Scheduling multi-account publishing and managing assets
- One-click synchronised publishing for Douyin matrix accounts
- Unified multi-platform matrix management
- Apple cluster control for Zhihu content distribution
关于 EasyClick: A phone automation AI-agent platform covering Android no-root, iOS no-jailbreak and HarmonyOS Next, offering script development, Apple cluster control, local central control & mirroring, and cloud control systems. → Explore all products
Ready to build it for real?
Every approach in this article can be built with EasyClick capabilities on iEasyClick — full documentation, developer tools and automation products, free to try.