You absolutely can. Xojo creates native apps that are also cross-platform. It can be done. It’s just a matter of choosing the right framework. At Xojo, we didn’t take the easy path of drawing controls ourselves or using HTML5. We didn’t dumb things down to the least common denominator. We did the hard work of creating a framework with an API that manages the nuances, intricacies, and subtle yet important differences between 7 different platforms (macOS, Windows, Linux, web, Raspberry Pi, iOS and soon, Android) and multiple OS versions so you can focus on what makes your application unique. We have been doing it for over 20 years.

When discussing Facebook’s blog post, John Gruber of Daringfireball.net said, “…native apps are smaller, faster, and more reliable.”

Nearly every user interface element in Xojo is native. The one exception is the desktop Listbox because way back when, none of the desktop operating systems provided one. Everyone made their own. Having said that, the Listbox is made up of native controls. The scrollbar is a native scrollbar. If the developer makes the contents editable by their end user, a native TextField control appears. The headers are native controls. The advantages of native controls can’t be overstated, Facebook was right about that. Modern operating systems provide an ever-increasing array of features via their native controls and thus using them gives you immediate and nearly free access to these features. From focus rings to spellchecking to accessibility and more much, using native controls makes the most sense.

Event aesthetics come into play. Because the Xojo framework uses native controls, when Apple and Microsoft make changes to the look and feel of their controls, apps made in Xojo automatically change in appearance and behavior. Most recently, Apple added Dark Mode to both macOS and iOS and for most Xojo developers, adding this support required nothing more than indicating they wanted their apps to support it by clicking a checkbox.

While Xojo provides the developer with an easy drag-and-drop way to create their application’s user interface, it also provides a straightforward API for interacting with controls via code. The TextField control, for example, provides events that tell you when the control has appeared for the first time, when the user has changed the selection or the text itself, and even when they press down on a key or release it. There are properties to change the size, style and behavior of controls. And all of this is a level of abstraction that lets you focus not on the details of the platform but on what makes your application unique.

For example, under the hood for the desktop, Xojo’s TextField uses NSTextField on macOS, EditControl on Windows and GTKEntry on Linux. On iOS it’s the UITextField, on Android it’s EditText and on the web it’s <input type=”text”>. Each of these is very different but Xojo has done the hard work to provide a standard, straight-forward API so that you get the benefit of native controls without needing to learn the thousands of APIs and unique behaviors necessary to create a cross-platform app.

It’s not just controls. The Xojo cross-platform framework includes dialog boxes, menus, access to the file system, printing, sockets, database access and much more.

Native is more than the user interface. It’s also about performance. Xojo compiles to native code for each platform as well. Behind the scenes it uses LLVM, the same optimizing compiler that Apple, Google, Intel, AMD, Nvidia and many others use. Native code means native speed.

Thousands upon thousands of Xojo users have built cross-platform apps. The Xojo IDE itself and much of the Xojo framework are written in Xojo. So yes, we eat our own dog food. Studiometry and Property Me are just two of the many examples of commercial cross-platform apps written in Xojo. There are countless others.

We have also done this in a way that makes it easy for students and hobbyists to learn programming so they can take it into their workplaces and build business applications. In some cases, those citizen developers create something revolutionary and become full-time professional developers. That’s why the Xojo user community is so diverse.

So yes, you can create native applications that are also cross-platform. You just have to choose the right tool.

In this case the specific FOR NEXT loop in question is :

For X As UInt8 = 0 To 255 
  Dim strAnything As String = "Hello World" 
Next

If you run this code you’ll find that it runs forever. You’ve accidentally created an infinite loop.

How did this come to be this way? There are two things involved. One is what range of values a Uint8 can actually store. And the second is the actual code generated for the for loop itself. When these two combine the stopping conditions will never occur.

Uint8 values can hold a range of values like any integer. They are all positive. And the range is from 0 – 255.

So a Uint8 will NEVER hold a value > 255 or < 0.

Combine this with the fact that a FOR loop is generated using roughly this underlying code

Dim loopCounter As UInt8
Dim loopLimit As Integer = 255
Dim loopBase As Integer = 254
Dim loopStep As Integer = 1

loopCounter = loopBase

