A CodeFlow blog

about live coding and more…

CodeFlow 1.0.2


CodeFlow 1.0.2 focuses on improving the Live Application Developer Experience

CodeFlow 1.0.2 is a minor release that focuses on improving the Live Application Developer's Experience.

It includes many small improvements and bug fixes in the following areas: automatic creation of Lua action methods, usability of the Lua editor, performance, project templates and live storyboard updates, Lua runtime robustness and native interface support.

Main Changes

This section list the most significant improvements and bug fixes in CodeFlow 1.0.2. For the complete change list, please see the version history in the CodeFlow readme file.

Automatic creation of Lua action methods

CodeFlow can now automatically create Lua action methods in your project to match IBAction methods defined in the associated Xcode project.

This is especially convenient when using Live Storyboards: you can define the action method associated to an interface component by control-dragging from this component to the corresponding View Controller source file in Xcode, and in CodeFlow, a Lua version of the new action method will magically appear in the corresponding Lua class extension, so you can directly write the action code and test it immediately in the target application.

Here is a short video (also available on Youtube) that illustrates this:

The creation of automatic action methods creation can be configured on a per-Lua-module basis (via a command in the Syntax menu).

Lua editor usability

In CodeFlow 1.0.2, we have improved many small details in the Lua code editor to make it more comfortable to use:

  • Easier type annotations: In CodeFlow you can insert type annotations in your Lua code to improve code-completion proposals for native properties and method names. But manually typing type annotation like --[[@type objc.UIPanGestureReognizer]] can become tedious and error-prone. Now, you can now simply insert a type annotation in your code using the command ⌥⌘T, and auto-completion of class and struct names is working inside type annotations comments. These improvements make type annotations very easy to use where needed in the code.

  • Added brief highlighting of counterpart syntax elements in the Lua editor when you enter code or move the selection. Highlighted elements include the usual set of brackets ( ) { } [ ], and also syntax block delimiters like do, if, while, repeat, function, else, elseif, end, until. Syntax counterpart highlighting can be disabled in the application preferences if you don't like it.

  • Much better behavior of Lua syntax auto-completion in the editor (e.g. the automatic insertion of missing strings terminators or of missing closing brackets): previously, syntax auto-completion could get really annoying sometimes by making deletion of the inserted characters or undo quite difficult; this is now fixed and syntax auto-completion should now be a transparent help when entering code. In addition, more syntax auto-completion patterns have been added, and you can now disable syntax auto-completion in the preference window if you don't want it.

  • Special characters and emojis are now correctly displayed inside Lua source code (special characters are valid inside Lua strings and comments).

Performance improvements

The two main performance optimizations in CodeFlow 1.0.2 are related to very different areas of the system: the first one is purely internal to the CodeFlow IDE, while the second one significantly decreases the debug overhead in target applications:

  • Highly improved display performance of Lua source code files in the editor. This better performance is especially noticeable when scrolling in big Lua source files.

  • Reduced the frequency of global variables refresh in the Variable Inspector while the target application is running. In previous versions, global variables refresh in debug mode could have a significant impact on CPU and network bandwidth in target applications with intensive code-driven animations, like 3D games. Now, the Variables Inspector is refreshed at most once per second when the target application is running.

Project templates and live storyboards

Storyboard-based project templates also have significant improvements in this version:

  • iOS project templates now have support for live update of presented View Controllers, like modal sheets or popovers.

  • During a live storyboard update, the saved state of a replaced View Controller is now applied in the replacing View Controller's viewDidLoad method. This makes the state propagation code in your project much simpler, because the controller's views hierarchy is guaranteed to be available when the state propagation code is executed.

  • During a live storyboard update, Root View Controllers (iOS, tvOS) and Window's Content View Controllers (macOS) are now correctly updated, even if their view is not created yet.

  • Live storyboard updates are now coordinated with project bindings update in case an action method has been added to the updated storyboard. This guaranties that the added action can not be triggered before being defined. This comes in addition to the existing coordination in case of added IBOutlet.
    You can see this coordination mechanism in action in the above video, around 01'12": the storyboard version containing the updateLabelSize UISlider action method (MainStoryboard-12:55:35) is loaded to the target application right after the version of the ViewController Lua module implementing this action method (ViewController-12:55:34), so that interacting with the slider can not cause a method-non-existing runtime error.
    Storyboard updates referencing new actions are now coordinated with code updates.

Lua CodeFlow runtime

In addition to a bunch of minor bug fixes and performance improvement in the Lua CodeFlow runtime library embedded in the target applications, CodeFlow 1.0.2 include a few noticeable improvements in this area:

  • It solves an issue causing a target application using SceneKit on iOS 10 to freeze when a texture resource was dynamically updated. More generally, classes or frameworks that use a shared lock to protect their internal structure (like SceneKit) can now be declared as such to the CodeFlow runtime, which removes the possibility of entering a deadlock when a method of these classes is called.

  • You can now specify custom bindings generation options for project bindings libraries: bindings generation options help the bindings generation process to build the Lua version of C / Objective-C APIs. They do this by providing indications that remove ambiguities in C function parameter types, especially when parameters are typed as pointers, and they can dramatically reduce the number of function or methods of the target native API not available to the Lua code in your project. Custom bindings generation options shall be defined in a file named 'CIMLuaBindingsOptions.plist' located in the same directory as the associated Xcode project.

