The panelists talk about Xamarin with Frank Krueger.

 

Hey everybody and welcome to episode 81 of the iPhreaks Show. This week on our panel we have Jaim Zuber.

Hello from Minneapolis.

Alondo Brewington.

Hello from North Carolina.

Andrew Madsen.

Hello from Salt Lake City.

I’m Charles Max Wood from DevChat.tv. I just want to give you a quick reminder that I’m organizing a JavaScript conference. It’s a remote conference. I know that that’s not the focus of this show so that’s all I’m going to say. Go check it out as jsremoteconf.com. We also have a special guest this week, and that is Frank Krueger.

Howdy. Howdy from Seattle, I should say.

You want to introduce yourself really quickly?

Sure. Hi. My name is Frank Krueger. I’m @praeclarum on Twitter. I’ve been an iOS developer since about 2000—ever since they’ve let us start developing iOS apps. And I’ve been a .NET programmer for even longer than that; just your old programmer type, doing mobile development now for the last however many years.

You don’t sound that old.

Ah, I’m trying. I’m trying, I’m trying. [chuckling]

So we rushed you on today to talk about Xamarin.

Yeah, I love Xamarin.

Do you want to give us a brief overview for those who don’t know what it is?

Oh, okay. Well, it’s a lot of things. It’s a runtime and it’s a set of programming languages that you can use to write apps for Android, iOS, Mac. It’s based on .NET. It’s based on actually the Mono Framework, the open source version of .NET, which has its roots in Linux. But they expanded to including iOS and Mac. So we have an awesome runtime that comes with it, and then there’s a whole IDE for writing code in a language code, C#, and another language called F#. Back in the day you could also do some Visual Basic but I don’t think that’s really officially supported anymore. But basically you can use all these awesome .NET languages, basically the .NET runtime, to write apps for all these platforms that you didn’t expect that .NET ran on. That’s Xamarin.

So I have to ask. You mention that it’s based on Mono, which is the open source version of .NET. Aren’t they open sourcing .NET?

Yeah. It’s weird, huh? [chuckling]

So does that change the conversation at all around Xamarin, or do we know yet?

It’s hard to predict the future and all, but my gut feel is that it actually doesn’t change too much. Since Mono was already a pretty complete implementation of .NET, and, in fact, kind of a better one since it worked on multiple platforms from the get-go—it was never tied to Windows or anything like that—so it’s really awesome. I’m super excited that Microsoft’s open sourcing .NET, in fact, all the library source code and all that. In fact, what’s going to happen is that source code’s going to come into Mono to improve Mono. But we’re all going to pretty much keep using Mono since it’s still not quite clear how to compile .NET apps for iOS or Mac without using Xamarin, or Mono, or anything like that. I guess we really don’t know the future, but it’s kind of exciting either way.

So, one of the big benefits that’s touted for Xamarin is that it’s cross platform. You can develop an app for iOS and Android and you’ll have code sharing. There are different approaches to these cross-platform frameworks. One would be like an HTML-based where you can reuse your HTML skills, like at PhoneGap. There’s other least-common-denominator things where you abstract things like buttons and lists and do your cross-platforms that way, like Titanium. How does Xamarin fit in? What is their philosophy?

Well there are actually two answers to that. There are two philosophies, in fact. The first philosophy is probably the most important one, is that Xamarin is built for writing native apps. So when it comes to writing a UI for an application, you use the native framework. So on iOS you use Cocoa Touch, on Mac you use Cocoa, Android you use Android—I don’t know what it’s called. Android [chuckles]. The premise is that the majority of your app is actually the logic. It’s talking to web services, it’s saving data, it’s running algorithms – it’s doing stuff. That core part of your application is the part that gets shared between all the platforms.

But when you go to each platform you then write a custom UI for that platform. That is kind of what you want to do. This actually comes from the experience of the Mono team. Whenever they were trying to import an app from say Linux to Mac OS—you know that style of app; they look Linux-y or look wrong when they run on OSX. So they learned quickly that you really do want to write custom UIs for the platform to fit that platform.

That said, we were all trying to push the Linux back in the day of how much code could we reuse between the platforms. People would come out with abstractions that you try to aggregate; try to take a greatest common denominator between the platforms and do that kind of work. That’s pushing towards that PhoneGap HTML solution of write one app, run it everywhere, user interface be damned. It’s fine.

That’s called write one, suck everywhere.

Yeah. Yeah. I learned that lesson with Java. I think we all just buried our head and said, “Fine we’re going to write a nice UI for each platform. That’s just better for users.” But it’s just so tempting from a programmer’s perspective to reuse 100% of your code between platforms.

