Continuous: C# and F# IDE for the iPad by Frank A. Krueger


Continuous gives you the power of a traditional desktop .NET IDE - full C# 6 and F# 4 language support with semantic highlighting and code completion - while also featuring live code execution so you don’t have to wait around for code to compile and run. Continuous works completely offline so you get super fast compiles and your code is secure.

Continuous gives you access to all of .NET’s standard library, F#’s core library, all of Xamarin’s iOS binding, and Xamarin.Forms. Access to all of these libraries means you won’t be constrained by Continuous - you can write code exactly as you’re used to.

Real Work, on the iPad

I love the iPad but was still stuck having to lug around my laptop if I ever wanted to do “real work”. Real work, in my world, means programming. There are indeed other IDEs for the iPad: there is the powerful Pythonista app and the brilliant Codea app. But neither of those apps was able to help me in my job: writing iOS apps in C# and F#. I couldn’t use my favorite languages on my favorite device and that unfortunately relegated my iPad to a play thing.

Well it took me a bit of time, but I finally have it: a .NET IDE on the iPad (and phone too!).

But it’s not “just an IDE”. I didn’t want it to simply be sufficient - I wanted it to be great. I also thought it was a nice time to push the state of the art in .NET IDEs a tad.

For ages compiled languages like C# and F# have forced a sequential development loop on programmers: the Code-Compile-Run-Test loop. We code something up, wait for it to compile, then wait for it to deploy and run, then we get to test it.

I hate waiting for compilation and deployment so I designed Continuous to minimize those steps. It does this by eagerly compiling your code - never waiting for you to tell it when to start. It runs your code as soon as those compiles complete successfully and displays the results of that execution right next to your code. Now you can focus on the code and the results of that code instead of being distracted by all the silly machinery of a compiler and IDE.

The benefits of making compilation and execution fast have surprised me. My iPad has become my favorite place to write apps now.

  • The UI is visualized right next to the code that is building it.
  • I am no longer constrained by designers with their static view of the world - the UI objects in Continuous are live and interactive.
  • I can use real code files but still visualize objects out of them as if they were scripts.
  • I can focus on building one screen of my app at a time and see the results without having to navigate from the first screen to see the screen I’m working on over and over.

I could argue that I’m a more efficient programmer thanks to these changes. Perhaps I am more productive. But the truth is, I’m just happier using Continuous. I play with GUIs more now, trying new ideas and tweaking things left and right. It’s quite liberating and plain old fun to get nearly instant feedback on your work.

I hope you find these features as exciting as I do. Please visit the website if you want more details on them, or throw caution to the wind and buy Continuous on the App Store now to see them first-hand.

Standing on the shoulders of giants

Continuous wouldn’t be possible if it wasn’t for .NET’s great open source ecosystem. Continuous uses Roslyn for compiling C# and FSharp.Compiler.Service for compiling F#. Continuous also relies heavily on Cecil (what problem can’t be solved with Cecil?) Also, Xamarin.Forms could only be included thanks to Xamarin open sourcing it.

And of course, none of this would be possible without mono and Xamarin.


I wrote Continuous in F# using Xamarin Studio. The code is more functional than object oriented and uses a redux style architecture. I don’t think I could have built such a large app with its sophisticated requirements without F# at my side. Three years ago I wasn’t sure how to write GUI apps in a functional language, now I question why I haven’t always done things this way.

C# 7 Features Previewed

Over the last year we've shown you various features that were being considered for C# 7. With the preview of Visual Studio 15, Microsoft has decided to demonstrate the features to make it into the final release of C# 7.

Tuple Value Types

.NET has a tuple type, but in the context of C# there are a lot of problems. Being a reference type, you probably want to avoid using it in performance sensitive code as you have to pay for GC costs. And as they are immutable, while making it safer for sharing across threads, making any changes requires allocating a new object.

C# 7 will address this by offering a tuple as a value type. This will be a mutable type, making it more efficient when performance is essential. And as a value type, it makes a copy on assignment so there is little risk of threading issues.

To create a tuple, you can use this syntax:

var result = (5, 20);

Optionally, you can name the values. This isn't necessary, it just makes the code more readable.

var result = (count: 5, sum: 20);

Multi-value Returns

Returning two values from one function has always been a pain in C-style languages. You have to either wrap the results in some sort of structure or use output parameters. Like many functional languages, C# 7 will do the first option for you:

(int, int) Tally (IEnumerable<int> list)

Here we see the basic problem with using generic tuples: there is no way to know what each field is for. So C# is offering a compiler trick to name the results:

(int Count, int Sum) Tally (IEnumerable<int> list)

We'd like to stress that C# isn't generating a new anonymous type. You are still getting back a tuple, but the compiler is pretending its properties are Count and Sum instead of Item1 and Item2. Thus these lines of code are equivalent:

var result = Tally(list);

Note that we do not yet have a syntax for multi-assignment. Presumably when it happens, it will look something like this:

(count, sum) = Tally(list);

Beyond simple utility functions such as this, multi-value returns will be useful for writing asynchronous code, as async functions aren't allowed to use out parameters.

Pattern Matching: Enhanced Switch Blocks