loopTop:
  If loopCounter > loopLimit Then
    GoTo loopEnd
  End If
  
  // loop body code would be here
  // its been elided to focus on the actual loop mechanics
  //    dim strAnything as string = "Hello World" 
  // 
  loopCounter = loopCounter + loopStep // NOTE THIS CAN CAUSE OVERFLOW !

  GoTo LoopTop

loopEnd:

This is NOT the actual code used. It is just a Xojo version of the actual underlying LLVM IR code that gets generated.

Hopefully this explains the confusion. Since a Uint8 cannot hold a value greater than 255, you will find that when loopCounter IS already 255 and the increment, or loopStep in this example, is added to the existing value the loopCounter goes NOT from 255 to 256 but back to 0. It wraps around. This isn’t a bug.

The addition of the loopStep value causes the Uint8 to overflow since the value 256, in binary, requires 9 bits, not 8 but the Uint8 can only hold 8 bits. And so when you add it the 8 bits the value can hold are all 0 and the loop counter resets to 0.

And this behavior is not specifically a Xojo thing, most programming languages do this. In fact, there are some very well know encryption algorithms, like BlowFish, that rely on this  .

In the specific sample code that prompted this post, a loop counter that is an Integer or Uint16 is needed because they can hold values that exceed the loops upper bound.

Loops that count down have a similar problem. but counting down and underflowing instead of overflowing.

The moral of the story is to stick to using the general Integer data type unless you have a specific need for a size-specific Integer type.

This is the sixth post in our Compiler series. Previous posts:

• LLVM Everywhere
• Compilers 101 – Overview and Lexer
• Compilers 102 – Parser
• Compilers 103 – Semantic Analyzer
• Compilers 104 – IR Generation
• Compilers 105 – Back End Overview

The Optimizer does a series of transformations to the IR code, typically in multiple passes. LLVM provides full control over these passes.

Not all LLVM optimizations provide benefits to Xojo code. We have distilled the many complicated optimization settings that are available with LLVM into three options that are useful for Xojo code, which you can set from the Shared Build settings: Default, Moderate and Aggressive.

The Default optimization does minimal optimization in order to have the quickest compile times.

The Moderate setting does more optimizations, primarily to reduce the time needed for mathematical calculations which results in slightly slower compile times.

The Aggressive setting does many more mathematical optimizations to further reduce calculation time, but also dramatically increases compile time.

Optimization intends to create something that is equivalent to the original code. The end result is the same, even if the means to do so might be very different. For example, the optimizer may determine that it should do a bit shift to do integer math as a single operation rather than a series of add operations. This could result in smaller, faster code but may take longer for the optimizer to process the code in order to make this determination.

Deciding the “best” optimization for any code is not technically a solvable problem (np-hard), so optimizers use a combination of “heuristics and hand-waving”. “Hand-waving” means the compiler thinks this is correct, but has no real way to prove it. And heuristics simply means that optimizations that have been known to work in prior code are used when similar code is found.

Constant Folding

Constant Folding is a simple example of an optimization that can be done.

This essentially mans the optimizer evaluates constant expressions up front to reduce execution time, and save stack and register space.

For example:

a = 1 + 2

can be replaced with:

a = 3

Not everything will be quite so obvious in your code, of course.

Optimization Issues

There are certain types of code that can make the optimizer’s job more difficult. These special Xojo features can challenge an optimizer:

• Exception Handling: Makes things difficult because you cannot tell where a function call may return.
• Memory Management: Xojo has deterministic object destruction when variable goes out of scope, which forces the optimizer to have to track things more closely.
• Introspection: The use of Introspection requires lots of metadata to remain available so it can be referenced at run-time.
• Threading: Cooperative thread yielding affects loops and other things.
• Xojo is a “safe” language and many of the things it does to ensure your app does not crash (and instead raise exceptions) such as Nil object checks, stack overflow checks, bounds checks, etc. all restrict what the optimizer can do.
• Plugins: Since these are pre-compiled, they are ignored by the optimizer.

Continue to learn about a specific optimization: Loop Unrolling.

With the move to LLVM as the backend of our compiler, the format of our Windows executables changed somewhat. LLVM puts the executable code in a different location that doesn’t set off those same flags for anti-virus software. If you’re having problems with such false positives, recompiling your apps for 64-bit may solve the problem. Doing this is not a 100% guarantee but it can reduce the chances of a false-positive occurring.