So to that end, Xamarin actually has a solution to that. It’s called Xamarin.Forms, and you can pretty much write 99% of your application in a cross-platform style. Xamarin.Forms is a little better than the HTML approach because it at least tries to adopt native UIs, so you program at a high level. You just say, “Generally there’s a list view here, and it has some buttons.” But then the framework kicks in and replaces all that with native UI controls.

So they’re trying to blend the two worlds and it’s pretty successful. But in the end, if you want a good native experience, you rewrite the UI. That’s the approach.

Okay, so it sounds like there’s two basic approaches. One: you write each UI by itself – so in iOS, you’re creating the nibs. Would you do a storyboard in Xamarin?

Oh yeah, absolutely.

Okay.

In fact they have a nice storyboard editor. I think it’s better than Xcode’s.

Okay. Which isn’t that hard [chuckling]. So you have your custom UIs. That’s why I don’t think I’d put Xamarin in a cross platform solution the same way because you’re doing UI both ways. You don’t have the drawbacks from a lot of the hybrid approaches. But the newer approach that you’re talking about is Xamarin.Forms where you have one [crosstalk 08:13]

Yeah, one code base to rule them all. Yeah.

Yeah.

It’s finding a lot of popularity with internal apps for businesses. It’s like the old Ruby scaffolded websites. You just define your database and it gives you a UI. It’s a good place to start. The neat thing about it is you can gradually pull in platform features into these apps. So you can start with 100% cross platform app and then finely tune it on each platform to customize it. It’s just a different attack factor for creating your UI.

Now, with the separate UIs, do you have a folder for iOS UIs, and a folder for Android UIs, and a folder for Xamarin Form UIs, or –?

Yeah. In .NET nomenclature you have a solution and it has multiple projects. Then you have one project for each platform. You usually have one or more projects that are your shared code.

Should we translate solution?

Workspace?

Workspace, okay, that’s good.

Then projects would be targets. Targets in Xcode are projects. Whereas in Xcode you have one big hunk of source files and then you have multiple targets, in .NET the project has its own source code and they reference each other. It just makes compiling faster and it makes your code more modular and that kind of stuff.

So does it just statically compile it with LLVM?

Yeah. It’s pretty neat. It does a first pass when it compiles from the source language to .NET’s internal byte code. Then there is a second compilation step which was called the just-in-time compiler—but obviously it’s not just-in-time anymore; it’s at compile time. So they take this .NET byte code and convert it to LLVM byte code, and then shove that through LLVM and get all the great optimizations it does, and it’s out on iOS binary. It’s pretty smooth.

The question I have is, I realize that no Xamarin programmer wants to write in Objective-C. Is there any way to link in—the reason I thought of this is that there are a lot of libraries out there. Is it possible to link in platforms from specific libraries or write, for example, Objective-C code for some platform-specific piece of UI that you’re doing? Or is there no way to interoperate between those two?

It’s 100% interoperation. The whole system is a binding to Cocoa and all the other frameworks, right? So you have that binding system. What Xamarin did was provide the tool that they used to create those bindings so that you can bind to any other Objective-C library. So I can hop onto GitHub, pull down anyone’s Objective-C, and just add it to my project. It becomes a C++ project in my solution, and then I can reference it. I have to run this little binding tool on it to go translate from Objective-C names to C# names. You know, we like to capitalize the first letter of words and stuff like that.

But the whole system is designed for easy binding and all that. So you absolutely can do that, and we do it all the time. Especially if a company like Dropbox has an SDK that is Objective-C—it’s a bad example because they have a .NET SDK also—but any of these big companies, you can just take their library and shove it into your project. No big deal.

Cool. I’m not a .NET programmer and I don’t really know C#, but I’ve seen other languages that are a bridge to Objective-C, like there’s a Python bridge and whatever. How is this syntax for calling into Objective-C? Is it pretty easy to deal with or is it kind of gross?

Oh no, I love it. So it’s 100% into the language. Using Objective-C classes feels like using any other .NET class. They’ve done an excellent job with the binding. This is actually due to the power of .NET. .NET, when it first came out, was on Windows and specifically designed to help you write UIs on Windows. But the Windows UI layer was all native code and all that kind of stuff. So even from the beginning, .NET has had to wrap native libraries and integrate them into the language very nicely.