Bug fixes

CodeFlow 1.0.2 fixes a crash that could occur if a Lua module in the project contained emojis (or other characters of Unicode supplementary planes).


CodeFlow 1.0.1 and WWDC 2016


The just-released CodeFlow 1.0.1 brings support for the new iOS 10, tvOS 10 and macOS 10.12 announced at WWDC 2016 this week.

[Edited Jun 23, 2016: Added quick-start video and notes explaining how to use SDK bindings libraries.]

CodeFlow 1.0.1 Now you can live-code iOS 10, tvOS 10 and macOS 10.12 in Lua

Less than one week after we released CodeFlow 1.0, a new version 1.0.1 has already landed in our download page. And it is much more than a bug-fix release. Since the WWDC keynote this Monday, we have worked non-stop to bring support in CodeFlow for Xcode 8.0 and for the new Apple's OS SDKs, so you can start live-coding and experimenting right away in Lua with the new iOS, tvOS and macOS.

Actually, things went rather well. Without diving too deeply into technical details, the good surprise was that this year's language additions brought to improve the Swiftness of the SDKs (e.g. Objective-C class-properties), were already available in the latest open-source version of the Clang compiler . So I didn't have to add them in Clang by myself, and I could quickly jump to the generation of CodeFlow Bindings Libraries for iOS 10, tvOS 10 and macOS 10.12.

And here it is. CodeFlow 1.0.1 comes with an upgraded Project Bindings Generator, compatible with Xcode 8 projects. SDK Bindings Libraries for iOS 10, tvOS 10 and macOS 10.12 are available as a separate download, because not all CodeFlow users will be interested by these.

Configuring the target SDK in a CodeFlow project

CodeFlow SDK Bindings Libraries provide interfaces between your project and a specific platform / OS SDK version. Actually selecting a given SDK Bindings Library in your project is the way you configure the project for this SDK in CodeFlow. Configuration includes automatically adding the corresponding libraries to the build phases of your app, but it also creates an association between the CodeFlow project and the appropriate Xcode version for the selected SDK.

For example, a CodeFlow project using the iOS 9.3 SDK Bindings library will open the associated Xcode project in Xcode 7.3(.1) and it will also use this Xcode version as the external resource editor for storyboards or nibs. If you select the iOS 10 SDK Bindings library in this project, it will use Xcode 8 instead (because the iOS 10 SDK is supported by Xcode 8, not by Xcode 7.3).

On the practical side, installing and using an additional SDK Bindings Library is very simple:

  1. Download the SDK Bindings Libraries for Xcode 8.0.
  2. Open the Bindings dmg image, and install the Bindings Libraries by double-clicking on them.
  3. In a CodeFlow project, select the target OS SDK by changing the SDK Bindings Library with the contextual menu (or in the main menu Program->Select SDK Library).

As you can see in this video, once you have selected one of the new SDKs (here iOS 10), then all Xcode-related actions in the CodeFlow project will use Xcode 8 (like opening the associated Xcode project or editing a storyboard resource). So you will build and run your app with Xcode 8 and you will have the possibility to use any iOS 10 API in Lua in your CodeFlow project.

Troubleshooting Xcode 8 with CodeFlow

As you can expect from a first developer beta, Xcode 8 and the new OS releases are not completely polished yet, so you shouldn't be surprised if a few bugs are present. In this case, do not hesitate to use the bug-report form in CodeFlow. This will help us to investigate these problems, and hopefully to fix them quickly.

In addition, here are a few tips that you might save you some time when using CodeFlow with Xcode 8:

  • The way to handle app signing has changed in Xcode 8. As a consequence, in Xcode 8, when you run on a device an application created with a CodeFlow project template, it seems that you need to select manually a team for signing the app, otherwise the compilation fails.
  • Storyboards in Xcode 8 have a different file format than in Xcode 7. Therefore if you test a CodeFlow app with a storyboard in iOS 10, and then revert it to iOS 9.3, you might see an error next to the storyboard source item in CodeFlow. In this case, open the storyboard in Xcode 8 and in the right panel, select the File Inspector tab, set Opens in to 'Xcode 7.x', and save. This will remove the storyboard error in CodeFlow.

Bottom line

I will come back to WWDC 2016 in a next post, because lots of interesting things were (and still are) presented during the week. Starting with Swift Playgrounds on iOS. But this is another story…

In the meanwhile, have fun live-coding the new features in iOS 10, tvOS 10 and macOS 10.12 with CodeFlow! 😃

Read More

CodeFlow turns 1.0


It has been some time since the last beta of CodeFlow, version 0.9.20 was released in January this year. And all this time, we have worked very hard to improve CodeFlow, and to turn it into an effective Application Development System that we love to use in our daily work.

