Well, putting liveCode aside as "just a toy" might be a tad bit too quick of a judgement. It surely depends on what you need to do. I have helped releasing a couple of production grade applications over the last 13 years using liveCode. Sure it could not do everything, but I guess like always it is a matter of choosing the right tool for the purpose. The beauty of it being Open Source now is that lacking features can be incorporated into the engine now and it will be even easier once widgets and open language will arrive.

If you search on wikipedia for "Transcript", you'll get redirected to RunRev and LiveCode. I wasn't sure whether Transcript is the name actually used for the programming language. Anyways, I was presuming that one thing is the technology / framework as a whole (LiveCode) and another is the actual name of the programming language standing behind it.

My company has a product that assists home users in troubleshooting computer problems and network connectivity issues (router, internet uplink connection etc). A key part of this commercial product is a "Network Discovery layer". We basically employ several protocols, such as ARP pinging, MAC->to->Manufacturer mapping, UPnP, Bonjour/Multicast DNS, NetBIOS/SMB, TR-064 etc, to discover as many network device nodes as we can within enduser's home network.

Our app is currently developed in C# and WPF. We also have 3 other SEPARATE code bases - one for Mac, another for iOS and finally another for Android. So as you can see, we wish to tackle both mobile and non-mobile network device nodes (i.e. mobile nodes used to initiate network discovery of other devices or to be discovered by others).

We also have a SOA central endpoint, which the agent apps running on the users' devices is connecting to (using RESTful JSON interfaces), to push all the discovered data and create association - users can attach custom names to network nodes, or bind them to a user account etc. The final goal / grand scheme of things is to provide an assistive / help layer on top of all this info, like KB articles and something that we call "Guided Content" (a fully configurable decisioning system, asking users certain questions such as how your cable modem LED lights look like, etc and prompting them to check other things or perform automated tasks like reboot the PC or the router, reset network interfaces etc).

Part of this system (especially the Guided Content system) was even backported to Linux-based embedded appliances, such as a Satellite Receiver STB box (using a Broadcom MIPSEL platform) and a home automation / security device (based on an ARM platform).

So as you can see, it's not a trivial system. I was evaluating many Cross-Platform solutions (node.js, LiveCode, Embarcadero, PhoneGap, Titanium) and LiveCode seemed interesting. Because it can target also Linux desktops (even Raspberry Pi), Mac OSX and the mobile (Android and iPhone). The only thing missing from this picture is Windows Phone (for the linux embedded platform such as MIPS we can live with lack of support for that for the moment).
LiveCode seems very promising (even if its programming language is not that concise / we like more terse language in general).

But it cannot unlock too much of the target platform's functionality - at least in terms of common / usual things such as socket programming - then I'm afraid it's not production ready?

We have another team who is evaluating Xamarin (they are a bit stubborn and wish to use C# and nothing else). But I don't like that Xamarin is too expensive and it's not able to target, out-of-the-box, via a single IDE and technology, Linux or even Windows Phone (for Linux it's telling you to "go to Mono" as if THEY FORGOT where they started from and they distanced themselves from the open source community) and for Windows Phone they just say "well, Visual Studio 2010/2012/2013 supports that implicitly, so don't use Xamarin for that).

This "code once, run everywhere" paradigm was a very hard problem in Computer Science - even before the mobile platforms came in. And now that the mobile stuff came into the picture, the market had become more fragmented, more locked-in / too many walled gardens (to the extent that now you have an "affinity" of some particular programming language to a very particular mobile platform i.e. Objective-C or Swift for iOS, Java for Android, C++ for Blackberry 10 etc), SO THE PROBLEM BECAME EVEN HARDER TO SOLVE.

Could you guys help me in getting to a more informed decision?
We wouldn't need access to too much low-level stuff from the target platform. For example, we are aware of the "sandbox model" that all the major mobile platforms have been designed with from start, so we won't be expecting to be able to open sockets in listen/inbound mode as such devices are meant mainly for consumption (clients) of other remote services. An "equalizer" - lowest common denominator - wouldn't impact our app too much. If we focus mostly onto UI and outbound network connections etc...And eventually have "#if" statements to leverage more functionality on more capable platforms (windows desktop, linux, Mac OS X desktop) - so we will accept that certain nodes in the network will be more capable (i.e. being discovered via more comprehensive protocols such as UPnP etc or able to perform troubleshooting tasks such as disk defrag, automatic wifi connection assistance etc).

To add another datapoint for your evaluation, we're currently in the process of adding some of the features you're missing to LiveCode as part of the LiveCode 8 project.

Firstly, we're augmenting the existing LiveCode Scripting language with a complementary language offering some of the features more typical for "systems" programming languages. This language keeps the English-like syntax but provides for strict type checking, a foreign-function interface (FFI) for calling into native-code libraries, better encapsulation and modularity, etc. (As an aside, it is equally usable as a C-style language using function calls rather than syntax, if that's how you'd like to provide your functions).

It is true that the current scripting-language access to sockets is very high level and providing lower-level access to sockets is on our radar for LiveCode 8 (via extension libraries written in the new language). If that isn't enough for your needs, it can be done through the FFI. (You'd have to write a small amount of code per-platform for the FFI bindings, but the rest of the code can be shared).

I'd be happy to help if you'd like more information or to discuss your requirements in more detail. I'll PM you my email address so that we don't go too off-topic on this thread (unless it is all socket-related!).

That sounds like a *very* interesting system. I've done similar work, some in LiveCode, some not. I can tell you that most, but not all, of what you're looking for can be done now. The cross-platform capabilities are second to none. RESTful interfaces and dealing with json objects are very easy. I have also added a soa web services library to the revOnline repository.

Unfortunately, we had to pass on LiveCode for a project that needed udp broadcasts and ended up with an Adobe Flex nightmare. Yes, it did link in the proper networking layered stuff, but building and maintaining it was a real pain. And it ended up being Windows only because Adobe eventually pulled out support for everything else. And the flex automation layer is a partial implementation, causing us to run into brick walls frequently.

There is good news on a couple of fronts: first of all, as Fraser mentioned, there are some exciting new additions on the way. They're dribbling out slowly, but if you have a pressing need maybe you can be the driver for getting a push behind some features you need. OTOH, if you need a low-level networking solution Right Now then I'd suggest you keep looking. The other good news is that you can add external libraries written in other languages (notably C) for additional functionality.