Why DingTalk Mini‑Program Development Feels Like a Nightmare (and How to Survive)

Preface

How many developers know that DingTalk also has mini‑programs? How many have actually built them, and how many have built more than 50 pages? After a strict selection, only a few remain; our team is one of them.

Two years ago we decided to go all‑in on DingTalk mini‑programs because of H5 experience issues and the need for rapid iteration. All user and organization data are bound to DingTalk, so the mini‑program became the primary delivery method. Currently six TOB applications run as DingTalk mini‑programs with over 500 pages, plus H5 apps inside the DingTalk container, and a suite of supporting libraries (form engine, component library, request, OSS, F2, debug tools).

However, during these two years we constantly hit the low ceiling of DingTalk mini‑program capabilities. Minor business demands quickly expose limitations, leaving a bad impression on product owners. We have been providing weekly feedback to the DingTalk team, but most problems still require us to devise our own solutions.

Criticism

Ready, let’s start venting.

Weird Numeric Keyboard

The iOS version of DingTalk mini‑programs fails to pop up the numeric keyboard for input elements of type number. Mobile browsers normally trigger the appropriate keyboard based on the type attribute, as shown in the screenshot below.

DingTalk’s configuration for input is essentially a placeholder; it does not actually enable the numeric keyboard.

We asked the DingTalk community and received a baffling reply. The official support later confirmed that the iOS WebKit has a bug that DingTalk cannot fix.

We compared with WeChat, which works fine on the same device.

Douyin mini‑programs also display the numeric keyboard correctly.

Alipay’s mini‑program can pop up the numeric keyboard, confirming that the issue is specific to DingTalk’s iOS WebView.

The DingTalk team finally replied that we could implement our own numeric keyboard, which is unsatisfactory.

Mini‑Program Development Tool 2.0 – KPI IDE?

We tried DingTalk’s dedicated IDE, but the dd.getAuthCode API always fails, preventing us from obtaining the authorization token needed for any further API calls.

The official response was to stop using the DingTalk IDE and continue with the Alipay IDE, which defeats the purpose of a DingTalk‑specific tool.

Beware of regeneratorRuntime

During a local build we encountered the error “ regeneratorRuntime_default is not function ”. The issue only appeared in the local environment, not on CI.

After reproducing the problem, we discovered that DingTalk injects its own regeneratorRuntime during compilation, which collides with the one generated by Taro.

// partial code for illustration
...
regeneratorRuntime = webpack_required(20)

regeneratorRuntime_default = wepack_required.n(regeneratorRuntime)
...

This hidden substitution caused the page to break.

Uploading Videos Longer Than One Minute

Our business requires uploading multi‑minute operation videos, but DingTalk mini‑programs do not support chunked uploads, leading to memory‑related crashes on low‑end devices.

chooseVideo – increase recording duration

chooseVideo – lower resolution to extend duration

Chunked upload

Record → compress on device → upload via DingTalk

Handle upload outside the DingTalk mini‑program

Options 1 and 2 are rejected; the other three are not supported by DingTalk.

Version Upgrade Never Works

Version updates are unreliable. Even after clearing caches, the mini‑program may stay on an old version for over an hour. The only workaround we found is to uninstall and reinstall DingTalk.

DingTalk’s official upgrade strategy includes four policies based on offline‑package checks, but in practice they are not trustworthy.

Policy 1 – download on first open if no offline package

Policy 2 – download if more than 48 hours since last check

Policy 3 – async download if opened between 10 minutes and 48 hours

Policy 4 – no download if opened within 10 minutes

Cannot Detect Cold Start

DingTalk lacks a launch page, making it impossible to detect a cold start, which is the only reliable trigger for downloading a new offline package.

We compared with WeChat, which provides clear destruction rules that allow developers to force a cold start.

Header Click‑Through Issue

On iOS, custom header left‑side elements do not respond to click events, effectively blocking interaction.

The official reply promised a fix in the August release.

Loading Spinner Mystery

Users reported a persistent loading spinner that never disappears. Investigation showed that the spinner originates from DingTalk’s container, not from our code.

maxLength Not Working

On iOS, textarea with maxlength fails when the user inserts line breaks and spaces, allowing unlimited input. The official answer: iOS system bug, no fix.

No Gray‑Scale Release Control

DingTalk does not provide gray‑scale (canary) release capabilities. We resort to either code‑level gating or creating separate mini‑programs for staged rollout.

Long List Performance Issues

Rendering long lists (e.g., a year‑long calendar) on low‑end Android devices becomes sluggish, especially with animations, whereas the same code runs smoothly in WeChat.

Our workaround is to implement lazy loading.

page‑meta Not Supported

The native page-meta component, which allows dynamic modification of page root data, is not supported in DingTalk, while Alipay already implements it.

Positive Points

WebView Communication

DingTalk provides an open postMessage API for WebView communication, allowing H5 apps inside the mini‑program to call native APIs without the restrictions present in WeChat.

Login authorization sync

Data cache sync

Common DD API mapping

Unified media upload

Redirect H5 landing pages to the mini‑program

These features have helped us migrate about 80 % of our business to the mini‑program.

Mini‑Program Version Management

Initially the DingTalk CLI only supported upload and preview; publishing required manual steps in the backend. We automated the whole CI/CD pipeline, adding commands for preview release, official release, and rollback, which are now fully integrated with GitLab.

CI/CD integration with DingTalk backend

Only one release pipeline at a time

Automatic publishing after test verification

One‑click rollback of both version and code

These improvements have streamlined our release workflow dramatically.

Conclusion

Our team of over 30 developers interacts with DingTalk daily. Despite many bugs, DingTalk’s platform enables us to deliver complex B‑side applications. We hope the open platform will continue to improve developer experience, provide better official support, and perhaps create a community group for DingTalk mini‑program developers.