Clojure on iOS devices - Swift as a host?

[Greg Knapp]

The recent release of Swift made me revisit Clojure on LLVM. This post from 2010 suggests it's a very difficult task.

Swift would make this job easier? As with ClojureScript, generate Swift code / provide interop and Clojurian's can produce native iOS apps?

Perhaps the biggest hole to be filled would be tooling (Xcode is not Clojure/Lisp friendly? i.e. no playground support)

[Timothy Baldridge]

I'm starting to feel like a broken record, but here we go.

Some things to think about:

1) Why do you want this? The JVM GC and JIT are some of the fastest (if not the fastest) on the planet, so performance will never be a good reason to do this. 
2) Do you want something like eval? As far as I can tell Swift is statically compiled. Only XCode has the ability to modify a program on the fly. 
3) Clojure is highly polymorphic and dynamically typed. Walk the source code for first  and next and you'll find something like 3-4 polymorphic calls involved in something as simple as (doseq [x (range 100)]), per item.

4) I have yet to see performance numbers for Swift....how fast/slow is it compared to other languages?

To put this all into perspective, I once translated LazySeq to C++ and ran some code (with a GC) that performed something like (doall (range 100000)). The result was about 10x slower than Clojure on the JVM. So simply running something in C++/LLVM doesn't mean that you'll even get close to the performance of the JVM. 

Memory constrained systems might benefit from a LLVM Clojure. In addition there's room for improvement with the JVM's horrible warmup times. Python will boot instantly on most systems while the Clojure REPL takes about a minute to boot on the RPi. But aside form that, I can't see much of a point. 

If you want something like this there's always (https://github.com/galdolber/clojure-objc)

Timothy

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Mike Fikes]

I have been experimenting writing an iOS app using ClojureScript embedded in JavaScriptCore, where the ClojureScript essentially implements the logic of my view controllers which drive native UI.

So far, this approach seems like a reasonable one to “writing iOS apps using Clojure.”

You essentially trade off direct tooling support and gain the ease of developing using ClojureScript (this is important to me, as my server is in Clojure and I can effectively master one language.)

[Aaron France]

@Timothy, you mention speed a lot, but I'm not sure where in the OP it mentioned wanting to do this for speed at all. I think the intention is to be able to Clojure on a different platform, is all.

[Greg Knapp]

I wasn't really pointing at performance with my post. More about native app development, for OSX we have Clojure on the JVM which is fine. I don't see Apple allowing Java on iOS anytime though.

Thanks for the replies so far, this was purely food for thought.

[David Nolen]

I wouldn't pass judgement on Swift too soon. Eval works just fine in the REPL and it appears the language supports hot code loads out of the box. Swift also has real support for final fields via 'let'. I personally think a ClojureSwift could be quite interesting :)

[Ambrose Bonnaire-Sergeant]

Does Swift have any static types to harvest? :)

[Mike Fikes]

Maybe ClojureSwift does have potential, even with respect to *performance* as well: There's decent speculative chatter [1] about Swift’s safety enabling aggressive optimizations that can't be performed in unsafe languages like Objective-C, with Swift outperforming on RC4 and other benchmarks.

[1] http://programmers.stackexchange.com/questions/242816/how-can-swift-be-so-much-faster-than-objective-c-in-these-comparisons

[Max Gonzih]

GC means pauses. Swift doesn't have proper GC, only ref counting because of that. GC pauses in UI are bad.
I like idea of Clojure on some new fancy high performance language like Go or Swift.

[Hussein B.]

The idea of having lisp on iOS (and OS X) is really awesome but there is a huge downside:

That won't integrate with Xcode "Interface Builder" out of the box. That would be the deal breaker.

[Gal Dolber]

I've been writing iOS apps in clojure for some time now. Believe me when I say that Interface Builder is the least of your problems. I wrote a small lib https://github.com/galdolber/uikit to generate iOS interfaces from clojure data structures.

Aside from being able to compose ui like never before, Interface Builder gives you limited access to Apple's amazing Auto Layouts. Once you have full access to it, it's amazing what you can do.

Now, all that said, I don't see why you could not have binding to work with Interface Builder.

--

[Mike Fikes]

While Gal's approach of ditching IB is fine, I still use it, but bind UI components to atoms in ClojureScript. Once that is done, you have a lot of power at your disposal on the ClojureScript side of the JavaScriptCore bridge: With atom watchers you can react to UI state changes, feed them through core.async channels if you'd like to create FRP-like solutions, etc. You can create macros as needed to simplify any complexities that arise with the fact that iOS is on the other side of that bridge. You can nearly have your cake and eat it too :)

[Devin Walters]

