Celedev Blog Archive

On the technical side, enabling the Lua code to use SDK native APIs requires some sort of interface components, which are called Bindings Libraries. In CodeFlow a Binding Library is a package containing two kinds of contents: Lua API modules (i.e. Lua source files containing a Lua translation of SDK APIs), and code libraries that will be linked - when needed - with the target application in Xcode. The code in these libraries handles the necessary conversions between a Lua dynamic environment and iOS native system APIs.

This could look a bit complex, but actually the the use of Bindings Libraries is fully transparent for the user. Once you have selected the SDK version that you want to use, CodeFlow takes care of everything: making code writing easier by proposing auto-completion for symbols in the SDK, configuring the Xcode project of the target application, so that it embeds the framework and bindings libraries needed by the Lua code... These things are automatically done, so you don't need to bother with bindings management.

Therefore Bindings Libraries are an essential component of a dynamic application development system like CodeFlow, because they act as a transparent communication path between the dynamic code and the rest of the system.

Accessing Application-Specific APIs

And for accessing application-specific APIs from Lua, how does that work?

In previous CodeFlow versions, prior to 0.9.15, it was definitely possible to reference (and to extend) specific compiled classes of the target application from the Lua code, to call their methods, or to use their properties and IBOutlets. In most cases that worked just well, but using such APIs was done somewhat in the blind, without completion support from the Lua editor in CodeFlow, and method calls were done in best-effort mode, relying on the (sometimes insufficient) information available in the Objective-C runtime. Besides, application-specific C types or functions were simply not accessible from Lua.

In a nutshell, before CodeFlow 0.9.15, integration between dynamic code and compiled code in an iOS application was a bit limited…

This is why I am happy to present the great new feature of CodeFlow 0.9.15: dynamic creation of Project Bindings Libraries, providing extended access from Lua to specific types and APIs of the target application.

Project Bindings Libraries, this means that all APIs defined in your application's header files can now be used from your Lua code in CodeFlow, with the same level of transparency and quality that was previously only available for APIs of the system SDK. Naturally, Project Bindings Libraries can also include the APIs of third-party libraries and CocoaPods used in your application project! 😃

Specifically, Project Bindings Libraries give access to the vast majority of symbols defined in .h files belonging to your Xcode project; this includes entities declared as #define, enum, struct, C function, const global variable (e.g. string constants declared as extern NSString* const), and, of course, Objective-C classes and protocols, with their methods and properties.

Each CodeFlow project has its own Project Bindings Library. This Bindings Library is automatically created and updated, so as to stay in-sync with the target application's Xcode project. You can configure the content of a Project Bindings Library through a dedicated interface in CodeFlow (read below).

Using Project Bindings

In CodeFlow 0.9.15, if a given CodeFlow project has an associated Xcode project, then a Project Bindings Library is automatically created, to provide Lua interfaces for the C and Objective-C APIs defined in this Xcode project. By default the Project Bindings Library includes APIs defined in all .h files of the Xcode project, but the list of visible header files can be modified in the corresponding Bindings Editor.

As an example, let's consider a WatchKit test application named WatchApp1, that show the following structure under Xcode:

If we select the Project Bindings Library in the associated CodeFlow project, we can see the Bindings Editor for it. The Bindings Editor presents a file tree that mirrors the Xcode project structure and that contains every .h file in this project.

Each .h file (and each group) can be individually selected or unselected, and only APIs declared in selected header files will be included in the Project Bindings Library. In this example, we are only interested in APIs in the "WatchKit Extension" group; so we have unchecked the "WatchApp1" group in the list.

In addition to the selection checkbox, the Bindings Editor displays for every header file in the project:

• a QuickLook button that shows a preview of the .h header file;
• a Bindings-generation-result indicator for this file: green in case of success, yellow if warnings were emitted during the generation, red if the generation did fail, or gray if the generation did not take place; a click on this indicator displays detailed information about the status;
• a direct access button to the generated Lua module API.

