
Swift available for Beaglebone/RasPi - zdw
http://www.housedillon.com/?p=2287
======
andybak
One step closer to Swift on Android.

One step closer to cross-platform, native mobile development in a vaguely
tolerable language.

(I'm under no illusion as to how much further work is needed and how many
things would need to fall into place - but I'm the optimistic type)

~~~
nostrademons
Swift on Android has been done already, by multiple independent groups:

[http://arctouch.com/2014/10/swift-make-android-
app/](http://arctouch.com/2014/10/swift-make-android-app/)

[http://romain.goyet.com/articles/running_swift_code_on_andro...](http://romain.goyet.com/articles/running_swift_code_on_android/)

It's not exactly easy though, and I doubt that a single WORA language will
_ever_ become the preferred way to do mobile development. (It already exists,
anyway, in the form of Xamarin. Neither Xamarin or Java on the desktop became
all that popular, though, because the apps you can write with them just aren't
as good.) A native platform is a moving target: by the time your cross-
platform abstraction layer catches up, new features will have been introduced.

It's more likely that a single app will become ubiquitous enough that you can
count on it being on every platform, and then develop a programmable layer on
top (a la the web). Either that, or everyone will continue developing native
clients with a shared data/logic layer abstracted behind RPC calls. That's how
we used to do networked applications back in the desktop days.

~~~
andybak
Maybe not WORA - but 'Write your business logic, a chunk of your UI logic
once, then do something sensible for the rest of the UI code'.

Admittedly - there's problems even achieving that. Android intents, activities
and fragments don't easily map to anything on iOS and they have big
architectural implications.

~~~
mahyarm
Activities and fragments are pretty much just view controllers in iOS. People
make view controllers meant to be reused and embedded into other view
controllers all the time. Parts of intents are a navigation mechanism, the
other part starting an app with an app specific URL. Working in such an
environment with a C++ business logic layer and the iOS and Android UXs, the
architectural differences weren't that big of a deal.

Also the business logic layer shouldn't care about the UI that much. It mostly
should be a set of service objects that you interact with that give you a data
set to render. The service objects handle persistence and network operations
themselves. From that you build your own independent apps. Coupling the UX to
the C++ layer results in pain unless your rendering the UI yourself in C++,
like with most games.

~~~
nostrademons
I've found the trickiest parts of cross-platform app development is that some
features on a platform just have no analogue on other platforms. For example,
notifications on Android can have BigViews in either text, list, or inbox
styles. They're also supposed to collapse, although some apps (I'm looking at
you, Facebook) don't bother. The equivalent on iOS is just badging the icon
and showing a short 1-line text string as an alert. That means that some
information which would've gone straight into the notification on Android
needs to be shown on app launch in iOS, which often completely changes the
data structures you'd use to represent it. Oftentimes this can ripple through
the app as well, where because you need to launch the app to see it on iOS,
you might as well add extra interactivity to this data, but that's not allowed
by the Android platform as long as you want to keep it in a notification.

This doesn't matter if all your cross-platform C++ or Xamarin library does is
format strings, provide predicates, and clean data - which is probably what it
should do. But it means that the dream of a business logic layer that just
hands off objects to the UI to render is just a dream. You need to hand off
wildly different objects for a short notification on Android vs. an inbox-
style notification vs. an iOS notification vs. an Intent to start an Activity
on Android vs. an options dictionary for
application:didFinishLaunchingWithOptions:.

------
jws
My interest lies orthogonally to this… I wonder how much effort is required to
port the runtime to a non-unix, non-c-standard-library API. (also not Windows,
in case you were thinking that.)

------
Narishma
Since this is an ARMv7 build, it only works on the Raspberry Pi 2, not the 1
or the new zero.