This is even more true if you are using console-based helper apps especially if you’re launching multiple instances of them. Despite this being a known and often-used technique for taking advantage of multiple cores (and one we wrote about recently), it can make anti-virus software more suspicious. If your helper app has code that the anti-virus software thinks is in the wrong place, recompiling it for 64-bit may help.

Having said all of this, false is still false. If your apps (compiled for 32-bit or 64-bit) are falsely identified as having a virus, contact the anti-virus software company so they can update their software. Many have established protocols for reporting false positives.

This is the fifth in our compiler series and the first on the back end. We covered the parts of the compiler that are called the front end in these posts:

• LLVM Everywhere
• Compilers 101 – Overview and Lexer
• Compilers 102 – Parser
• Compilers 103 – Semantic Analyzer
• Compilers 104 – IR Generation

Back End

The components of the back end take the IR that was generated by the last step of the front end and emit executable code, which is machine language in the case of Xojo.

To recap a bit from the LLVM post, for 32-bit x86 apps, Xojo uses its own in-house, proprietary compiler first created in 2004/2005. This powerful and fast compiler handles the front end and back end, but it does have a couple limitations: it can only target 32-bit x86 and it does not do any optimizations.

Today when you build an iOS app, a 64-bit app for Windows, MacOS or Linux, or an ARM app for Raspberry Pi you are using LLVM as the back end to generate your native, binary code.

The rest of these posts will cover the back end as it pertains to LLVM. Specifically, the components are:

• Optimizer, Loop Unrolling
• Code Generation
• Linker

This is the fourth post in our Compiler series. Other posts:

• LLVM Everywhere
• Compilers 101 – Overview and Lexer
• Compilers 102 – Parser
• Compilers 103 – Semantic Analyzer

What is IR?

After the Semantic Analyzer, the next step is to turn the trees that it validated and added type information to into a representation that is much closer to what the machine is actually going to generate. This representation is called an intermediate representation (IR). The Xojo compiler, when building for 64-bit or ARM, uses LLVM IR.

The resulting LLVM IR describes the actual control flow of the program and every single thing that will be in the final program. In addition to the user-visible code that gets executed and the implicit conversions that are now in the trees, it also needs to contain all of the hidden, behind the scenes calls like reference counting and introspection metadata.

LLVM IR is actually higher level and more abstract than the actual assembly that it’ll end up generating. For example, unlike assembly language, it’s entirely strongly typed and the Xojo compiler has to be very precise in what it generates (which is a good thing!).

IR Code Generation

To get started, here is the abstract syntax tree that was previously created by the Semantic Analyzer:



To generate IR, the compiler walks through the above tree, depth first, to get to the leaf nodes. Doing this gets us to the BinaryOperator* for the multiple on the lower right side of the tree.

The LLVM IR to multiply those two values (mul) looks like this:

%1 = mul i32 2, 4

Now it works backwards through the tree. So the next item is the implicit cast, which has to cast the value that was calculated in the previous command:

%2 = sitofp i32 %1 to double

The sitofp IR command means “Signed Integer to Floating Point”.

Continuing up the tree, the binary operator is next, so it can now grab the left hand-side value to apply to the right-hand side value. This is the IR to add the values:

%3 = fadd double 3.14, %2

The fadd IR command means “floating point add”.

And continuing up the tree, the implicit cast is next:

%4 = fptosi double %3 to i32

The fptosi IR command means “floating point to signed integer”.

Lastly, we reach the actual assignment (store) with IR that looks like this:

store i32 %4, i32* @sum

Here is the complete IR that gets generated:

%1 = mul i32 2, 4
%2 = sitofp i32 %1 to double
%3 = fadd double 3.14, %2
%4 = fptosi double %3 to i32
store i32 %4, i32* @sum

Reading through this you should now understand why no one wants to manually write code at such a low-level.

This is the last part of the compiler that is considered to be part of the front end. The rest of the compiler components belong to the back end.

• Growing? Read how one Xojo user took his app from in-house to commercial,
• Transitioning Windows Graphics: Direct2D/DirectWrite,
• Remote Debugger for Raspberry Pi and the Programming with Raspberry Pi Book,
• Check out our highly popular JSON Feed blog post series for iOS, web and Desktop,
• We updated Xojo’s Linux Desktop framework to GTK3 and HiDPI,
• Whatever happens, Xojo has your back if Mac goes ARM, and
• Jump into our ongoing Compiler blog post series: LLVM Everywhere, Compiler 101 – Overview and Lexer, and Compilers 102 – Parser.

