Celedev Blog Archive

Old posts that were originally published on celedev.com

Celedev CodeFlow has now been renamed Bounces.

Some posts in this section may be outdated or not relevant anymore.
Please refer to the Home page and the Documentation section for current information about Bounces.

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).

Read More

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

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
Blog Post
Apr 22, 2016

Live storyboards in CodeFlow

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.

Apr 22, 2016