One of the long standing complaints of VB and functional programmers alike is that C#'s switch statement is extremely limited. VB developers want ranges, while those who used to F# or Haskell want decomposition-style pattern matching. C# 7 intends to offer both.

When pattern matching on types, you can create variables to hold the result of the cast. For example, when using a switch on a System.Object you could write:

case int x:

If the object is an integer, the variable x will be populated. Otherwise it will check the next case block in a top to bottom fashion. If you want to be more specific, you can use range checks:

case int x when x > 0:
case int y:

In this example, if the object is a positive integer the x block will be executed. If the object is zero or a negative integer, the y block will be executed.

If you want to check for null, simply use this syntax:

case null;

Pattern Matching: Decomposition

So far we've just seen an incremental improvement over what is available in VB. The real power of pattern matching comes from decomposition, where you can tear apart an object. Consider this syntax:

if (person is Professor {Subject is var s, FirstName is "Scott"})

This does two things:

  1. It creates a local variable named s with the value of
  2. It performs the equality check
    ((Professor)person).FirstName == "Scott"

Translated into C# 6 code:

var temp = person as Professor;
if (temp != null && temp.FirstName == "Scott")
   var s = temp.Subject

Presumably we'll be able to combine enhanced switch blocks in the final release.

Ref Returns

Passing large structures by reference can be significantly faster than passing them by value, as the latter requires copying the whole structure. Likewise, returning a large structure by reference can be faster.

In languages such as C, you return a structure by reference using a pointer. This brings in the usual problems with pointers such as pointing to a piece of memory after it has been recycled for another purpose.

C# avoids this problem by using a reference, which is essentially a pointer with rules. The most important rule is that you can't return a reference to a local variable. If you tried, that variable would be on a portion of the stack that is no longer valid as soon as the function returns.

In the demonstration, they instead returned a reference to a structure inside an array. Since it is effectively a pointer to an element in the array, the array itself can be modified. For example:

var x = ref FirstElement(myArray)
x = 5; //MyArray[0] now equals 5

The use case for this is highly performance sensitive code. You wouldn't use it in most applications.

Binary Literals

A minor feature is the addition of binary literals. The syntax is simple prefix, for example 5 would be "0b0101". The main use cases for this would be setting up flag based enumerations and creating bitmasks for working with C-style interop.

Local Functions

Local functions are functions that you define inside another function. At first glance, local functions look like a slightly nicer syntax for anonymous functions. But they have some advantages.

  • First, they don't require you to allocate a delegate to hold them. Not only does this reduce memory pressure, it also allows the function to be in-lined by the compiler.
  • Secondly, they don't require you to allocate an object when creating a closure. Instead it just has access to the local variables. Again, this improves performance by reducing GC pressure.

Presumably the second rule means that you can't create a delegate that points to a local function. Still, this offers organizational benefits over creating separate private functions to which you pass the current function's state as explicit parameters.

Partial Class Enhancements

The final feature demonstrated was a new way to handle partial classes. In the past, partial classes were based around the concept of code-generation first. The generated code would include a set of partial methods that the developer could implement as needed to refine behavior.

With the new "replace" syntax, you can go the other way. The developer writes code in a straight forward fashion first and then the code generator comes in and rewrites it. Here is a simple example of what the developer may write,

public string FirstName {get; set;}

Simple, clean, and completely wrong for a XAML style application. So here's what the code generator will produce:

private string m_FirstName;
static readonly PropertyChangedEventArgs s_FirstName_EventArgs 
                   = new PropertyChangedEventArgs("FirstName")