This is actually a very strong point of .NET and C#, that they can do this, and so that binding is very tight. I even have an anecdote. I did iOS programming in Objective-C—well actually ObjectiveC++--and Xcode for probably a year or two before I did C# and Xamarin. I like to say that I really didn’t know the Cocoa API until I had the great IntelliSense and code completion that you have to explore APIs, and see how they actually work, and see how they really reference each other. All that was from the binding to it, so I think it’s a lovely binding.

One thing I’m wondering about is—you know you’re talking about exploration tools—are you using Visual Studio to write this or is it a different IDE you use to write Xamarin apps?

You can write Xamarin apps in Visual Studio, but I’m a Mac user. I like my OSX. So I use Xamarin’s IDE that they built. It’s a customized version of an open source IDE, and it’s pretty fantastic. It’s called Xamarin Studio. It just comes when you buy Xamarin; it’s their IDE. So I run Xamarin Studio instead of Xcode on a Mac and do all my coding there. It can work with the simulator and all that kind of stuff, so there’s no need to run Xcode.

So is Xamarin targeted specifically to people who want to do cross platform development? Or it’s specifically to C# developers who are interested in mobile development?

This has changed a tiny bit over time because the iOS product from Xamarin was their original, and first, and only product for quite some time. So the story there was basically, here’s a more powerful programming environment to write iOS apps. This is for people who appreciate these kinds of environments and appreciate iOS, and mobile, and all of that stuff, and just want the two to be working together.

Nowadays, it was just a giant pink and green elephant in the room that’s roaring [chuckles]—well if it works on Windows and it works on iOS, that’s two of three or four platforms that exist in the world. Let’s just do the other ones too. So the value proposition is two-fold. It’s the powerful platform and it’s the cross-platform.

Well then there’s also the sense of familiarity if you are a .NET developer already.

Oh, absolutely.

I know there’s a lot of appeal to the other communities that I talked to for things like the Ionic or Famo.us frameworks in JavaScript or the RubyMotion framework in Ruby. Of course, RubyMotion works a lot more like Xamarin where it statically compiles with LLVM to the iOS runtime where the others are more WebView and optimized stuff so it feels less unnatural on the device.

Yeah, absolutely. You say familiarity, and I almost want to replace that for adoration and love. It’s not just we’re familiar with these libraries; these are good libraries. This is a very well-designed tool set that gives you a lot of things.

On top of that, it’s an older tool set so we have a lot of libraries for it already. In the early days of iOS, I don’t think there were built-in regex things and even XML was a little weird, but we had very powerful libraries for doing basically network communications. .NET got its name for some reason; it was very good at serialization and talking to networks and all that kind of stuff. We just had these really powerful libraries that we can take along with us, too.

Are you talking about the internal .NET libraries or third-party libraries too?

The BCL itself, that’s the Base Class Library, that’s all your collections. It’s basically Foundation in the OSX world; it’s all your basics. That’s just a really nice library onto itself; it’s pretty big and includes a lot of things.

And then there’s ten years of both first party libraries, things that Microsoft has added to it and also third party. We have libraries for pretty much everything at this point.

Can I just say that XML support in iOS is still kind of lame?

Is it? I haven’t looked in a while.

Yeah, there's NSXMLParser, but it’s sort of this event-driven parser.

But with Swift, you can finally create a good API for it. You have a powerful-enough language that you could do something better now.

Yeah, but even OSX has better XML support than iOS.

Oh, is that right?

And did before iOS came out. I don’t really understand why they didn’t bring all of that over, but we do have lots of libraries now, so I guess that’s okay.

Yeah, who uses XML anymore, right?

Yeah, right [chuckling].

One thing that I’ve noticed, because I’ve played with RubyMotion; I haven’t played with Xamarin, but they had to tweak the language a little bit because there were capabilities in the Ruby programming language that really weren’t supported in iOS. Do you see the same kind of thing with Xamarin?

Yeah. Historically, there have been those problems, specifically around generics in the very, very early days. Our generics are very similar to Swift’s generics, so hopefully you’re familiar with those. They worked, but Xamarin wasn’t willing to say they always work, and so you could use them but you really wanted to test your app to make sure everything was functioning properly.

Fortunately, a couple of years ago, they’ve really batted that down and fixed it and it’s100% good to go. But in the early days, yeah, we had those problems. Actually, I prefer using this other language called F# instead of C#; it’s just another .NET language. It’s a very powerful and sophisticated language, but unfortunately the code it generates is very sophisticated and complicated, and that code threw Xamarin for a spin for a few years until they were able to really refine it and get the runtime able to handle it on iOS. But now it’s pretty much 100% solid. Anything that you can write in .NET will run on iOS. All the languages, even.