A special mention on the topic of Net Neutrality in the US. Geoff has shared his point of view and we hope you make your voice heard to the FCC before December 14th. This is an issue that effects us all.

The Xojo community continues to grow with developers switching from VB, emerging citizen developers and small businesses all discovering what they can with Xojo. In the last 12 months the Xojo Forum has welcomed 1,688 new forum members and 60,772 forum posts.

Our blog post from back in June, Daring to Defy Software Extinction sums up Xojo and Dev Tool history with some perspective. We’re proud of what we, along with the Xojo Community, have built over the past 21 years and we look forward to 2018 – Android support, I’m looking at you!

From everyone at Xojo, thank you for your continued support. This community is truly one-of-a-kind and we look forward to all that 2018 has in store!

These will all be at a high-level. None of these posts are going to teach you how to write a compiler. The goal of these posts is for you to have a basic understanding of the components of a compiler and how they all work together to create a native app.

This is the second post in our ongoing series on compilers. I recommend that you first read Compilers 101 – Overview and Lexer before continuing.

After the Lexer has converted your source code to tokens, it sends them to the Parser. The job of the Parser is to turn these tokens into abstract syntax trees, which are representations of the source code and its meaning.

For reference, this is the simple source code we are “compiling”as we go through the parts of the compiler:

sum = 3.14 + 2 * 4

The lexer has converted this to a stream of tokens which are now sent to the Parser to process. The tokens are:

1. Type: identifier
   1. value: sum
   2. start: 0
   3. length: 3
2. Type: equals or assigns
   1. value: n/a
   2. start: 4
   3. length: 1
3. Type: double
   1.  value: 3.14
   2.  start: 6
   3. length: 4
4. Type: plus
   1. value: n/a
   2. start: 11
   3. length: 1
5. Type: integer
   1. value: 2
   2. start: 15
   3. length: 1
6. Type: multiply
   1. value: n/a
   2. start: 15
   3. length: 1
7. Type: integer
   1. value: 4
   2. start: 17
   3. length: 1

Parser

To see how this works, we’ll go through the tokens and create the syntax tree.

The first token is the identifier, which the parser knows is actually a variable. So it becomes the first node of the tree:



The next token is equals or assigns. The parser knows things about this such as that it is an assignment and that assignment is a binary operator that has two operands, one on the left and one on the right. The variable from above is the left value, so it gets moved to the left side of the Assignment node that is now added to the tree to look like this:



Continuing, the double token is next with value 3.14. This is the right value for the assignment:



Moving along, the plus token is next. The parser knows this is the addition operator (BinaryOperator+) that takes two values (and is also left associative). This means that the addition is added to the tree with the double as its left value:



After the plus token, an integer is next and this becomes the right value for the BinaryOperator+ node:



Next is the multiply token, another binary operator that is left associative. So it gets the integer as its left value:



The last token is another integer which becomes the right value for the multiplication:

And that is the final abstract syntax tree for our simple line of code. The Parser has done its work and has now created a tree that no longer represents the exact source code but is an idealized representation of what the user wrote.

This tree is then provided to the next component, the Semantic Analyzer.

These will all be at a high-level. None of these posts are going to teach you how to write a compiler. The goal of these posts is for you to have a basic understanding of the components of a compiler and how they all work together to create a native app.

Compiler Components

A compiler is a complicated thing and consists of many components. In general the compiler is divided into two major parts: the front end and the back end. In turn, those two parts have their own components.

For the purposes of these posts, this is how we will be covering the components of the compiler:

Front End

The front end is responsible for taking the source code and converting it to a format that the back end can then use to generate binary code that can run on the target CPU architecture. The front end has these components:

• Lexer
• Parser
• Semantic Analyzer
• IR (intermediate representation) Generator

Back End

The back end takes the IR, optionally optimizes it and then generates a binary (machine code) file that can be run on the target CPU architecture. These are the components of the back end:

• Optimizer
• Code Generation
• Linker

Each of these steps processes things to get it a little further along for the next step to handle.

The linker is not technically part of the compiler but is often considered part of the compile process.

Lexer

