1） 和原生IOS开发的技术一样，编译出.a动态库（下文称之为libtclib.a，蕴含简略的native_add函数）。

2） 确认flutter的dart插件产生的我的项目的IOS局部应用obj-c语言：

3） 应用xcode关上Runner.xcworkspace，在linkBinaryWithLibraries里把libtclib.a蕴含进来，还须要在LibarySearchPaths把libtclib.a的门路放进去。

4） main.dart里的内容：

内容和上一篇《flutter应用C代码库—Android篇》一样。

编译运行，会发现，编译失常通过，但运行时，报错了，报告找不到相应的native_add这个symbol。

我偶尔在AppDelegate.m文件中测试了对native_add的调用：

而后编译运行，意外发现整个APP运行失常了！

剖析起因：如果没有在AppDelegate.m里对native_add的调用，那么xcode的编译器（留神是编译obj-c的，不是flutter的编译器）会认为native_add没有用，从而不链接进可执行文件中（我还没有弄明确xcode的编译器是基于单个函数、还是分段、还是基于动态库文件来决定链接的。比方，同一个动态库有两个函数A和B，如果A在AppDelegate.m被调用，B没有，那么xcode链接时，是只链接A还是整个动态库都链接进去？），这是因为xcode的编译器是不晓得在main.dart调用了native_add的。等到main.dart去lookup这个native_add函数symbol的时候，天然就找不到了。

所以，为了保险起见，在flutter中须要间接用到的函数（间接用到的函数没关系，xcode会主动剖析而后链接进来），在AppDelegate.m中先调用一遍。然而如果真的调用一遍，耗时耗电不说，还会产生副作用，为此，用一点技巧：

先写一个touch函数，这个touch函数能够放在动态库中，也能够放在AppDelegate.m中，而后在AppDelegate.m中，这么调用一下：

touch_api(0);

这样，等于坑骗了一把xcode编译器，让他误以为咱们的利用中调用了相干的函数，就把相干的函数链接进来了。

留神，如果这样是不行的：

xcode编译器还是有点智商的，它会剖析出并没有真正调用native_times和native_add两个函数，所以不会去链接。但如果变成下面的调用形式，就能够骗过xcode编译器了。