"Either way I think Arc would be a great fit for creating iOS apps as Arc has much simpler language constructs and mutability/concurrency wouldn't be as big of an issue given the localized nature of mobile code."
Sorry, I think I'm not catching all the context of this sentence. What language's "language constructs" are you comparing with Arc's? (Objective-C? Gambit Scheme? Racket?) What environment with "mutability/concurrency" issues are you contrasting with "mobile code"? (Server programming?)
I've only barely done any iOS programming, but I've done a bit of work on Android apps, and Android organizes rendering and event handling onto different threads.
Arc has fewer data types and consequently there are less methods/means required to interact with them. For example clojure has at least a dozen collection types (sets, various types of maps, vectors, seqs, lists, cons, etc, etc...) while at the same time having a variety of methods used to access them (atoms, refs etc).
This variety creates depth to the language, but it also makes the language more complex (even if appropriate). For example even the terms overlap creating confusion... I.e what's an 'atom' ? what's a 'map'? ifn? vs fn?, why does a vector get treated as a function?
So each of these "constructs" serve a purpose, some of which are to deal with state and time, or shall I say concurrency and mutability which often have to do with parallel computing or managing concurrent threads which all operate on the same object or data structure.
Currently Arc is limited to a very small set of data structures and methods to interact with. I believe arc still deals in mutability only, relying heavily on queues to manage state and time. Either way Arcs minimal set of constructs are probably well suited for many mobile code applications given you only need to manage interaction from a single user.