Project Bindings Libraries are automatically updated if one of the selected .h files is modified, or if the contents of the associated Xcode Project is changed (e.g. if you add a new .h file in the project). Conversely when you change the list of selected header files in the Bindings Editor, you have to explicitly tell CodeFlow to update the Bindings Library, by either clicking on the Refresh button in the Bindings Editor or by selecting the Update Lua Bindings… command in the Program menu.

And, well… that's about all you need to know for using this new Project Bindings feature in CodeFlow.

The actual usage of the Project Bindings Library in your code is transparently managed by CodeFlow, just as with SDK Bindings Libraries. Project APIs are added to code-completion proposals; Project Bindings code libraries are automatically added to the associated Xcode project if needed; and, during the target app execution, project-specific data are created with the expected types, project methods and function are called with the specified parameter types…

All this is made possible by Bindings Libraries. In CodeFlow they are an essential component of the live-coding system, almost invisible but so important. And with CodeFlow 0.9.15 and Project Bindings Libraries, live coding on iOS takes a major feature boost. And really, for the developer, It just works!

Here the execution is stopped at line 23 in a function named square, where a lot of variable masking takes place.

Variables Inspector

To start with, the function defines a local environment on line 12, that masks the inherited _ENV up-value (that was set at line 4); you can see in the Variable Inspector that the masked _ENV up-value is dimmed but still accessible, and you can easily identify the active _ENV, which is a local variable.

In addition, many variables in the square function are named x. This is really confusing and certainly not a good programming practice, but this is still syntacticly-valid Lua code. Fortunately, the CodeFlow Variable Inspector will help you to clarify things.

The last x in the list is not dimmed, so it is the active variable x; its value has been modified by the last step in the code, as indicated by the yellow highlight on the Craig value. Other variables called x are dimmed, so they are masked; you can locate any them precisely in the source code by selecting it in the variable inspector, like here thexwith value Bob: we can see that it is set on line 21 and never read.

Lua Commands

Now, we can have a look at the Lua Command Editor, in the Lua Console pane. The Lua Console title indicates the context in which the command will be executed, here in function square, line 23. The code of the command is colored appropriately for this context, so it is easier to detect typing errors: you can see that huge and print are colored as up-values, and x is colored as a local variable, which is precisely what we expect.

What happens if we execute the command?

We can see that the values of variables huge and x have been modified (highlighted in yellow), and the console output contains the string printed by the command, with the right value for x.

Other improvements

In addition to these debug-related improvements, CodeFlow v0.9.10 fixes a number of bugs in various parts of the system and improves the reliability of the connection between CodeFlow and target iOS device running the application.

For Swift, the design team has chosen the exact opposite option: build into the language a large set of syntactic constructs, in which you can almost always find one that fits your needs in a given situation. This makes Swift a very powerful language, and most iOS developers I know are really excited about Swift. But it comes at the price of a high complexity: the Swift grammar takes 20 pages in the book The Swift Programming Language and learning Swift is not a matter of one day or two.

A complex language needs a complex and clever compiler, and Swift is no exception to the rule: Apple has certainly put a massive effort on the Swift compiler, capitalizing on the work they did for llvm and clang, and Swift code execution performances rely heavily on compiler optimizations, as shown by many benchmarks on the web comparing Swift and Obj-C performances in debug and release modes. The language sophistication and its needs for code optimization result in a more CPU-demanding compilation and in a probably higher memory usage by the compiler. But for a compiler designed to be used inside Xcode or from the command line, and not supposed to be embedded in a target application, this choice is fully consistent and (reasonable) CPU/memory consumption is not an issue in this case.

Dynamic vs. compile-time decisions

Lua is a dynamic language, meaning that most decisions that affect the code and data structure of the program are made dynamically at runtime, instead of being pre-calculated during the compilation. For example, Lua's main data structure, the Lua table, is a dictionary that doesn't impose any restriction on the types of acceptable keys or values; it is therefore possible at any time to add a property or a method to an object defined as a Lua table. Another example: when compiling a Lua code chunk, Lua doesn't need any context information about this code chunk's source code dependencies; the result of the compilation is just a regular function that can be stored in any variable or called immediately, as decided by the program loading the code chunk.