We have – literally – fixed hundreds of bugs. We have added awesome new features and and brought significant improvements to almost every aspects of the system. And, to be honest, all this has taken slightly longer than expected. But it was worth the wait.

And Today, I am very happy to announce that CodeFlow 1.0 is available for download! 🚀 😃 🎉

Note that, even if the version number has jumped to 1.0, we consider the CodeFlow beta phase as still ongoing. Which means in particular that you can still use CodeFlow for free for a while, so really you should have no reason for not downloading this 1.0 version… 😉

Before jumping into new features of this version, let's start with a quick recap of what CodeFlow is and what it does.

What is CodeFlow?

CodeFlow is a Live Application Development Environment for iOS, tvOS and macOS.

Lua language

CodeFlow use the Lua programming language for Live Application development. Lua is a nice, fast, easy-to-learn and powerful language.

And if you are not yet familiar with Lua, a good way to start is to read our Get Started with Lua tutorials.

Native APIs

With CodeFlow, you create native applications, that use native OS APIs, and run their native UI at native speed.

This is made possible by a key component of CodeFlow: the native bridge. In short, CodeFlow native bridge makes the OS SDK available to the Lua code in your app. Meaning that anything you can do in Objective-C or Swift, you can do it in Lua with CodeFlow. And there is more: the native bridge extends to your own custom code in the App Xcode project, so you can easily write hybrid applications, partly written using traditional Objective-C or Swift code, and partly written in Lua, with both parts capable of working closely together.

To learn more about the native bridge, read Get Started with Lua - CodeFlow Native Bridge.

IDE

CodeFlow comes as an IDE, running on macOS. The CodeFlow IDE includes a nice dedicated Lua code editor and a powerful, always-available Lua debugger.

The Lua editor includes features like advanced syntax coloring, code indentation, syntax error detection, variables scoping, or automatic code completion (including native methods or property names from the OS SDK).

The Lua debugger supports breakpoints, step-by-step execution, and stop-on-error. It has a nice stack & variables inspector, that shows the contents of Lua local and global variables, capable of presenting useful information for both Lua and native values/objects. It supports multithreaded execution and shows all active Lua threads in the program at any given time. Finally, the Lua debugger includes a context-aware Lua command console, in which you can execute arbitrary code in the context of the selected Lua thread/stack-frame.

A codeFlow project can include Lua code files, as well as (non-code) resources (e.g. images). CodeFlow includes a QuickLook-base resource viewer, and delegates resource editing to appropriate external resource editor applications. And CodeFlow also supports resource update by drag-and-drop.

Live App Development

Live Application Development is a more-natural more-interactive way of developing applications. Where old-style App development considers code-writing and app-running as two separate steps in the development cycle, Live Application Development gives you the freedom to code your application while it is running. Seeing the results of source code edits immediately in the real application, without having to re-build, re-load and re-run it, is incredibly fun and powerful, especially when creating the app's user interface, or for fixing bugs.

As a Live App Development Environment, CodeFlow is designed to provide instant feedback to the developer, by updating the running application in real-time when its source code is changed.

For this, CodeFlow implements two features. The first is automatic device connection: Devices in the network that run an application embedding the CodeFlow library are automatically detected by CodeFlow and can be used as targets by a corresponding CodeFlow project.

The second feature is live application update: When connected to a target application, CodeFlow keeps this application in sync with the current project, updating Lua source code and resources in the app when necessary, and without stopping it.

Live App Development is not limited to a single device: you can connect multiple devices to a same CodeFlow project, with different screen sizes or different OS versions, and do live update on all of them simultaneously!

Local Lua Context

A Local Lua Context is a special kind of lightweight target for a CodeFlow project, that executes the project's Lua code inside the CodeFlow IDE. Local Lua Contexts are useful as playgrounds, when you just want to test some code without creating an application for that. Local Lua Contexts have access to a limited set of macOS frameworks and they benefit from the same debug facilities as real target applications.

New Features in CodeFlow 1.0

CodeFlow 1.0 includes quite a lot or new or improved features, and enumerating them all would make this post too long and boring.

This section will highlight a few important new features in CodeFlow 1.0. Other improvements will be listed in the next section Other Changes in CodeFlow.

Project templates

Project templates in CodeFlow are similar to templates in other IDEs: they create pre-packaged projects that you can use as a starting point for your own app. Using a project template saves you lots of time and effort, as you don't have write boilerplate code or project setup before launching the target application for the first time. In CodeFlow, templates are particularly important for two more reasons:

  1. CodeFlow is a Live Application Development Environment, so things have to be responsive and fast, particularly when starting a new project;
  2. CodeFlow targets iOS, tvOS and macOS, so a CodeFlow project is not enough to build an application: an Xcode project is needed too. And this brings additional complexity to the project setup.

This is why project templates was certainly the most awaited feature in CodeFlow. With CodeFlow 1.0, the wait is now over, and project templates turn live app creation into a very simple operation.