The lexer turns source code into a stream of tokens. This term is actually a shortened version of “lexical analysis”. A token is essentially a representation of each item in the code at a simple level.

By way of example, here is a line of source code that does a simple calculation:

sum = 3.14 + 2 * 4

To see how a lexer works, let’s walk through how it would tokenize the above calculation, scanning it from left-to-right and tracking its type, value and position in the source code (which helps with more precise reporting of errors):

1. The first token it finds is “sum”
   1. type: identifier
   2. value: sum
   3. start: 0
   4. length: 3
2. Token: =
   1. type: equals or assigns
   2. value: n/a
   3. start: 4
   4. length: 1
3. Token: 3.14
   1. type: double
   2.  value: 3.14
   3.  start: 6
   4. length: 4
4. Token: +
   1. type: plus
   2. value: n/a
   3. start: 11
   4. length: 1
5. Token: 2
   1. type: integer
   2. value: 2
   3. start: 15
   4. length: 1
6. Token: *
   1. type: multiply
   2. value: n/a
   3. start: 15
   4. length: 1
7. Token: 4
   1. type: integer
   2. value: 4
   3. start: 17
   4. length: 1

As you can see, white space and comments are ignored. So after processing that single line of code there are 7 tokens that are handed off to the next part of the compiler, which is the Parser. The Parser is covered in the next post. Stay tuned!

What is LLVM?

On a high-level, LLVM is a collection of libraries and tools for building compilers. The LLVM project was started in the early 2000s by Chris Lattner (who eventually went to work at Apple and has now moved on to Tesla) and remains in active development. Because LLVM is a toolkit for building compilers and because it can target most CPU architectures, its use has become much more prominent in recent years. It has widespread industry backing with support from major companies including AMD, Apple, ARM, IBM, Intel, Google, Mozilla, Nvidia, Qualcomm, Sony, Samsung.

The first appearance of LLVM in Xojo was when we started using it to compile and run XojoScript code (2010). Later we used LLVM to build iOS apps (2014), 64-bit apps for x86 (Windows, MacOS, Linux) and 32-bit apps for Raspberry Pi (2015), and most recently we’ve hooked up the Xojo debugger so it works with apps built using LLVM (2016).

In addition to now being used as part of Xojo’s compiler, LLVM is also used with other languages, including: Clang, D, Rust, OpenCL, and Swift.

Why is Xojo using LLVM?

First, a little background. A compiler consists of many things and is typically split into parts called the “front end” and the “back end”. LLVM has components for both front ends and back ends; Xojo uses it as a back end.

For 32-bit x86 apps, Xojo uses its own in-house, proprietary compiler first created in 2004/2005. This powerful and fast compiler handles the front end and back end, but it does have a couple limitations: it can only target 32-bit x86 and it does not do any optimizations.

But technology marches on and we knew we would eventually have to add support for x86-64 (64-bit) and ARM CPU architectures. Updating a compiler is a large undertaking, but fortunately the LLVM compiler toolkit started gaining traction in the industry and became a better alternative to creating our own x86-64 and ARM compiler back ends.

Today when you build an iOS app, a 64-bit app for Windows, MacOS or Linux, or an ARM app for Raspberry Pi you are using LLVM as the back end to generate your native, binary code.

By using LLVM, we are able to respond more quickly to changes in the industry and to add features our users want. As an example, we were able to rapidly add Raspberry Pi support (32-bit ARM Linux) by leveraging much LLVM work that had already been done for x86-64 and ARM for iOS.

As Joe Ranieri (the Xojo compiler guru) likes to say “Every single line of code [you write] is a liability and not an asset”. With LLVM we can implement more features in less time because we don’t have to recreate the wheel, so to speak.

In effect, LLVM enables us to better support the unknown future, including new and updated architectures. One such example is 64-bit ARM Linux, which will likely become necessary at some point.

Learn More

LLVM is great. We love it and are thrilled that it has allowed us to add significant capabilities to Xojo for you. A compiler is a complicated thing and we are pleased that Xojo hides the complexity of compiler technology so that you don’t have to worry about it. You just need to focus on making the best app you can, select your OS target, click build and let Xojo take care of the rest.

If this post has made you curious about LLVM and you’d like to learn more, I recommend the following:

• Wikipedia: LLVM
• LLVM official site
• Accidental Tech Podcast: Interview with Chris Lattner, creator of LLVM
• Joe Ranieri’s Compiler Session from XDC 2016