Okay, so a number of years ago when I was first in a MonoTouch Xamarin project, we had the problem where if you’re using the link heavily in doing grouped by like it would work in the simulator, that would be fine.

That is the exact problem that I was just describing; that’s all in [inaudible 18:21].

That’s all text, so this is between just-in-time and ahead-of-time – is now not really something you need to worry about.

Nope, non-issue at all, yup.

Awesome.

Wait, I should take that back. There is one feature left in .NET that they absolutely can’t support on iOS but I wish we had. That is runtime code generation. While your app is running, it can write itself its own code and start executing it. There are a lot of people that say it’s witchcraft and you shouldn’t do that ever anyway, but there are a lot of optimization scenarios that you can perform in that case.

I have a circuit simulation app and it has a generic run loop that it does to do the physical simulation of the circuit. If I could generate code at runtime and have it compile and run itself, it could be made ten times faster than it is right now. But I can’t do that because on iOS we’re not allowed to generate and execute code. That’s not a limitation because of Xamarin; that’s a limitation Apple puts on the platform.

It’s funny that you mention that because that’s exactly the same kind of thing that they disallow in RubyMotion for the same reason.

Yeah. It’s good if used in proper hands with safety gloves and all that kind of stuff; runtime code generation is a nice feature, but I understand Apple’s reason for not wanting to do it.

But I should say, there are few other reasons that drew me to Xamarin, too. At the time, the Xcode debugger was absolutely horrendous, especially because I used that terrible mix of C++ and Objective-C, and I just couldn’t debug anything. But with Xamarin, because it’s a managed runtime, it knows everything about everything. The debugger is just gorgeous. We have interactive sessions where you can just type in code. We have beautiful breakouts of objects and following references and doing all that kind of stuff.

Definitely in the early days, I think the debugger was a pretty big part of it, and I’m pretty sure my last experience with Xcode reminds me the debugger is still a little iffy. I don’t know, maybe you guys have any opinion on that, or are you all pretty happy with the debugger over there?

26]

The debugger’s fine for Objective-C. I’m still not really that comfortable in it with Swift, but it’s super early days still, so [crosstalk 20:34] change.

Yeah, and the Swift one can only get better because there’s a lot more metadata with Swift that it can use, so hopefully that one.

Speaking of Swift, I think we actually haven’t really talked much about Swift on iPhreaks, or maybe we did while I was gone. How do you think Swift changes the landscape for Xamarin? Is Swift something that makes it less attractive, more attractive? Is there maybe some opportunity to use Swift in Xamarin projects? What do you think?

[Chuckles] I am so preventing myself from mentioning an open source project that I have right now.

Oh, just say it.

Go for it.

I’ll tag it on at the end then. Swift is exciting because at first I was like, “Oh gosh, what if they get a more powerful programming language than we did? Then I have to rethink every decision I’ve made for the last –.” Nothing like that.

Swift is an awesome language; it’s like a subset of the language that I use, F#; it’s a cute, little subset. It’s like a very version 1.0 language [laughter].

That wasn’t condescending [laughter].

I think I know what should be the tagline on the Apple site: cute, little version of F#.

But that is actually a highest compliment, because F# is the greatest language ever. It’s a great language, especially because of the pattern matching. It’s a great feature that can really reduce the size of your code and really simplify a lot of logic, so the powerful features like the discriminated unions and the pattern matching and just the fact that the ARC is built in from the beginning, you have the faintest sense of a garbage collector there. It’s a great, little language.

On one side, I was very excited because one of the tricks that we have to do in Xamarin is the binding layer where we have to call the more native APIs, and Swift makes that a lot easier because they cleaned up a lot of Objective-C APIs to make the bindings a lot simpler.

In fact, it’s kind of funny, because coding in Swift feels a lot like coding in Xamarin. A lot of names match; we all use parenthesis for function arguments now and all that.

52], at 3AM for a few nights, I started writing a Swift .NET compiler, the idea being that all the fancy, little new libraries I’m assuming everyone’s going to write them in Swift, and instead of actually binding to them, I can just compile them right into my app as native Swift things. This is in no way officially supported; this is in no way complete or anything like that, that’s why I hesitated even mentioning it, but the idea being, it’s really just exciting that there’s a new, more powerful language in Apple land. It’s just exciting [chuckling].

So you’re all Swift programmers now?

No.

I think we’re going to be, eventually.

Okay, you have to be?

Not yet.

Not yet. We actually, at my day job, have not started using it really at all. We’re just writing everything in Objective-C still, but there are various reasons for that not directly related to the language itself.