When you create a new project in CodeFlow (File->New Project… or ⌘N), the New Project Window is diplayed and shows a list of available templates. Select a template in the list, configure a few fields (or leave them with the default values), select a directory for the new project and you are done.

New Project Window

Actually a CodeFlow template creates two projects: a CodeFlow project and an Xcode project, associated with the CodeFlow project and configured accordingly. Therefore, as soon as CodeFlow completes the project configuration , you can open the Xcode project from CodeFlow (Program->Open Xcode Project or ⇧⌘O), run the application on a device or in the simulator, and start live-coding right away.

CodeFlow 1.0 includes 9 generic application templates: 5 for iOS, 2 for tvOS, and 2 for macOS. All of them have a Swift/Objective-C option for the associated Xcode project. And all of them, except the Empty iOS Application template, support live storyboard updates (see below).

In addition, CodeFlow 1.0 comes with a few Example Application templates. Examples Applications are provided as templates, so that you can play with the code at will, and if you break things up, you can simply create a new project and continue experimenting with it.

Live storyboard update

Storyboards play an important role in iOS app development, and CodeFlow could not pretend to enable Live App Development for iOS without supporting seamless storyboards updates in target applications.

So live storyboard update is available in CodeFlow 1.0. And this is a good thing, because actually seeing the user interface take shape interactively in the real application, when adding interface components and setting layout constraints in Xcode, is an incredibly cool experience!

I wrote an entire blog post about Live storyboards in April, so please read it if you want to know more about this feature. Or watch this short "Hello World" video (from the same blog post) which gives a pretty good idea of live storyboards in action.

Under the hood, the magic of live storyboard updates comes from a Lua module present in every project template (for storyboard-based apps). This module, called MonitorViewControllerClass in iOS projects and MonitorControllerClass in macOS projects, is available in source code, so feel free to customize it for your own needs if necessary.

Swift support

CodeFlow 1.0 adds support for Swift. This means that the CodeFlow library can be integrated in an application written in Swift, and also that classes, methods, and object properties defined in Swift can be exposed to the Lua code in CodeFlow.

All generic application templates in CodeFlow have an option to create a Swift Xcode project. You can use these templates as examples of how to use CodeFlow's CIMLua interface in Swift.

Concerning the visibility in Lua of class, methods or properties defined in Swift, the rule is simple: Swift class, methods or properties that are visible from Objective-C, are visible from Lua.
For more information about this, see Apple document Using Swift with Cocoa and Objective-C.

That being said, there is no real difference, seen from Lua code, between native interfaces exposed by Swift and native interfaces exposed by Objective-C. It just works.

Lua Runtime improvements

The Lua Runtime is the CodeFlow library that powers live code execution and update in target applications. In CodeFlow 1.0, the Lua runtime includes lots of internal improvements, and it gains noteworthy new features:

  • Lua object properties are now compatible with KVC and KVO (Key Value Coding / Observing), so you can implement a property in Lua, and have native code of your application notified when it change. And you can use Cocoa bindings on macOS, to display a Lua property in your target application without writing a single line of code.
  • You can now call the original implementation of a native method, even when a Lua method overrides it. You do this by indexing the target object by the objc global variable, like this self[objc]:viewDidLoad(). You generally use this feature to extend in Lua a method already implemented natively by the current class; you can also use it as an easy and reasonnably-safe way of doing dynamic method swizzling!
  • You can now use weak references to native objects in your Lua code. Weak object references are useful to avoid creating retain cycles involving one or more native objects. CodeFlow 1.0 add two generic Lua object properties weakRef and strongRef for controlling the memory lifecycle of native objects. anObject.weakRef gets a weak reference on anObject, that you can use in your Lua code or store in a variable without preventing the deallocation of the referenced object. On the other hand, yo use strongRef to get a back strong object reference from a weak reference; if the object does not exist anymore, strongRef returns nil. Note that a Lua object property can also be defined as "weak".

Other changes in CodeFlow 1.0

This section lists other significant improvements brought by CodeFlow 1.0.

Lua Source Editor

  • Code-completion now include methods and properties declared in Objective-C protocols referenced by the current Lua source file.
  • Code-completion of native bridge globals, like objc or struct, are now proposed even if the global has been aliased to a local variable. For example: Code-completion still works for fields of aliased global variables
  • Type comment annotation, like --[[@type objc.UICollectionViewLayout]] are now taken into account when proposing code completions in the current Lua file.
  • Improved 'Dependencies' menu in source editor bar, that displays the full hierarchy of classes, protocols and structs referenced in the current Lua file. In addition, selecting a class, class category, protocol or struct in this menu jumps to the corresponding declaration in the relevant bindings file and highlights it.
  • Pasting or uncommenting code now correctly re-indent the corresponding code range.