replace public string FirstName {
   get {
      return m_FirstName;
   set {
      if (m_FirstName == value)
      m_FirstName = value;
      PropertyChanged?.Invoke(this, m_FirstName_EventArg);

By using the "replace" keyword, the generated code can literally replace the hand-written code with the missing functionality. In this example, we can even handle the tedious parts that developers often skip such as caching EventArgs objects.

While the canonical example is property change notifications, this technique could be used for many "Aspect Oriented Programming" scenarios such as injecting logging, security checks, parameter validation, and other tedious boilerplate code.

Why Visual Studio Code?

Visual Studio Code provides developers with a new choice of developer tool that combines the simplicity and streamlined experience of a code editor with the best of what developers need for their core code-edit-debug cycle. Visual Studio Code is the first code editor, and first cross-platform development tool - supporting OSX, Linux, and Windows - in the Visual Studio family.

At its heart, Visual Studio Code features a powerful, fast code editor great for day-to-day use. The Preview release of Code already has many of the features developers need in a code and text editor, including navigation, keyboard support with customizable bindings, syntax highlighting, bracket matching, auto indentation, and snippets, with support for dozens of languages.

For serious coding, developers often need to work with code as more than just text. Visual Studio Code includes built-in support for always-on IntelliSense code completion, richer semantic code understanding and navigation, and code refactoring. In the Preview, Code includes enriched built-in support for ASP.NET 5 development with C#, and Node.js development with TypeScript and JavaScript, powered by the same underlying technologies that drive Visual Studio. Code includes great tooling for web technologies such as HTML, CSS, LESS, SASS, and JSON. Code also integrates with package managers and repositories, and builds and other common tasks to make everyday workflows faster. And Code understands Git, and delivers great Git workflows and source diffs integrated with the editor.

But developers don't spend all their time just writing code: they go back and forth between coding and debugging. Debugging is the most popular feature in Visual Studio, and often the one feature from an IDE that developers want in a leaner coding experience. Visual Studio Code includes a streamlined, integrated debugging experience, with support for Node.js debugging in the Preview, and more to come later.

Architecturally, Visual Studio Code combines the best of web, native, and language-specific technologies. Using the GitHub Electron Shell, Code combines web technologies such as JavaScript and Node.js with the speed and flexibility of native apps. Code uses a newer, faster version of the same industrial-strength HTML-based editor that has powered the “Monaco” cloud editor, Internet Explorer's F12 Tools, and other projects. And Code uses a tools service architecture that enables it to use many of the same technologies that power Visual Studio, including Roslyn for .NET, TypeScript, the Visual Studio debugging engine, and more. In future previews, as we continue to evolve and refine this architecture, Visual Studio Code will include a public extensibility model that lets developers build and use plug-ins, and richly customize their edit-build-debug experience.

We are, of course, still very early with Visual Studio Code. If you prefer a code editor-centric development tool, or are building cross-platform web and cloud applications, we invite you to try out the Visual Studio Code Preview, and let us know what you think!

Next Steps

Read on to find out about:

  • Code Basics - a quick orientation of VSCode
  • Editing Evolved - from code colorization & multi-cursor to IntelliSense
  • Debugging - OK time for the really fun stuff - break, step, watch

The Rise of Mobile C#

Microsoft have been struggling to get traction with their mobile computing efforts, with Windows Phone stuck at around 3% share of the smartphone market. Windows 8 is doing a little better in the tablet market but is still a distant third to iOS and Android. Despite losing in the platform wars, Microsoft’s developer ecosystem is still strong and they’re not showing much sign of wanting to give up their tools. The latest Developer Economics survey showed that 38% of mobile developers were using C# for some of their work and 16% use it as their main language. Those developers are not all focused on Microsoft platforms by a long way. They’re not all building games with Unity either. So what are they doing?

Not just Windows Phone, particularly not for pros

Whilst 30% of all developers in the survey were targeting Windows Phone, that doesn’t quite account for the majority of those whose main language is C#. Also, more than half of the developers targeting Windows Phone are Hobbyists and Explorers – i.e. those not working on mobile apps full time. If we focus on full time professional mobile developers, as we will for the rest of this article, then just 50% of those that use C# as their main language are primarily targeting Microsoft platforms. Apple’s iOS (with 23% of developers) and Google’s Android (14%) are in fact more popular targets than Windows 8 (10%). So, how do developers use C# on other platforms? With cross-platform tools, particularly Unity and Xamarin.

A flexible cross-platform approach

A lot of popular cross-platform tools for mobile development only support iOS and Android. As such, for those also wanting support for Windows Phone and possibly desktop Windows and Mac too, Xamarin is one of very few serious options. That said, it’s not just a default choice. Using Xamarin.Forms, developers can get the write-once-run-anywhere efficiency that drives many decisions to use a cross-platform approach. The downside to this approach is that it can give a lowest common denominator of functionality; not allowing developers to really optimise for the unique features of each platform. However, Xamarin also directly wraps the native platform APIs, allowing developers to call anything in the native SDKs. They can even automatically create bindings for popular third party libraries on each platform. The other key reason developers often go with a native rather than cross-platform approach is performance. However, a recent independent performance test (by an early Google engineer) showed Xamarin’s compiler produces raw performance that’s comparable to native on iOS and Android. Raw performance isn’t the only thing that counts of course – a garbage collection pause causing a stutter in your animation is jarring, however fast the the code is executing otherwise. Enterprises customers will usually put up with mild inconveniences of that nature to get the cost savings and maintenance benefits of a single code base across platforms though.

Better revenues

Possibly the best measure of the success of C# on mobile devices is the revenues of the developers using it. Whether you believe the same level of smoothness in the user experience can be achieved or not, it only matters if it costs users and revenue. Here there is no room for debate. The revenues of full time professional developers whose main language is C# are comparable to, or better than, those of other developers targeting the same primary platform with the native language. For example, the revenue distribution for C# developers on iOS is extremely similar to that for Objective-C developers and the average revenues are higher. This is both because there are more C# developers earning more than $10K (46% vs 36%) per month and while there are slightly fewer earning more than $100K per month (16% vs 17%), a significantly greater fraction of those using C# earn more than $500K per month (14% vs 6%).

This is not to suggest that C# is somehow a better language for targeting iOS than Objective-C. This is correlation and not causation. The cause of the better revenues is that the C# developers are much more likely to be targeting enterprises than the Objective-C developers and that’s where the higher revenues are most likely to be found. There’s an enormous pool of developers trained in C# and related Microsoft technologies. A lot of them are working on desktop enterprise apps or the server side. As it becomes increasingly clear that C# is a viable language for successfully delivering cross-platform mobile solutions, C#’s rise on mobile looks set to continue for several years yet.