Mobile App Development

[[)roi(]]

If I had to pick, I would start with Android/Java (largest user-base in general) and then do iOS. You will find that you can get away with a Java-wrapped app for BlackBerry and Windows usage seems to be very low compared to the other platforms. With Xamarin you will have to figure out many workarounds to make certain things work (especially native integration) and support is horrible. Xamarin is also not free.

If it's corporate apps, then their standards will pretty much dictate the platform; it's rare for corporates to internally want both iOS and Android. External apps the pick should always be based on your potential customers, focus either on the larger market or the market that is most likely to ensure success.

Strange re Xamarin support; I found them to be quite responsive and their skills above question. Tagging wrappers onto someone else's stuff is never easy especially when you have no control over how it evolves. I'd honestly love to see them running with Swift; being open source they could easily lead the Android and Windows projects.

 

[MagicDude4Eva]

If it's corporate apps, then their standards will pretty much dictate the platform; it's rare for corporates to internally want both iOS and Android. External apps the pick should always be based on your potential customers, focus either on the larger market or the market that is most likely to ensure success.

Strange re Xamarin support; I found them to be quite responsive and their skills above question. Tagging wrappers onto someone else's stuff is never easy especially when you have no control over how it evolves. I'd honestly love to see them running with Swift; being open source they could easily lead the Android and Windows projects.

I agree with the Swift comments, but if you look back over the last 6 years in the mobile dev space when it comes to cross-platform tooling none really succeeded:

• Adobe Flex/Air: My SO uses it for corporate apps. It works very well from a development and deployment aspect (i.e. no issue with having to do something custom for different platforms). The app is bloated due to runtime and is horribly slow especially on low end devices.
• Phonegap: Never really went anywhere and was eventually bought over by Adobe. And is now not free any more. There were various HTML5/JS wrappers like it, but none really took off
• HTML5/JS wrappers: There are many (Appcelerator, Appception, Appear IQ, Appery.io, Convertigo, Sencha) and some are as simple as a native app with a webkit container just rendering a responsive website (Firefox OS just requires a simple manifest file for your responsive website to work on Firefox OS devices)
• Mono based: Xamarin is probably the most well-known. But there are others such as Mono for Android, MonoTouch, Unity

Anyone having developed native apps for iOS or Android will know what massive pain Android development is (due to huge fragmentation of devices and poor documentation) and how many issues you have during run-time (especially on low-end devices). The same can be said about iOS and when SDKs change. Neither Android nor iOS support is great.

My advice would be:
- If your app is a simple content app (such as News24 or any banking app) you can get away with individual native apps as the codebase will be small.
- If your app does not require native features and/or heavy UI/UX (i.e. a simple app with menu-slider / navbar), go with cross-platform
- If your app is a corporate app and your environment can control device specs, go cross-platform (Xamarin or Adobe Air)
- If your app requires native features and heavily relies on platform specific features (iCloud, Google Cloud services etc), go native.

In case you go with a native app, determine the largest user base per platform and start with one platform first. You will find that once you have done the app once, you will throw away pretty much all app code when you go through the second iteration (since we did our iOS app in 2011 we have thrown out all code twice as we had external parties develop it which turned into a horrible mess / we have now moved the dev in-house and the app is super-slick)

 

[[)roi(]]

I agree with the Swift comments, but if you look back over the last 6 years in the mobile dev space when it comes to cross-platform tooling none really succeeded:
...
In case you go with a native app, determine the largest user base per platform and start with one platform first. You will find that once you have done the app once, you will throw away pretty much all app code when you go through the second iteration (since we did our iOS app in 2011 we have thrown out all code twice as we had external parties develop it which turned into a horrible mess / we have now moved the dev in-house and the app is super-slick)

Comparing Swift with other solutions is incorrect for two reasons:
1. It's a Systems Programming Language, so the comparison should be drawn only with languages like C++ and C. Which btw are natively supported on Android, iOS and Windows; Apps developed at this level overcome most of the performance and resource issues, however true API support will always be dependent on what e.g. Google's has built to be compatible with C++ or C, i.e. Android Native Development Kit (NDK) http://developer.android.com/tools/sdk/ndk/index.html
2. Swift is only starting out, so everything at this stage is conjecture. Although the first alpha version of Swift is running on Android, it really that means nothing; any real application support is ~2 years off.

Btw when Swift accesses C++ and/or C frameworks, these are exposed very similar to the way that C++ or C see them; which implies that Swift in theory should be able to develop Androids Apps indistinguishable from C++ using Google Android NDK, which under the covers is just Java's JNI https://en.m.wikipedia.org/wiki/Java_Native_Interface