CodeFlow Project & Files List

  • Added a New Empty Project command in the File menu, that creates an empty project with a Local Lua Context.
  • Added support for package-typed resources in a CodeFlow project. This means that you can add a resource of any type to a CodeFlow project and process this resource in the Lua code of your target application.
  • Drag & drop: You can now control how dropped files in the project files list shall behave by using standard modifier keys: use ⌥⌘ to link the resource item to the dragged file, to create an internal copy of the dragged file, or to replace the content of a resource without replacing the existing link. You can also set the default behavior (link or copy) in the CodeFlow preferences.
  • Drag & drop: You can now replace the content of a resource with a file having a compatible content type. For example, you can drop a png file on a resource with a jpeg image content, and see the connected target applications being updated with the new image.
  • A group in a CodeFlow project can now be linked to a directory in the file system. Linking a group means that any change you make to this group in CodeFlow will be reflected in the linked directory (adding or removing a Lua source file or resource, editing a Lua file…). And any change in the linked directory will be immediately visible in the group in CodeFlow. In addition, changes done to a linked group, in CodeFlow or by modifying the linked directory, can now be undone.
    Linked groups in CodeFlow can be used to share Lua code between projects, or to organize Lua code and resources into git repositories/submodules (or equivalent configuration management units for your favorite tool).

Code Execution and Debug

  • Projects can now automatically connect to target applications with specific service name patterns. When you create a CodeFlow project from a template, the auto-connect pattern is automatically set for you, based on the new project's Product-Name and Lua-Context-Name, so generally you don't have to set this manually.
    Automatic connection to targets is configured in the Targets popover
  • The initial breakpoint on a starting target Lua Context can now be enabled / disabled on a per-project basis.
  • Lua module reloading does not interrupt you anymore when you are typing code in Lua module with autoload enabled!
  • Continuing execution after stopping in an old code module version, now switches back the code editor to the last edited file.
  • Added keyboard shortcuts and menu commands for debug actions.
  • In Local Lua Contexts, you can now use the debug commands to run a Lua source file, when the Lua Context is idle.
  • Added a Restart Local Lua Context command in the Execution menu.
  • Switching the debug interface to a given connected targets is now possible via the execution menu, or with keyboard shortcuts ⌘1, ⌘2
  • The variable inspector now updates global variables in real time while your application is running (even if it does not stop on a breakpoint).

Lua Code and Bindings

  • The new property() Lua function is the new way of declaring object properties in Lua classes. Properties declared using this syntax (see in Get Started with Lua - CodeFlow object Framework) are flexible and compatible with Objective-C properties and Swift computed properties.
  • Added Lua object introspection methods implementsLuaMethod and implementsLuaClassMethod.
  • More flexible Message/Resource handler parameters. For example, a handler function passed to a Message- or Resource-Handler can now omit the self parameter if not useful.
  • Resource handlers now have an extra resource file URL passed as their last parameter. This allows a resource handler to use the raw resource data if more convenient than using the proposed resource object.
  • Binding Lua files now have a type annotation for block parameters that indicates the expected function prototype. Example:

    function NSString:enumerateSubstringsInRange_options_usingBlock 
                    (range --[[@type struct.NSRange]], 
                     opts --[[@type enum(NSStringEnumerationOptions)]], 
                     block --[[@type function(substring, substringRange, enclosingRange)->stop]])  
        --[[@return nil]] 
    end
    
  • Binding Lua files now indicate required and optional methods of protocols
  • Binding Lua files now declare properties using the new property notation. Example:

    UIView.userInteractionEnabled --[[@type bool]] = property { get = 'isUserInteractionEnabled' }
    UIView.tag --[[@type integer]] = property()
    UIView.layer --[[@type objc.CALayer]] = property { kind = 'readonly' }
    UIView.focused --[[@type bool]] = property { kind = 'readonly', get = 'isFocused' }
    
  • Local Lua Contexts now have an associated SDK Bindings library that shows available frameworks and APIs.
    SDK Bindings Library for Local Lua Contexts show available frameworks

CodeFlow Objective-C/Swift API

  • Added method -doLuaSetupIfNeeded that you call on instances of a native class with a Lua extension, if some Lua-specific setup must be done on these instances. For example, if you load a Lua module that extends the class of the root view controller, you can write:

    [_luaContext loadLuaModuleNamed:@"ViewController" withCompletionBlock:^(id result) {
        if (result != nil) {
            // Configure the rootViewController in Lua
            [(id<CIMLuaObject>)self.window.rootViewController doLuaSetupIfNeeded];
        }
    }];
    

    or in Swift:

    luaContext?.loadLuaModuleNamed("ViewController", withCompletionBlock: { (result) in
            // Configure the rootViewController in Lua
            (self.window?.rootViewController as! CIMLuaObject).doLuaSetupIfNeeded()
        })
    
  • Added method -isLuaClassExtensionLoadedForClass: and -isLuaClassExtensionLoadedForClass:withId: to test if a given Lua class extension is loaded.
  • Improved kCIMLuaModuleLoadedNotification, that now contains extensive information about the loaded module and its results. In addition, this notification is now sent for every loaded module (previously it was only sent for Lua modules loaded from the CIMLua API).
  • On iOS, your app can now display a modal dialog while trying to connect to the IDE. Pressing the 'Skip' button in this dialog make the app switch to the embedded Lua code and resource cache.
  • Added nullability annotations in CIMLua.h, for a better coding experience in Swift.
    Note that these nullability annotations make CIMLua.h incompatible with Xcode 6.2 and earlier. If this is a problem for you, drop us a line (by email or using the feedback forms in CodeFlow) and we will manage to find a compatible solution very quickly.