Mm-hm. I wrote a small open source library for a data center, Socrata OpenData. They have just a big data server out there on the web, and they wanted a client written in Swift. And so I wrote them a little Swift just to get my feet wet in the language, and it’s a good language. It’s a good language. It’s missing exceptions though. You still have to pass around errors like it’s 1980 or 1950, but the transition seems pretty smooth, at least, to use it

So what type of apps are you developing with Xamarin?

I’m a little bit all over the place, but my favorite apps to write are engineering and scientific apps. I’m an engineer myself – an electrical engineer by education, even though I’m mostly just a programmer – but I love the idea of creating real-world physical things and at least simulating them and doing designs. But I also think the state-of-the-art for engineering tools is quite pathetic, especially from a user interface point of view, how easy it is. A 16-year-old can pick this up and start designing things with it.

To that end, I’ve written a circuit simulation app, which is basically the app that I wish I had when I was taking Circuits 101 and had no idea what I was doing. It’s just a better UI for a circuit simulator. And then I also have a crazy, Markdown editor/symbolic math calculator/plotting crazy app called Calca, and it’s probably my favorite. It’s found a pretty good brain share with the more nerdy types out there; people who really like math or who really like engineering type of things. On top of it I

wrote a podcast player, so kind of all over the place. It’s just a programming environment; you can write whatever you want in it.

The neat thing is, iCircuit is a very high-performance application. It was released on the iPad 1.0, so back in 2010, and this was still way back in the day when everyone was saying managed code wasn’t fast enough for embedded devices. You can’t write garbage-collected apps on embedded devices – all that kind of naysay going around, so I just took a little, delightful nerdy pleasure in writing a high-performance simulation app in C# and having it run perfectly fine on slow hardware.

I know there was a reason I liked you. I was an electrical engineering major in college as well.

Me too, I guess there are a bunch of us.

Four of us! Alondo?

I changed to CS my sophomore year.

I tried for CS and the classes were just so boring [laughter].

It was the circuit lab that did it.

If you had the app, you would have stuck with it.

Exactly, I think so.

I’ll have to try iCircuit out. The state of circuit simulation tools on the Mac in particular has been pretty poor for a long, long time.

I would say there are probably two or three good ones out there, and I don’t like the user interface of any of them, even, except for mine.

Yeah. Did you release the Mac version of iCircuit later than the iOS version?

Yeah, it was probably a good year later. I still wasn’t sure if I wanted to be a Mac app developer, but it turns out I love writing for the Mac.

I’m actually also basically a Mac developer, but I’m doing some hardware right now, so a new circuit simulation tool to play with is cool.

Yeah, it was also trying to just be fun, too. It tries to tap into the centers on the iPad, so you can put an accelerometer in there or a microphone element; do something terrible, like put a microphone leading to a speaker and you’ll actually get a great time with delayed echo going on. I wanted to make it fun, too.

So with the circuit simulation, what did you use for the UI? Because I’m assuming that it has more of a custom UI and less of the databased UI.

The UI is just Cocoa, but the major UI is the graphical editor, obviously, that actually shows symbols and that kind of thing. That’s just a UIView stuck inside a UIScrollView that does its own custom drawing. It handles touch events just as you would normally handle touch events. There’s another scope element, which again is just a UIView that knows how to draw itself properly. Just all standard Cocoa stuff.

Later, when it came time to port it to other platforms, I started putting a couple little abstraction layers on top of things. My main editor doesn’t inherit from UIView directly; it inherits from something called Canvas. What I do on each platform, I just reimplement Canvas on that platform and that circuit editor goes over easy peasy.

With that technique, I get about 80-90% code reuse between the platforms, which means if I have 100,000 line app, I have to write 10,000 lines to write the UI on each platform. It’s a bit of work and requires a little bit of architectural thought, but honestly isn’t really rocket science. It’s just a bit of effort.

I guess what I was driving at a little bit was that some people come to iOS thinking, “Oh I’m going to write awesome games or something,” right? And so I guess I’m wondering, can you write games with Xamarin?

Oh, 100%! [Chuckles] In fact, the most popular Xamarin apps out there are games. All Unity games – have you guys heard of the Unity tool for writing games? That’s all mono. Basically Xamarin. It’s basically just an older version of Xamarin, and that accounts for lots of the top paid games, I should say.

So there is nothing about the runtime and the languages or anything preventing you from writing high-performance stuff. Games are easy in my world. I mean, I’m running a circuit simulator that has to do 100,000 steps/second; a game on has to do 60 – that’s pathetic. A game, you just run a little bit of logic and throw a million triangles at the renderer. Games are easy.