I can already confirm seamless development with Linux frameworks (e.g. Gnome GTK/ GDK X11) i.e. method calls appear no different that they do in C or C++.

Note: Mono was the original name for the Xamarin C# project on OS X and Linux. Monotouch was the original Xamarin name for its iOS implementation; that portion of the codebase remains open-source and if you consider that the developers of Xamarin and mono are one and the same; its not hard to imagine how hamstrung mono would be vs. Xamarin.

 

[MagicDude4Eva]

Comparing Swift with other solutions is incorrect for two reasons:

I get that. Remember with what great promises Mono started out? The same applies to Swift as contributors need to provide underlying integration/libraries to transform Swift code into Java. The NDK is just a fancy name for JNI (Java Native Interface - we used that already in 2004 when we needed to call OS/2 libraries from Java) and has only value in high-compute requirements (gaming / graphics / encryption). I doubt that Google would open the whole Android SDK within the NDK.

I think going down the Swift route now is wrong and will probably lead nowhere for the next 2 years.

 

[[)roi(]]

I get that. Remember with what great promises Mono started out? The same applies to Swift as contributors need to provide underlying integration/libraries to transform Swift code into Java. The NDK is just a fancy name for JNI (Java Native Interface - we used that already in 2004 when we needed to call OS/2 libraries from Java) and has only value in high-compute requirements (gaming / graphics / encryption). I doubt that Google would open the whole Android SDK within the NDK.

I think going down the Swift route now is wrong and will probably lead nowhere for the next 2 years.

Nope that's what you don't get; nothing needs to be done except to port Swift on Android version of Linux. Apple's already doing the big work with the compiler and linker.
The frameworks will need no special provisions, Swift will link in Android NDK using the same JNI type interface that C and C++ use today. It's not limited like Xamarin of the others. Swift will just be another option to choose from i.e, C, C++, Swift or Java.

Google could have done the same with Go, not sure why they didn't pursue it.

Btw I've checked most of Google's Android API is exposed via JNI; a lot of the performance vector is lost in this design though, meaning C++ code won't run faster than Java, because it's still tying in the Java VM i.e. no discernible difference for API code; but tying into C++ frameworks will fly of course. Biggest benefit is being able to tie into frameworks from both worlds, with s huge performance vector jump for the native C++ ones

 

[semaphore]

Google could have done the same with Go, not sure why they didn't pursue it.

There is support, it started in 1.4. It's obviously still under heavy development.

https://github.com/golang/mobile

 

[[)roi(]]

There is support, it started in 1.4. It's obviously still under heavy development.

https://github.com/golang/mobile

Cool, always thought it strange that Google never deprecated Java in favor of Go; the performance benefit alone should have been reason to push for this + with NDK/JNI they have a fairly easy migration path.

I think one go the biggest decisions they need to take is dropping the GCC compiler and moving over to LLVM; biggest gain is the C interop, which today is not comparable with Swift.

I might even start to enjoy Android programming if this happened.

 

[semaphore]

Cool, always thought it strange that Google never deprecated Java in favor of Go; the performance benefit alone should have been reason to push for this + with NDK/JNI they have a fairly easy migration path.

I think one go the biggest decisions they need to take is dropping the GCC compiler and moving over to LLVM; biggest gain is the C interop, which today is not comparable with Swift.

I might even start to enjoy Android programming if this happened.

Go's support for C is fine, you just use cgo. I've had to use it on some fairly complex C libraries.

https://golang.org/cmd/cgo/

Furthermore:

http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT

 

[rward]

[*]Phonegap: Never really went anywhere and was eventually bought over by Adobe. And is now not free any more. There were various HTML5/JS wrappers like it, but none really took off

Cordova, which phonegap is based off is FOSS. - https://en.wikipedia.org/wiki/Apache_Cordova

PhoneGap is Adobe’s productized version and ecosystem on top of Cordova. Like PhoneGap, many other tools and frameworks are also built on top of Cordova, including Ionic,[8] the Intel XDK,[9] Monaca, TACO, and the Telerik Platform.[10] These tools use Cordova, and not PhoneGap for their core tools.

 

[[)roi(]]

Go's support for C is fine, you just use cgo. I've had to use it on some fairly complex C libraries.

https://golang.org/cmd/cgo/

Furthermore:

http://llvm.org/svn/llvm-project/llgo/trunk/README.TXT

As for LLVM as far as I know they abandoned that, refer: https://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers

It was really a short sighted decision: they basically prioritized faster compile times over compiler power, flexibility and faster code; LLVM takes longer to compile but that's because it doing so much more than GCC; Apple e.g. ran with GCC until Xcode 4.1.

Go's C integration could be so much simpler; it's supported by default with Clang module maps http://clang.llvm.org/docs/Modules.html

Also there's a price to lay for cgo design http://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
LLVM would have fixed all this.

 

[semaphore]

As for LLVM as far as I know they abandoned that, refer: https://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers

It was really a short sighted decision: [Bt]hey basically prioritized faster compile times over compiler power[/B], flexibility and faster code; LLVM takes longer to compile but that's because it doing so much more than GCC; Apple e.g. ran with GCC until Xcode 4.1.

Go's C integration could be so much simpler; it's supported by default with Clang module maps http://clang.llvm.org/docs/Modules.html

Also there's a price to lay for cgo design http://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/
LLVM would have fixed all this.

No it was not a short sighted decision, It was designed precisely for that in mind, watch videos by Rob pike on the subject. Faster code? Funny, our code executes in nanoseconds and there are some pretty intense routines.

Re: compile link, Its not abandoned, its been done as a side project by another group of people, the same link I referred you to.

Re: Roach Link, obviously there is going to be some concerns when moving from a gc language to none gc. But still cgo performs very well. And yes, LLVM would have most likely fixed, but they didn't go that route, due to the concerns you mentioned already, so yeah its a moot point.

 

[[)roi(]]

No it was not a short sighted decision, It was designed precisely for that in mind, watch videos by Rob pike on the subject. Faster code? Funny, our code executes in nanoseconds and there are some pretty intense routines.

Re: compile link, Its not abandoned, its been done as a side project by another group of people, the same link I referred you to.

Re: Roach Link, obviously there is going to be some concerns when moving from a gc language to none gc. But still cgo performs very well. And yes, LLVM would have most likely fixed, but they didn't go that route, due to the concerns you mentioned already, so yeah its a moot point.

Faster code I was referring to is important in Systems Programming (Operating Systems, Languages, Device Drivers, etc.).
Never been a fan of GC, been burnt far too often by its unpredictability, but with Go it does seem like Google trying to substantially minimise its overhead, 1.5 target is 10ms latency, which is remarkable. For day to day stuff 10ms is great, but not so for lower level system stuff: there 10ms is a massive delay, but I guess they'll stick to C++ for that bit.

Still confused by their choice of staying on GCC, especially if you consider Google's active role in the LLVM project, for example: https://twitter.com/jckarter/status/667456209482420224. Who knows maybe it's a case of not now.

Nevertheless Go's a great language, would be very happy if Google decided to replace Java with it.

 

[semaphore]

Never been a fan of GC, been burnt far too often by its unpredictability, but with Go it does seem like Google trying to substantially minimise its overhead, 1.5 target is 10ms latency, which is remarkable. For day to day stuff 10ms is great, but not so for lower level system stuff: there 10ms is a massive delay, but I guess they'll stick to C++ for that bit.

I assume you're referring to GC pauses? That being the 10 ? If so its less than that.

https://talks.golang.org/2015/go-gc.pdf

We're using the latest golang at the office and we have not picked up any issues with GC pauses.

Still confused by their choice of staying on GCC, especially if you consider Google's active role in the LLVM project, for example: https://twitter.com/jckarter/status/667456209482420224. Who knows maybe it's a case of not now.

You do not need gcc to build go, you can build the entire compiler for go 1.5 using go 1.4.

https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNAfepWy2yhPUBs96FGV28/edit

Faster code I was referring to is important in Systems Programming (Operating Systems, Languages, Device Drivers, etc.).

Well to be quite frank, you would not be using golang to write device drivers and operating systems, so its a moot point as well.

As for language. Here write a compiler in go for your own language, you'll need to obviously write the ast for it.

http://noeffclue.blogspot.ca/2014/05/compiler-part-1-introduction-to-writing.html

 

[[)roi(]]

I assume you're referring to GC pauses? That being the 10 ? If so its less than that.

https://talks.golang.org/2015/go-gc.pdf

We're using the latest golang at the office and we have not picked up any issues with GC pauses.



You do not need gcc to build go, you can build the entire compiler for go 1.5 using go 1.4.

https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNAfepWy2yhPUBs96FGV28/edit



Well to be quite frank, you would not be using golang to write device drivers and operating systems, so its a moot point as well.