Xcode Project Management

  • Better accuracy of the list of frameworks and libraries that need to be linked with the target application.
  • Project bindings generation now gently asks Xcode to write unsaved files to disk, in the associated Xcode project, before checking if a Bindings Library update is needed.
  • After changing the Xcode project, changed methods and properties are available much quicker for code-completion in CodeFlow Lua editor, or for dynamic declaration in the target application.
  • CodeFlow now enforce the consistency between the target platform defined in the associated Xcode project and the SDK Bindings library selected in a CodeFlow project.

Misc.

  • New application icon.
    CodeFlow new icon
  • You can now send feedback or submit bugs without leaving CodeFlow. Select Send Feedback… or Report a Bug… in the Help menu, and write your feedback in the provided rich-text editor. You can paste code from CodeFlow or Xcode (it will keeps its colors), you can add images, or attachments of any kind. You are free. The sole constraint is the size: feedback messages are limited to 64 MB each, so no big movie, but everything else should fit in.
    Use the new feedback forms to report a bug or to send general feedback
  • Updated user license agreement.
  • Updated internally the Sparkle framework to version 1.14.0 (For information, CodeFlow use https for updates, and was therefore not vulnerable to the security issue fixed by this version, but it is always good to stick to a recent version :-).
  • CodeFlow now include bindings libraries for the SDKs available in 7.3.1 (iOS 9.3, tvOS 9.2, macOS 10.11.4).

Code different : Think live.

All these new features and improvements make CodeFlow 1.0 a great App Development System. And the Live Development feature makes CodeFlow truly unique in the world of iOS coding tools.

You can download CodeFlow 1.0 from the downloads page here.

And we'd love to hear from you. Use the new feedback forms in CodeFlow's Help menu, and tell us how you use CodeFlow, what you like in it, what we should improve, what feature you want too see in future CodeFlow versions…

And, most of all, we hope that you will enjoy the freedom and creativity enabled by live coding!

Read More

Live storyboards in CodeFlow 1.0


Live storyboards are a important feature of the upcoming CodeFlow 1.0. Mixing the power of Xcode storyboards with the flexibility of CodeFlow live coding, they are amazing for fast, fun and creative live app development.

Storyboards and Interface Builder (IB) are promoted by Apple as a (the?) recommended way of creating user interfaces for iOS/tvOS/MacOS. Actually IB has seen significant improvements in recent Xcode versions, especially since Xcode 6 with its finally-usable layout constraints editor, and in Xcode 7 where storyboards have become more modular, making them usable by small development teams. And it seems that now, most (non-game) iOS/tvOS/MacOS developers use IB storyboards or nib files as part as their app development process.

However, IB still presents a quite abstract and static view of your app interface, and often it is not easy to figure out how this interface will actually feel and behave in the real app, until you run it in the simulator, or (better) on an actual device. And more often than not, the result is not exactly what you expected, so you have to iterate again and again the process: edit stuff in IB, rebuild and restart your app, check the result. Boring and time-consuming.

This is the reason why I'm happy to present in this post a great new feature of CodeFlow 1.0: live storyboards.

You can get a first idea of what live storyboards are, by seeing it in action in this Hello World short video tutorial:

In the above video, the Hello World app runs on my iPhone (whose screen has been recorded with Reflector and then added to the Mac screen capture); the app is started only once, right after the CodeFlow project is created, and all subsequent changes occur in live coding mode, while the app is running.

And now, time to describe in more details the live storyboards feature.

CodeFlow Project Templates

First, a few words about another CodeFlow 1.0 new feature: project templates.

CodeFlow 1.0 includes project templates. CodeFlow project templates provide a way to easily create a ready-to-run app consisting of a CodeFlow project and an associated Xcode project. The application in the Xcode project creates a Lua Context and makes it available for connection from CodeFlow. The Xcode project usually includes additional app-specific code and resources, and notably storyboards. The CodeFlow project contains all necessary Lua code and resources, making the newly-created application ready for live-coding.

Project templates remove the need for writing boilerplate code, both on the Swift/ObjC side in Xcode, and on the Lua side in CodeFlow, making it much easier and faster to start a new project. In addition, project templates can include quite complex live-update patterns in the application, in a totally transparent way for the app developer. As such, they are a key enabler of the live storyboards feature.

Live storyboards

As you might have guessed from the video, what we mean by live storyboards is the capacity to display right away in the running target application, any change made on a storyboard in Xcode. Combined with application live-coding, live storyboards brings the usefulness and power of Xcode storyboards to the next level, by making you see your actual app interface take shape interactively, while you design it.

So, how do live storyboards work in practice?