There are a few gotcha’s with games, like you can’t be ridiculous. I was talking to one person once who said he was allocating 20,000 objects/frame, and the garbage collector couldn’t keep up with it. And so you just say, “Well yeah, don’t give the garbage collector that much work. Use an array or something.” No big deal, but it’s funny that – the garbage collector works flawlessly 99.99% of the time except for when you do something ridiculous, like ask it to move the world.

So it’s garbage collected; it’s not referencing – I forget what the term is.

ARC?

ARC?

ARC.

No ARC. We’re a properly garbage collected world, which is so much better than a reference counted world. You don’t have to worry weak references or anything like that; it really just frees your mind. I’m a traditional; I did my first programming in Delphi with Object Pascal, then C, then C++. I spent ten years managing my own objects and I never, ever, ever want to do it again. It’s just too many little devils at the back of your head yelling at you, “Are you sure you checked this? Are you sure you checked that? Are you sure the sky is not referencing him?” The garbage collector, you just throw [inaudible 30:48] when you just start allocating objects and you don’t care. It’s much better.

It sounds like for that, the main driver is being able to have a nice functional language [inaudible 30:57] type F# that really drives a lot of what you’re doing, but that’s pretty niched for what we’re mostly doing Xamarin for, what most people are doing Xamarin with.

Even that’s hard. I just came back; Xamarin had their big conference this year – Evolve, in Atlanta – and they gave away and some Xammy awards to the winners. They all ended up being enterprise-y, big corporation apps. It’s a little bit of a selection bias too, because a big corporation can pay for the resources to have well-designed apps, a beautiful user interface and all that kind of stuff.

And a lot of Xamarin licenses too.

That kind of thing [chuckles]. These were big corporate apps, but what they did was quite diverse. One that’s really neat – augmented reality – it’s very strange. I think it was for people going out and diagnosing problems with windmills, power-generating windmills. It was this weird augmented reality app that you could visualize some data from the windmills by pointing it at the windmills; it was trippy. It was really neat. I’m into augmented reality so I loved it.

And then the other one was a game. Games are still obviously a big thing. And then another one was the weirdest thing; it was from the Tax Bureau of Denmark or Amsterdam. I don’t even remember, but it was some really public office who wanted to make it easier to pay your bills online or something, but ended up designing this really nice app for it [chuckles].

But I would say it’s definitely big with the big corporations and all that, but when I started out, it was a lot of small programmers, a lot of indie developers doing it. This sudden surge into larger corporations and then becoming notable has happened with Xamarin's growth, but from the beginning, we were just normal iOS developers and Android developers like everyone else, just a lot of independent developers who just happened to prefer this platform over using just Xcode straight up. It’s definitely matured into everyone doing everything.

I think the maturity happened along the lines where corporations are starting to use iPhone apps internally – iPad apps.

That’s probably right.

They already had an army of C# developers, like, “Oh, here we go! We don’t have to learn another language.” It’s a big driver for what a lot of people are doing with Xamarin.

Yeah, I could definitely see that argument. For me, I’m stuck in independent developer land though. I only look at the companies that are two or three or four people in size.

That’s cool. For a lot of developers, if your brackets –. [Chuckling]

You get used to the brackets, right? I did Objective-C for a few years. Objective-C is a very – not even Objective-C; Cocoa and all those libraries are so well-designed. The long names are a joke, but they’re descriptive and it’s pretty easy to use that API and everything. But yeah, those stupid brackets – for me, it was always the memory management though. I like writing algorithms; I like exploring algorithms, and if I have to worry about bookkeeping while I’m experimenting with algorithms, then that’s just bothering me. It’s wasted effort to care about things you really don’t need to care about. Especially since we’ve had garbage collectors since 1950, basically, and it’s 2014. I think people should've seen the light by now.

A lot of my inspiration comes from Smalltalk and playing with things like Newspeak and seeing what a proper development environment and a proper object-oriented operating system would work like. I guess I’m just constantly pushing for our practical, everyday operating systems to just be a little bit more like that.

Awesome.

Xamarin.Forms – I’ve heard mixed reviews on whether it’s really a usable technology at this point.

Okay. Where do you even begin with this one? It’s definitely usable technology. It’s definitely a version 1.0 product though. I’m not sure which part you’re referring to, but I think the biggest complain I get is sometimes people run into performance issues, and that’s all due to its [inaudible 34:57] to the operating system internal implementation details – all details that can be improved over time. But from a productivity perspective, it’s a pretty darn nice library. It brings back this concept of defining your user interface and XML files and then just doing data binding to them, but it’s also a very succinct API if you want to construct user interfaces just in code.