If I had a small fortune I would pay you to sit down and show me how this business you're talking about works. Sounds really cool. Is doing this kind if thing documented well anywhere? I'd love to see some code and your workflow.

'(Devin Walters)

> On Jun 11, 2014, at 15:30, Mike Fikes <mike...@me.com> wrote:
>
> While Gal's approach of ditching IB is fine, I still use it, but bind UI components to atoms in ClojureScript. Once that is done, you have a lot of power at your disposal on the ClojureScript side of the JavaScriptCore bridge: With atom watchers you can react to UI state changes, feed them through core.async channels if you'd like to create FRP-like solutions, etc. You can create macros as needed to simplify any complexities that arise with the fact that iOS is on the other side of that bridge. You can nearly have your cake and eat it too :)
>

[Mike Fikes]

Hi Devin,

A great place to start is http://web.cecs.pdx.edu/~cpinera/javascriptcore-integration-with-clojurescript-in-ios.html (some slight modifications are required to get that blog post examples working with the latest, but it's not that hard).

Another great resource is the WWDC 2013 video on JavaScriptCore.

Once you have a sample project up and running, then you are “cooking with fire.” Roughly the workflow involves editing ClojureScript (I use Cursive in IntelliJ, but any IDE would do) where the results of lein cljsbuild auto are being consumed in a “sibling” Xcode workspace. Make a change to ClojureScript, rebuild your Xcode app, observe the change in behavior, repeat.

Debugging is nearly impossible, so I rely heavily on logging, and on producing lots of pure functions that can be independently verified in a REPL. So the first thing you would want to do is set up things do that when you call a logging function in your ClojureScript, it is routed to iOS and logged in the console.

To avoid needing to add lots of new JSExport methods for new functionality, I take the approach of writing some plumbing code that can work with the UI by referencing UIComponents via their “tag” integer, which I manually set in IB and then call a “bind!” function in ClojureScript to set up the needed interactions.

For example, I might have a (def text-field (atom {})) and then in an init method marked ^:export that takes a view argument, I do (bind! text-field view 1), where the literal 1 is the tag for a text field in IB. I've written bind to call into Objective C and register for notifications on that tag, setting things so that, for example, whenever the text changes, it calls back into ClojureScript executing a function that ends up calling (swap! text-view assoc :text updated-text).

You can take a similar approach to have button tap events drop a message into a core.async channel, and associated plumbing to bind a UI button to the channel.

The end result is that you can essentially write what would normally be view controller code in ClojureScript.

A lot of the above (especially the code fragments) are from memory—ask if you'd like more elaboration. But in the end, it's simpler and less elaborate than you might initially think.

- Mike

[Devin Walters]

Very helpful info Mike, thank you.

I'll fire up Xcode this weekend, give what you're saying a try, and report back.

Thanks!
'(Devin Walters)

[Gregg Reynolds]

On Thu, Jun 12, 2014 at 8:14 AM, Mike Fikes <mike...@me.com> wrote:

Hi Devin,

A great place to start is http://web.cecs.pdx.edu/~cpinera/javascriptcore-integration-with-clojurescript-in-ios.html (some slight modifications are required to get that blog post examples working with the latest, but it's not that hard).

Thanks for the great info.

I don't suppose you (or anybody else watching) have taken a crack at using Cappuccino with Clojurescript?

-Gregg 

[Mike Fikes]

Not me, but if I needed to build a web app, Cappuccino and Om would be on my list of things to dig into

[Mike Fikes]

Hey Devin,

You had asked to see some code. Here is a little, to give a feel for the “top level” without digging into the plumbing.

Let's say you want an authentication UI that lets you enter a 6-digit code with a keypad and asterisk indicators showing how many digits have been keyed. Here is a screenshot of that UI (actually being driven by ClojureScript):

This UI simply comprises some labels and some buttons.

The ClojureScript code that runs the UI binds to those iOS components via tag number (which is set in interface builder), and has a little logic to maintain a model that consists of a vector of the digits entered so far, and code to color the asterisks.

In the picture above, two button presses have occurred and the code has logged:

2014-06-14 22:47:11.291 Test App[2428:60b] JS: code-entered: [1]

2014-06-14 22:47:12.213 Test App[2428:60b] JS: code-entered: [1 4]

The “view controller namespace” hooked up to this view is this ClojureScript code below. In it you can see an atom per UI element along with bits of code manipulating the maps in the atoms (such as set-enabled!). The “plumbing” that I haven't shown is a bit of boring code that marshals information between the atom values and the iOS components. A sample atom value for a text field might look like {:text "foo" :enabled true}.

(ns test-app.view-controller

  (:require [fikesfarm.ios.interop :refer [bind!]]

            [fikesfarm.ios.view-model :refer [set-text! set-callback! set-enabled! set-hidden!]])

  (:require-macros [fikesfarm.ios.util :refer [with-try]]))