Storyboards as CodeFlow resources

At a first level, a storyboard behave like any other resource in CodeFlow. When you add a storyboard to a CodeFlow project, every new version of the storyboard file gets reloaded in the target application, where a registered resource handler takes care of updating the referenced View Controllers, making them match the new storyboard version.

To keep things simple and easy for the developer, a storyboard resource handler is included as a separate Lua module in every CodeFlow project template. This storyboard resource handler is capable of dynamically updating many common patterns of View Controllers hierarchy, and is easy to customize if your specific case is not supported.

With the provided storyboard resource handler, all you have to do is to add ViewController-specific configuration code in a few optional methods, used for configuring the ViewController's view when loaded, refreshing this view in case of code update, or preserving the ViewController's state in case of storyboard update.

In summary, as you can see in the video, when a storyboard referenced by a CodeFlow project is saved in Xcode, its View Controllers are updated in the target application, and the new storyboard becomes immediately visible on your device screen.

Live outlets and actions

This storyboard resource update feature is good, but it was not sufficient for a true live-coding experience. Actually, IB storyboards and nibs are useful for designing screen layouts, but they also have the very key function of declaring relationships between interface elements and application code, in the form of IBOutlets (a reference to an interface element from an object in the code) and IBActions (a method triggered by an interface element).

Therefore, dynamicity in storyboards implies that you will want to create and connect outlets and actions on the fly, without having to rebuild and restart the target application. For example, in the above Hello World video, after adding the label to the view, we had the need to set its (non-static) text from the ViewController's code, and the tap gesture recognizer would have been useless if we couldn't implement its action method dynamically in CodeFlow.

CodeFlow 1.0 handles this transparently: any property you add in the Xcode project's Swift or ObjC header files is dynamically created in the corresponding class of the running target application. And any action method declared in Swift or ObjC can be live-coded right away in Lua in the CodeFlow project. As a consequence, when the storyboard is updated in the target app, the storyboard instanciation code is capable of connecting the contained interface element to their corresponding outlets or actions, even if those were not defined at the time the application was compiled and run.

To recap, with CodeFlow 1.0, you can add properties and methods at the Xcode project level, and then use them immediately in both the app storyboard(s) and in your project's Lua code, with the insurance that it won't cause an error nor crash the app. And as a nice goodie, the Lua code editor in CodeFlow even shows auto-complete suggestions for the newly added properties and functions, making the code easy to write!

Live class creation

Live class creation is the last rocket stage of CodeFlow live storyboards feature. It turns out that a common need, when designing UI with storyboards, is to add to the storyboard a new custom View Controller or View, and to create a specific class for it at the same time.

CodeFlow 1.0 supports this use case without leaving the live coding mode, by implementing live class creation. When a class (Swift or ObjC) is added to the associated Xcode project, CodeFlow dynamically creates this class in the target application. So when a storyboard update is received, all referenced Views or ViewControllers can be correctly instanciated with their expected class by the storyboard, as this class already exists in the target application.

As a consequence, CodeFlow gives you the freedom to create a new class in the Xcode project, to add objects of this class to the storyboard, to see these objects in the target application immediately, and to write the code for the new class in live coding mode, all this without interrupting the execution of the target application.

What you can do with live storyboards

So. If you have read the technical descriptions above, you should have a pretty good idea of what this live storyboards feature does, but you may wonder: "What can I do with it?"

Here are a 3 typical use cases of live storyboards:

Interactive app design

This is the simplest use case, the one demoed in the hello World video, where you see the running app take shape interactively while you work on its storyboard.

The advantages of live app creation are obvious in all cases, except maybe the simplest ones. For example if you create a complex layout with lots of constraints, the fact of testing them directly and interactively on a device, in portrait and landscape mode, allows to debug and adjust the design much faster and easier than with the traditional cycle: edit in IB, then build, then run.

And if you need to handle some of your layout constraints in code, or animate part of the layout, the benefits are still higher, as you can simultaneously adjust the constraints in IB, define constraint outlets and play with these outlets in the CodeFlow project live code!

Multi-device app design

This is a variant of the previous use case, that takes advantage of CodeFlow multi-device live coding capabilities.

With CodeFlow live storyboards, if you run the target application simultaneously on several devices with different screen sizes (like an iPhone 4s, a 6 Plus, and an iPad), you will see how your interface looks and behaves on these devices, and this will allow you to interactively adjust the app design and size classes, so that your app makes the best use of every device screen size.

[Hey @twitter, this is for you! No more excuse to treat my iPad like a big iPhone!]

You can see an example of multi-device app design, using live storyboards and size classes in this short video:

Team live app design

Another great use case for CodeFlow live storyboards and live coding in general, is when you work on the app interface design with your coworkers, your boss, or your client. Everyone in the meeting can have the app running on his/her own iPhone or iPad, see in real time the changes done to the design, and give their personal feedback about them to the group, or suggest other adjustments.

The immediately visible feedback provided by live app design increase the group's creativity and helps to make the various design option easy to understand by non-tech people.