I would say it’s definitely version 1.0 and that it’s missing a few features. For me in particular, I really wanted a pan gesture recognition or swipe or something like that, and oddly enough, it only supports tap right now. So there are funny, little version 1.0 limitations like that right now, and there are a few little performance hiccups. Really sometimes people are building user interfaces incorrectly; I don’t think it’s a good user interface to display 10,000 rows and a TableView to a user. I just think that’s bad UI. But then there are people who complain that when they put 10,000 rows in a TableView, it doesn’t scroll nicely, so you got to play with the two balances of that to support even the craziest scenarios. It’s just a version 1.0. It’s coming along.

Okay. Declaring your UI in XML, it sounds similar to Silverlight or WPF. Is that [crosstalk 36:11].

It’s specifically like that. It even uses XAML, the language – it’s a different API so the class names are slightly different, but it’s XAML. It’s our old friend, XAML.

Here we go.

Yup. Which of course means everyone wants a XAML-designed tool now. But it’s definitely nice for the people who especially are still in Windows land, who do Windows development, because that’s all XAML-based. So transitioning over to doing iOS or Android, they can use a lot of their skills.

So are there any circumstances under which you would want to go full-on native tool set as opposed to using Xamarin?

I’ll give you one instance. In iCircuit, before the Accelerate framework came out, I had a bit of code that has to do with some work with matrices, so it has to solve a linear algebra equation. Unfortunately, the matrices get to be quite large; they’re 200 or 300 by 200 or 300, so it’s a lot of math they have to do. At first I wrote that in C# and it ran fine. I could handle circuits upwards of maybe 20 or 30 elements before it started to show its slowness. When I, just on an experiment, took that and rewrote it in C, compiled it in C and then just linked to that library, I got about 40% speed improvement, so there was something there, but you have to keep in mind that this is very tight code. This is not normal code; this is matrix code. It’s pretty much what LLVM was designed to optimize, so it’s really good at that. And even the 40 is sounding wrong to me right now.

That was a clear place where I got a real benefit from at least having a small part of my app written in just pure native, plain old C. The good news is, Apple gave us the Accelerate framework. Now, I can call into the Accelerate framework and have it do all the matrix math, and that thing’s ten times faster. We’re not talking about a 40% improvement; we’re talking 10,000 % improvement, so that thing is just awesome.

So there are times. I guess performance, there is one time you dip down. The other times are when you’re using someone else’s library; you just want to import it, but honestly I can’t think of any other reasons I would want to.

Makes sense to me.

Yup, performance [chuckles]. Always got to watch performance.

Alright, should we get to the picks?

Sounds good to me.

Let’s do it.

Andrew, do you want to start us with the picks?

I just got two picks today. My first one is maybe a little predictable, but it’s Calca and this is Frank’s app.

Nice!

I think I bought this app right when you released it. It is a really super cool app. It’s a Markdown editor, but it can also do all kinds of calculations basically, in-line, so it’s like a Markdown editor and a really sophisticated calculator mashed into one. It’s just great for doing quick calculations. I often use it when I’m trying to figure out budgeting and that kind of thing, but it’s also cool because you can use it to present this information to other people, like write about a bunch of calculations and actually show how the results work out. Anyway, definitely check out Calca.

My second pick is actually a new camera that I got this week, and it’s the Fujifilm X-T1. I hope I didn’t already pick this, but I don’t think I did. It’s a mirrorless digital camera, so that means it can be smaller than a digital SLR. These are starting to get really popular, but I’ve just been really impressed with this Fuji camera and the whole line of cameras and I’ve been enjoying shooting with it a lot. It probably weighs a third as much as the digital SLR that I had shot with previously.

That’s Fujifilm X-T1 and those are my picks.

Very nice. Alondo, what are your picks.

I have what I would consider one and a half picks this week. There’s a lot of excitement about WatchKit, because specifically where I work we’re all getting WatchKit as soon as they come out. We are working on some possible features that will integrate with our existing app.

There was a great article in the Verge that came out yesterday, and it talks about some of the discoveries they made just from investigating the WatchKit, which is now available. The documentation’s out for anybody who’s interested, so I thought it would spark some really good discussion about what we can do and if anyone’s interested I think they would find it pretty useful.

Along with the that, the half pick is just the actual documentation for WatchKit, for those that are interested. And those are my picks!

Very nice. Jaim, what are you picks?