;; View-Model

(def asterisk-labels (vec (repeatedly 6 #(atom {}))))

(def number-buttons (vec (repeatedly 10 #(atom {}))))

(def clear-button (atom {}))

;; Model

(def code-entered (atom [] :validator #(< (count %) 7)))

(defn- update-asterisk-labels!

  [count-entered]

  (dorun (map-indexed (fn [n asterisk-label] (set-enabled! asterisk-label (< n count-entered))) asterisk-labels)))

(defn- set-number-buttons-enabled!

  [enabled]

  (dorun (map #(set-enabled! % enabled) number-buttons)))

(defn ^:export init-myvc!

  [view]

  (with-try

    ;; Bind the UI elements

    (dorun (map #(bind! view %1 %2) (range 21 27) asterisk-labels))

    (dorun (map #(bind! view %1 %2 :touch-up-inside) (range 1 11) number-buttons))

    (bind! view 11 clear-button :touch-up-inside)

    ;; When a number button is pressed, conj value to the code-entered vector

    (dorun (map #(set-callback! %1 (fn [] (swap! code-entered conj (mod %2 10))))

                number-buttons

                (range 1 11)))

    ;; Empty the code-entered vector if clear button pressed

    (set-callback! clear-button (fn [] (reset! code-entered [])))

    ;; Set the asterisk labels to the correct initial rendering

    (update-asterisk-labels! 0)

    ;; As the code-entered model changes, update the number of asterisks shown

    (add-watch code-entered :code-entered

               (fn [_ _ old-code-entered new-code-entered]

                 (when-not (= old-code-entered new-code-entered)

                   (println "code-entered:" new-code-entered)

                   (update-asterisk-labels! (count new-code-entered))

                   (when (= new-code-entered [1 4 7 2 5 8])

                     (set-number-buttons-enabled! false)

                     (set-enabled! clear-button false)))))))

- Mike

[Mike Fikes]

(Apologies to Greg for having essentially hijacked this thread, but I suspect he'd find this cool.) 

I have no experience with the Swift REPL yet, but I'm still finding this a little surreal:

(It's a picture of me holding an iPod touch, jacked into it wirelessly via a ClojureScript REPL, live updating a UITextField's text.)

[David Nolen]

Nothing to add other than to say this is really cool stuff :)

David

[Mike Fikes]

Thanks David! Targeting ClojureScript to iOS just got an order of magnitude easier for me.

I want to say that Colin Fleming (Cursive) has been extremely helpful in helping me sort out how to achieve this.

[Colin Fleming]

Mike's doing all the hard work on this :-)

Very interesting project - CLJS may be a viable option for iOS app development, which is pretty exciting stuff.

One thing I dimly remember from somewhere (HN, maybe) was that JavaScriptCore apps wouldn't get JIT'ed, because iOS apps have no access to executable memory. This is allegedly a process-level restriction, so even if JavaScriptCore is a platform feature of iOS, standard apps won't benefit from JIT performance. Can anyone confirm this? That would be a bummer.

On 24 June 2014 23:59, Mike Fikes <mike...@me.com> wrote:

Thanks David! Targeting ClojureScript to iOS just got an order of magnitude easier for me.

I want to say that Colin Fleming (Cursive) has been extremely helpful in helping me sort out how to achieve this.

--

[Omer Iqbal]

I believe you're right Colin. JavaScriptCore doesn't use the JIT compiler [1]. There might be a possibility of that changing though

1. http://phoboslab.org/log/2011/04/ios-and-javascript-for-real-this-time

[Steve Tickle]

In the upcoming IOS8, UIWebView has the same (JITed) performance as the Safari, the distinction has been removed due to using the new inter-app communication mechanism. This allows the remote application (Safari/JavascriptCore/UIWebView) to display a view into another process, thus bypassing the no-executable-pages issue.

So basically... get the IOS8 beta & new XCode beta and play with it...

[Mike Fikes]

That's cool!

What I haven't been able to figure out is if we actually get FTL with JavaScriptCore on iOS 8, or better yet, if we can somehow gain access to a JSContext from the WKWebView.

More detail: I'm using ClojureScript to develop what are otherwise native iOS apps. (Meaning using UIKit, StoryBoards, UIButtons, UITextFields, view hierarchies, animations, etc.—the same stuff you would work with if you sat down at Xcode and wrote a "conventional" iOS app.) In other words, not self-contained web apps that manipulate the DOM of a page hosted in the app in order to render its UI (in which case WKWebView would be directly applicable and FTL would be enabled).

You can do this using JavaScriptCore, which is akin to a "bare-bones" JavaScript engine that you can use to drive Objective-C objects that you've exported into JavaScriptCore, and vice-versa (drive the JavaScript from Objective-C). UIWebView, on the other hand, adds additional stuff to its JavaScript environment. You can certainly run the output of the ClojureScript compiler in JavaScriptCore, but the first thing you will run into is the lack console.log, which is easy to add back in via Objective-C. Then the next thing you might encounter is the lack of setTimeout (which occurs, for example if you use a core.async timeout channel)—which you can also add back in. Then, if you try to establish a REPL into JavaScriptCore, then you may find you are lacking socket.io, which you could also theoretically add to JavaScriptCore.

At that point (essentially trying to run a browser REPL inside something that is arguably not a browser), I decided to just use UIWebView, simply for the purpose of REPL development, grabbing its JSContext (which is the same thing you get when you are working with JavaScriptCore), using private API. This is cool for development using the REPL, but it is safer to go back to JavaScriptCore for actual release builds that must pass review for the App Store. 

So, with WKWebView (the JITed replacement for UIWebView), those same questions come into play. Can we gain access to the JSContext of a hidden WKWebView using public API? (In that case it can be used all of the time, both for REPL dev and for release builds). Failing that, is JavaScriptCore JITed in iOS 8?

[Greg Knapp]

That is cool :)

[Sven Pedersen]

Here is a project by Austin Zheng to implement Clojure in Swift (swift-lambdatron). He has some basics implemented with a REPL, but it does not compile to LLVM bitcode yet. He's talking about moving to Rust somehow… I'm still pretty new to Clojure, so I'm not sure what I'll be able to offer in language implementation yet. :-)

I've been experimenting with Mike Fikes Goby code and I like what he's done using ClojureScript (see Shrimp example app). However a native solution able to access the Swift iOS API would be much easier and require less maintenance long-term. Anybody else interested in making it happen?

--Sven

[Sven Pedersen]

Austin Zheng has some code here 

https://github.com/austinzheng/swift-lambdatron

that implements the basic syntax of Clojure with a REPL but does not compile to LLVM bitcode yet. He's working on some cool ideas. I really like Mike Fikes work on Goby and the example app Shrimp, and I've been experimenting with them. However, a native solution that does not require Objective C wrappers would be much easier to maintain. I'd really like to see it take off...

BTW, nobody has mentioned RoboVM yet; it is an alternative to run real JVM Clojure on iOS.

[Fluid Dynamics]

On Monday, December 8, 2014 1:45:43 PM UTC-5, Sven Pedersen wrote:

Austin Zheng has some code here 

https://github.com/austinzheng/swift-lambdatron

that implements the basic syntax of Clojure with a REPL but does not compile to LLVM bitcode yet. He's working on some cool ideas. I really like Mike Fikes work on Goby and the example app Shrimp, and I've been experimenting with them. However, a native solution that does not require Objective C wrappers would be much easier to maintain. I'd really like to see it take off...

BTW, nobody has mentioned RoboVM yet; it is an alternative to run real JVM Clojure on iOS.

Do either of those *not* require jailbreaking the phone?

Does LLVM support fixnums? TCO?

[Sven Pedersen]

All the options I mentioned -- swift-lambdatron, Goby, and RoboVM can be used to make apps to submit to the app store. None require jail breaking. Goby and RoboVM have been used for apps that were accepted. 

The compiled form of each app is a bonified Objective-C style LLVM binary. The ClojureSwift hopeful, swift-lambdatron, is not yet ready to make apps.

--Sven

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/HaswRFJw29g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

``All that is gold does not glitter,
  not all those who wander are lost;
the old that is strong does not wither,
  deep roots are not reached by the frost.
From the ashes a fire shall be woken,
  a light from the shadows shall spring;
renewed shall be blade that was broken,
  the crownless again shall be king.”

[Colin Fleming]

Also worth mentioning is Gal Dolber's project https://github.com/galdolber/clojure-objc. It's a modified version of the Clojure compiler which outputs Java source instead of bytecode, and then uses Google's J2Objc project. It's pretty neat - he has two iOS apps live which were totally written in Clojure.

You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

[Sven Pedersen]

Also, LLVM does support 

Swift seems to support Tail Call Optimization, according to this thread:
http://stackoverflow.com/questions/24023580/does-swift-implement-tail-call-optimization-and-in-mutual-recursion-case

I'm not familiar with the term fixnum, but if you mean the Ruby term for machine word size integers, I believe that Swift can do that... at least LLVM supports it.

http://www.rubydoc.info/github/dubik/llvmruby/Fixnum

--Sven

On Mon, Dec 8, 2014 at 3:45 PM, Fluid Dynamics <a209...@trbvm.com> wrote:

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/HaswRFJw29g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.