Read More

Fantastic Bindings!


A great new feature of CodeFlow 0.9.15 is the automatic creation of Project Bindings Libraries. But what role do Bindings Libs play in CodeFlow? And what make them so important?

Since the very beginning, the main goal of CodeFlow is to bring real interactivity to iOS Apps development. Real interactivity implies a development environment that provides the highest possible level of responsiveness between the writing of the application's source code and the execution of this code on the target device, while giving to the developer access to every capability of the iOS platform and the comfort of using iOS familiar APIs.

The use of Lua as the programming language for dynamic code in CodeFlow comes therefore with the possibility to have access in Lua to the whole iOS SDK. Except for a few low-level frameworks, almost every API, type, classe, protocol and method defined in the SDK can be used in Lua, in a very straightforward and natural way. This is one of CodeFlow's big strengths: be fully transparent regarding the set of APIs usable from the code, avoiding thus the constraints of a proprietary API, and the pitfall of a narrow target application domain.

Bindings du SDK IOS dans une application

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.

Librairie de bindings

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.

Bindings projet dans une 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:

Structure du projet 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.

Éditeur de bindings projet

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!

Read More

Recent posts

Blog Post
Aug 1, 2016

CodeFlow 1.0.2

CodeFlow 1.0.2 is a minor release that focuses on improving the Live Application Developer's Experience.

Aug 1, 2016
Blog Post
Jun 16, 2016

CodeFlow 1.0.1 and WWDC 2016

The just-released CodeFlow 1.0.1 brings support for the new iOS 10, tvOS 10 and macOS 10.12 announced at WWDC 2016 this week.

Jun 16, 2016
Blog Post
Jun 9, 2016

CodeFlow turns 1.0

It has been some time since the last beta of CodeFlow, version 0.9.20 was released in January this year. And all this time, we have worked very hard to improve CodeFlow, and to turn it into an effective Application Development System that we love to…

Jun 9, 2016

Last tweets

Dec 5, 2016
@JLJumpertz
"Programming iOS in Lua - A bridge story"
Slides of my talk at Lua Workshop 2016 are here: slideshare.net/jljumpertz/pro…
#lualang #iosdev
Dec 5, 2016
Oct 11, 2016
Little Lua red Panda is now on GitHub! github.com/celedev/LuaPan…
A SceneKit 3D game in #LuaLang with dynamic update of all 3D assets and code
Oct 11, 2016
Oct 3, 2016
CodeFlow 1.0.3 is out!
⚡️ Live SceneKit assets, Sierra support, and more…
celedev.com/en/download/#c…
#lualang #iosdev
Oct 3, 2016
Oct 1, 2016
@aligatr
@Javi @nicklockwood same and also sad they didn't mention Redux realm.io/news/benji-enc… nor @celedev for Live Reloading & Faster iterations
Oct 1, 2016
Sep 22, 2016
If you want to test in #LuaLang the (few) new APIs added in iOS 10.1, CodeFlow SDK Bindings for Xcode 8.1 are there
celedev.com/en/download/#s…
Sep 22, 2016
Sep 20, 2016
Live update of SceneKit assets will be available very soon in a new CodeFlow version (1.0.3). Stay tuned! 😊
Sep 20, 2016
Sep 20, 2016
@JLJumpertz
🎉 Live feedback of SceneKit assets in a running app with @celedev!
1. texture
2. scene editing
3. animation
Sep 20, 2016
Sep 8, 2016
Ready for shipping your app for iOS 10, tvOS 10 or macOS 10.12?
Our #LuaLang live-code SDK Bindings are ready too 😎
celedev.com/en/download/#s…
Sep 8, 2016
Sep 6, 2016
@JLJumpertz
Next step, add live SceneKit resources: when using Xcode's SceneKit editor, send the updated assets dynamically to the live application.
Sep 6, 2016
Sep 6, 2016
@JLJumpertz
Amazing how easier SceneKit becomes when using live application update, thks to instant feedback of 3D math! 😃
Sep 6, 2016
Aug 4, 2016
Minor update for CodeFlow 1.0.2 today, fixing a rare issue in dynamic resource updates.
Check for updates or celedev.com/en/download/#c…
Aug 4, 2016
Aug 3, 2016
If you use Xcode 8 beta 4 and CodeFlow, Lua Bindings for the latest iOS 10, tvOS 10 and macOS 10.12 SDKs are here:
celedev.com/en/download/#s…
Aug 3, 2016
Aug 1, 2016
CodeFlow 1.0.2 🚀: learn about automatic Lua action methods and other changes in this new blog post: celedev.com/en/blog/2016/c…
#lualang #iosdev
Aug 1, 2016
Aug 1, 2016
In CodeFlow 1.0.2, automatic creation of Lua action methods leverage the power of Live Storyboards.
New video: youtu.be/koUkihgmyU8
Aug 1, 2016
Jul 29, 2016
For details about improvements and fixes in CodeFlow 1.0.2, release notes are here: celedev.com/en/download/co…
Jul 29, 2016