When I first woke up today, the iOS world was abuzz, with many developers reporting that they had received a warning email from Apple, which is widely available on the web but I won’t post here. The app uses dynamic techniques that allow different features to appear after approval, so that updates can be implemented without approval, warning developers to do some checks on the code and remove such implementations.

In fact, this is a long history, complex, there is no uniform standards of business. We’ll start with a very old project (we’ll skip over the application of Hybrid and talk about Native dynamics).

# “Originator” Wax

I’m going to start with Wax, but you know objective-C is very dynamic. Such as:

  • The runtime constructs classes and methods

  • Implementation of run-time replacement methods


In fact, these two capabilities are so scary that they allow Cocoa projects to do a lot of dark magic-like things. In short, they allow Objective-C to be like a scripting language, where text is code and no compilation is required. Then came a project called Wax (currently being maintained by Alibaba), which advertised Lua as a way to write native iOS apps. No one would do that, of course, because it would be too painful to write. But since iOS app approval is more painful than writing Wax, Wax is the best choice for HotFix.

The way this project works is to dynamically generate objective-C methods by loading Lua scripts, which are usually used to replace the faulty one. Lua scripts can be delivered dynamically, so the mission of fixing bugs on the line is realized.

Of course, Wax is extremely painful to use, especially with Objective-C conversions.

# JSPatch coming from behind

In iOS 7, Apple launched JavaScriptCore, which is a very interesting framework. It is a bridge between JS and native interaction, allowing you to navigate freely between native and JS. Most of the dynamic technologies on iOS platform are based on this.

Soon after JSCore was launched, an even better project was born: JSPatch, written by Bang. This project definitely crushed Wax in many ways, and JS is much better known than Lua, so it quickly replaced Wax as the mainstream hot fix choice.

JSPatch’s access costs are very low, the impact on the project is minimal, there is no need to introduce additional script interpreters (because JSCore already exists), and JS is really much more fun to write than Lua.

# React Native and Weex

As time goes on, various projects like React Native and Weex start to pop up. Their main idea is not to do hot fixes for the project, but to have a bigger idea: to use scripts to write the main features of the App.

In technologies like RN and Weex, JavaScript is a DSL that implements native code, which parses the JS and does the interface rendering, either through bundles or through js files that are delivered.

I have never played RN personally, but I have used Weex for a while because I worked at Alibaba, and my personal feeling is that the technical drive is driven by the high demand for dynamic operations.

# PY trading applets

There were no major innovations in technology, but something bolder came along: he told Apple directly: ‘We’re going to load other programs on wechat, and we’re going to call them miniprograms.’ Since the launch of miniprogram, Tencent and Apple have been fine. I guess there has been some PY trading. In fact, in some ways miniprogram is directly against the existing terms of the App Store, but wechat is fine anyway.

# Teaser DynamicCocoa and OCScript

This is actually not too much to say, after all, everyone’s appetite has been almost hanging, and at this rate should continue to hang.

In short, these two more radical solutions hope to eliminate the JS -> ObjC step, write ObjC directly, and then convert to their own kind of intermediate code without introducing new learning costs.

PS: For a repo that has 1K stars without a line of code, DynamicCocoa is fine.

What’s the incentive to be dynamic

Technologies are born for a variety of reasons, and when we talk about dynamics, here are some of the motivations:

  • Dynamic fix online bugs

  • Evade auditing and call private methods

  • Cross-platform development

  • Development cycles are too short and operational requirements vary too much


A lot of history has shown that cross-platform development (outside of games) is basically crap, that apps that do it purely don’t have any special advantages, and that evading censorship and calling private methods is a minority activity. So fixing bugs and responding to changing requirements is the main reason for many teams to study these technologies.

In fact, it is a strange phenomenon that there are sharp contrasts at home and abroad:

  • Domestic apps are keen to make hotfixes

  • Foreign apps are keen on Code Review


The domestic team is always in a hurry, always want what needs immediately, some even product managers to verify their ideas at will, completely disrespect the objective law of software research and development. Review of the App Store takes time, so I started thinking about getting around this process.

However, many foreign projects (such as Outlook Mobile, which I am involved in now) do not have any dynamic technology at all, but the Code Review is very strict and the development cycle is quite long, so we hope to prevent the problems in the cradle.

# Serious

As a matter of fact, I was shocked when this matter came out today. Like all things Apple tells you, the serious thing about this matter lies in its “ambiguity”. No one knows exactly what Apple is against. In fact, just like the Chinese film review, no standard is the most difficult standard, and sometimes it will be very lucky.

Apple clearly states in the review terms that it cannot load dynamic delivery scripts and change the intent of the app itself. But this definition is actually very, very vague, and I don’t think it’s a definition that can be implemented explicitly.

  • What is a script? What is a program?
  • To what extent does it change the intent of the application itself?

  • Game loading scripts is a common practice in the industry. Will Apple prohibit it?

  • Why is it ok to load JS inside a WebView?

  • Is it the right classification to distinguish between dynamic loaders by Web and Native?

  • Micro channel applets exactly what kind of PY transactions? (run


In any case, it was apple in every way.

Just like you can’t carry more than 100ml of water on a plane, the root cause is that security can’t cheaply determine whether it’s flammable or explosive, so Apple sends out such “shock and awe” emails very widely.

Does it work?

Because of objective-C’s hyperbolic dynamic nature, we’ve known for a long time that Apple is technically difficult to completely prevent this from happening.

To say the least, there is no need to use any dynamic technology or proprietary API at all to make the application look completely different from the user during the approval process, which is a trick I think we all know. I think what Apple really hates is this kind of cheating, so he’s trying to keep this “change” under his control as much as possible.

After all, if an App is just a shell, dynamic technology can load any content, and App approval is meaningless, which is something Apple, as a controlling company, really hates.

# Follow-up development

At present, Apple mainly targets hot repair frameworks such as JSPatch and Rollout, which can execute arbitrary Native Code after being delivered. However, React Native and Weex, which are mainly features, are not targeted.

I’m personally looking forward to this, as JavaScriptCore is a very useful framework and I don’t want it to die. It’s even interesting to see that a lot of Apple Music is implemented in JS.

I hope Apple can find a balance after the competition, reduce the bugs of their SDK, speed up the response of the audit, and be more open.

What we should be doing is ensuring quality before we go live and praying for qualified product managers. (run

– EOF –