I have one pick. Yesterday, with all the snow we’ve had around here, I’m trying to get my wife’s bike ready so she can bike in the winter inside with it; she had a trainer. We had to put on these trainer wheels, and these are a complete pain to get on a bike. There’s a rigid rim around them, so they’re really hard to get on a bike. We bought the trainer last year and we had the shop do it. I was too lazy because it was 10° outside I’m like, “I’m not going outside to take this to the shop just to put a wheel on a tire.”

I struggled with it for a little while and I found a really great video online of this older Englishman that tells you how to put a hard-to-fit tire on a bike. I was able to get my trainer on my wife’s bike and got it all set up, and she’s riding pretty good. That’s a good pick if you have to change tires on bikes. I’ll send the link. That’s my pick.

Awesome. I’ve got a couple of picks that I’m going to throw out there. I’ve actually joined the cast of another podcast. I guested on their show and then they asked me to come back permanently and I had a good time. If you’re interested, it’s the Entreprogrammers Podcast. It’s basically a Mastermind group, except we just record it and release it. If you’re interested in that kind of stuff – entrepreneurship – and you’re a developer, then this is right up your alley, so I’m going to pick that.

I have two picks and an anti-pick. This weekend, my wife and I got away. We went up to Park City, Utah, which is a terrific place to go. If you’re interested in the Olympics, the Olympic training facilities are up there. They have a bunch of Olympic venues that they build during the 2002 Olympics, so you can go see that stuff downtown, if you can call it a downtown. Park City is a lot of fun; just main street, it’s cool and it’s fun just to walk up and down there. It’s less fun when it’s this cold, but that was fun.

My other pick is just getting away, finding some space and enjoying yourself. I think we all work hard and sometimes we just need a break, so go take a break.

My anti-pick is, we went up there, we wound up staying at Westgate Resort. Westgate is a Timeshare company, and so we got a good deal on the room. The deal though included that we had to go sit through their sales pitch, and they were extremely aggressive and lied to me at least twice, so they’re my anti-pick. Timeshares don’t completely make sense to me anyway, but if you’re going to be rude, you’re going to be pushy, you’re going to be manipulative, and then you’re going to lie to me, yeah, I anti-picking.

Wow. I didn’t even know that you could anti-pick. That’s a whole new dimension to us.

Here are all the thing I hate [chuckles].

Yeah, gosh. It changes everything.

Yeah, I’m probably going to write a blog post about how not to sell, and it’s going to be based on this experience. Anyway, Frank, what are your picks?

I have three; I did my homework. I want to start with an app that – I run my life with the app. It’s called Clear. It’s an iOS and Mac app. It’s just a to-do app and its grand feature I guess is that it’s super easy to add things and check them off your list. But basically it’s just a very well-written app, just very fine-tuned to creating to-do items. It syncs over iCloud so I jump between Mac and my phone all the time for managing lists. Because of its ease of use, I just use it constantly. If I have someone that’s using my app and I’m looking over their shoulder, I’m just constantly taking notes while they’re doing UI improvements, things that I want to fix and all that just because the app is so awesome. Please go use Clear. It’s by Realmac Software. It’s easy to find.

Another app that I use day-to-day is called Dash. It’s a programmers’ documentation aggregator and browser for Mac. I think it’s also for iOS, but I always use it on Mac. The really cool thing about it is that it can handle multiple documentations sets, so I constantly have it searching .NET and iOS and Mac continuously, since those are the libraries that are available to me constantly. So it’s really nice just having one nice UI to jump between all the different documentation sets and everything like that, so I highly recommend Dash. That’s by Kapeli – D-A-S-H.

With Examples in F# and C#. I think with Swift coming out, and it being a very nice, cute, little subset of F#, Swift programmers could learn a lot from seeing all the knowledge and patterns. I know that word’s a bad word nowadays, but techniques for programming real apps in a functional hybrid language, just like F#. I’d say that even though this book is for F# and C# programmers, I’d say three-quarters of it is useful to a new Swift programmer, especially all the functional parts. You just can’t use all the cool async stuff that we can do. But definitely a great resource, if you’re jumping into that world. And those are my picks.

Awesome. I do want to point out, I always hesitate to tell people what we’re talking about next week, but Alondo mentioned it, I think Frank mentioned it, so I’m going to tell you and then if something happens and it gets moved or canceled, then I’m really sorry. Next week we will be talking about WatchKit with Carl Brown. If you’re interested in that, stay tuned.

Go Apple watch!

I don’t have any other announcements, so we’ll wrap up and we’ll catch you all next week! Thanks for coming, Frank.

Thank you. Thank you very much for having me, this was a lot of fun.