More on our Compiler Series: Compilers 101 – Overview and Lexer

Download a PDF of the full Compiler series: LLVM Everywhere

So what if they did? Say next year at WWDC Apple announced that they were planning to move to ARM-based Macs. How would that affect you as a Xojo developer? As it turns out, not much because Xojo abstracts and shields you from those sorts of platform changes. For example, since 2003 our compiler has been a modern, two-pass compiler. The first pass converts Xojo code into a sort of meta-assembly code. The second pass does a nearly straight translation from this meta-assembly code to the machine code for the processor being targeted (x86 for example or ARM for iPhone and Raspberry Pi). Had Apple made this change years ago, it would have required us to spend the time to create a new backend for ARM. However, as you may know, we have been transitioning the backend of our compiler to the open source LLVM compiler, the same one that Apple provides with Xcode. That’s how we support ARM (and 64 bit) today. Should Apple announce they are switching to their own ARM-based processors for future Macs, we could relatively easily recompile the Xojo desktop frameworks for ARM and provide that as a new build option. It would not be a significant amount of work for us and really no work for you at all except recompiling your projects.

This is true for other platforms as well. Incidentally, we have already been through this before. Xojo originally supported both the 68000 and PowerPC processors. When Apple switched to the x86, we switched too and Xojo users had little to do but recompile their projects.

This is part of the value you get from Xojo: be mostly insulated from these kinds of changes.

The best-laid plans of mice and men oft go astray…

As Burns so eloquently stated, no matter how carefully you plan sometimes things just don’t work out. Anyone who has done software development for long knows this all too well.

While Xojo already has 64-bit debugging for macOS and Linux, we had planned to include 64-bit debugging for Windows in 2017 Release 2 which will be shipping next month. As you may know, we rely on the open source LLVM compiler and toolchain for our 64-bit support. This provides huge advantages for us and you with features like 64-bit, ARM and performance optimizing, all with a lot less work compared to providing the entire compiler toolchain ourselves. The downside is that we are now dependent upon the LLVM project. While the LLVM team has been making fast progress, Windows debugging is not quite ready. We are confident it will be ready soon but there’s so much great stuff in Xojo 2017r2, we don’t want to delay it any longer.

If you have an active Xojo Pro license, you can test all the great new stuff coming in 2017r2 now (64-bit XojoScript, Windows Resource Compiler, and more). If you don’t have Xojo Pro but would still like to contribute to testing Xojo releases before they ship, go here to find out more.

As you may know, Xojo’s compiler takes the code you write and translates it into a sort of meta-assembly language. Think of it as assembly code that is not specific to any particular processor. This part of the compiler is called the Front End. The Back End of the compiler takes that meta-assembly code and translates it into actual machine code for a particular processor such as x86 or ARM. We have been moving Xojo from our own compiler Back End to using an open source one known as LLVM which is used by Apple and others as well. It’s how we are building for 64-bit and it optimizes your code for speed, something our old compiler Back End did not do.

We depend on LLVM to provide us with the data we need to make debugging work. LLVM version 3.7 had the necessary support for macOS and Linux. LLVM version 4 has added this for Windows but it was released only a few weeks ago, not enough time for us to get it working for today’s release of Xojo 2017 Release 1. Although you don’t directly see LLVM when you use Xojo, it’s doing significant and important work. Switching from one major release of LLVM to another affects far more than just debugging so it must be done very early in our development of a release of Xojo. It’s likely that 64-bit debugging support for Windows will be available in Xojo 2017 Release 2.

64-bit support in Xojo may seem like a minor feature. After all, for most of you, switching from 32 to 64-bit is a single-click operation. However, for it to be that simple has required a huge amount of effort on our part. While you can still get by with 32-bit apps in most cases today, that won’t be true in the not-too-distant future. That’s why it’s critical we make it easy for you to switch. The importance of Xojo supporting 64-bit really can’t be overstated.

Remember that many features in Xojo take multiple release cycles to complete. That means that when the feature list is short, there’s working going on for future releases. When it’s long, much of that work may have been done during previous release cycles. It’s a curious fact of software development that sometimes features that seem simple on the outside are actually large and complex on the inside.

There’s a lot more coming for Xojo in 2017 so stay tuned.