This dynamicity brings to Lua the same advantages and issues as in other dynamic languages: a huge freedom and flexibility in your code, which is especially great for live coding, but almost no static check to help you detect obvious errors in your code before executing it.

Swift, on the other hand, is all about compile-time checking and ensuring the safety of your code as much as it can. Which is really good for the safety of your code, and probably not so good for your creativity, since it obliges you to make your code base fully consistent before you start executing it.

Therefore the Swift compiler needs lots of context information when compiling a source file, like the definitions of all external entities used by the compiled source code: modules, other classes... All this information helps the compiler to generate better optimized code than in a dynamic approach. But when the code is running, you can not set a property to an object or change a method in a class (or at least not with the language).

Of course, Swift has some dynamic features, like optionals (variables that can be nil), the AnyObject type (needed for Obj-C interoperability), or failable initializers. But compile-time checks are really at the heart of the language. And especially aspects related to type-checking...

Variables vs. values typing

For the developer, probably the most visible difference between Lua and Swift is the way they handle typing.

Swift relies on variables typing. Swift has a strong, but rather classic, object-oriented typing system, and an important part of Swift compile-time check rules are related to guarantying the consistency of variables usage with the corresponding variable declaration types.

On the other side, in Lua, variables are not typed, only values are. Which mean that every value belongs to one of the 8 base types defined by Lua, and that a value always carries its own type with it. A Lua variable is simply a neutral container that can accept a value of any type. This is very flexible, but it puts on the developer's shoulders the task of checking the actual type of a variable, where necessary in the code.

Similarities

Actually Lua and Swift are not opposite in every aspect. On some points, they are even quite close. Here are some examples:

• None of them is derived from C, so they do not suffer from C major flaws: Lua syntax was originally inspired by Niklaus Wirth's Modula languages, and for Swift, its designers made the courageous and excellent decision to drop C compatibility, and to create a brand-new safer state-of-the-art programming language.

• Both include a certain level of extensibility in their syntax: in Lua you can do rather important customization (e.g. defining your own object model in Lua) through the clever use of metatables and metamethods; in Swift, language features like operator overloading, custom operators and generics give you the ability to extend the language syntax.

• In both, functions can have multiple return values: in Lua, a return statement simply accepts a sequence of expressions, e.g. return a, b, c, which is fully consistent with Lua multiple assignment syntax; in Swift, a function can specify multiple return values by specify a tupple as result type, and then use return (a, b, c).

• Both do not require semicolons at the end of instructions, but accept them to force statement separation if needed.

Beyond the language

The object here is not to claim that Lua is better than Swift, or Swift better than Lua. That would obviously be pointless, as both are great programming languages. What this short comparison shows, however, is that Lua and Swift have strength in different areas, related to their respective philosophies, design choices and implementation tradeoffs.

And actually, the programming language is only a part of a bigger development picture. Another important part of this picture is the IDE. The main role of an IDE is not to provide a text editor showing fancy colors in your source code; it is to make your whole development activity easier and more effective.

To achieve this goal, good IDEs include features that compensate for the main limitations of the programming language used. Examples of this can be found in our preferred IDEs: Xcode has the Playground for Swift, that allows you to interactively develop and experiment simple Swift programs; and CodeFlow adds extensive runtime checks to Lua when invoking native methods, that brings type errors detection and preserve the stability of the target app during live development.

Playing with Swift or Lua

If you want to go further and make up your own mind about both languages, here are some valuable resources:

• For Swift, you can go to Apple Swift Resources page, where you will find lots of documentation and the download link for Xcode, in case you don't already have it. Then create a new playground in Xcode and enter some swift code in it.

• For Lua, various language documentation can be found on lua.org, and my personal IDE recommendation for writing Lua code is to use CodeFlow, even if you don't target iOS apps. CodeFlow can be downloaded here, and it can be freely used as a pure Lua playground. To do this, create a new Lua project in CodeFlow (Menu File->New) and, in the project window, select the Local Lua Context target to run and debug the code locally inside CodeFlow.