As for language. Here write a compiler in go for your own language, you'll need to obviously write the ast for it.

http://noeffclue.blogspot.ca/2014/05/compiler-part-1-introduction-to-writing.html

Funny enough I was watching that exact presentation; phenominal improvements, overheads are still quite large, but quite typical for GC. Guess it's a give and take; need the extra resource to improve predicability. Still no where as horrid as C# or Java.

I certainly got the message (from the video) that they were aiming to get the latency down to rates that would make Go a viable alternative to C & C++ i.e. sounded like they have intentions to make Go a fully fledged System Programming language, and that would be cool.

See it supports function currying (that's cool); but haven't seen any support for Functional Programming: e.g. High order functions like Map, Flatmap, Zip2, Zip3, etc... Do you know if it exists?

Nevermind I found the reasons why it's not possible yet; Go doesn't support generics (not yet at least), and neither does it support operator overloading: not necessary for FP, but certainly allows aligning the constructs with e.g. Haskell

 

[semaphore]

Funny enough I was watching that exact presentation; phenominal improvements, overheads are still quite large, but quite typical for GC. Guess it's a give and take; need the extra resource to improve predicability. Still no where as horrid as C# or Java.

See it supports function currying (that's cool); but haven't seen any support for Functional Programming: e.g. High order functions like Map, Flatmap, Zip2, Zip3, etc... Do you know if it exists?

Well you wouldn't see functional support, because its not a functional programming language for starters. I have seen some flatmap implementations floating around, but never found the need for them. There is no generics in Go either, that was one of the bigger hurdles for me to come to accept, but eventually I got over it.

Here is something, but yeah if its not built in by the core team there is a reason.

http://blog.burntsushi.net/type-parametric-functions-golang/

 

[[)roi(]]

Well you wouldn't see functional support, because its not a functional programming language for starters. I have seen some flatmap implementations floating around, but never found the need for them. There is no generics in Go either, that was one of the bigger hurdles for me to come to accept, but eventually I got over it.

Here is something, but yeah if its not built in by the core team there is a reason.

http://blog.burntsushi.net/type-parametric-functions-golang/

Thanks for that; whew implementation a bit long winded, but that's primarily the jumping around with reflection re lack of generics and prototyping constraints.

Edit: Also saw another implementation of map; whew performance re use of reflection takes a big hit: Apparently X 100 time slower than a for loop (I wouldn't use it). That's the difference with Haskell and Swift, High order functions are just as fast if not faster than standard for loop (re scope containment and lazy evaluation means the compiler is able to apply a lot of optimization)

The reason there's no use for flatmap and map comes down to the fact that Go is not a functional programming language (not yet anyway). For example: Alterations would need to be made to collection types i.e. to turn them into full fledged monads & it'll need generics

Since learning Haskell and more recently Swift I just can't ever imagine how I programmed without this stuff. Anyway it seems intriguing and easy enough to learn, probably will tackle it in the coming months.

 

[semaphore]

Thanks for that; whew implementation a bit long winded, but that's primarily the jumping around with reflection re lack of generics and prototyping constraints.

The reason there's no use for flatmap and map comes down to the fact that Go is not a functional programming language (not yet anyway). For example: Alterations would need to be made to collection types i.e. to turn them into full fledged monads

Since learning Haskell and more recently Swift I just can ever imagine how I programmed without this stuff. Anyway it seems intriguing and easy enough to learn, probably will tackle it in the coming months.

My functional background is mostly Scala and now recently Rust. As for making Go functional, very unlikely (http://talks.golang.org/2012/splash.article). One thing that is amazing about Go is goroutines, they're cheap and the communication via channels. Is utterly moist.

func main() {
     finished := make(chan bool)

     go func() {
          println("this makes me moist")
          done <- true
     }()

     println("my moistness has dried up")
     <-done 
}

 

[[)roi(]]

My functional background is mostly Scala and now recently Rust. As for making Go functional, very unlikely (http://talks.golang.org/2012/splash.article). One thing that is amazing about Go is goroutines, they're cheap and the communication via channels. Is utterly moist.

func main() {
     finished := make(chan bool)

     go func() {
          println("this makes me moist")
          done <- true
     }()

     println("my moistness has dried up")
     <-done 
}

Yip that's cool; Couple of Swift projects doing the rounds on github with a similar implementation; They're ok, but no where as powerful as Goroutines. Swift's Inventor (Chris Lattner), has however committed to implementing fully fledged goroutines after V3 timeline (after September 2016).

Edit: here's about the best swift implementation of goroutines so far