Is it too early for 'real' cross-platform iOS & Android development?

[mi...@eggheadgames.com]

I'm fascinated by F# and it's potential for mobile development on iOS and Android.

My company creates niche puzzle apps for iOS and Android (Play & Amazon). Currently we use the Java-based libGDX framework (essentially an OpenGL wrapper), but I'm looking ahead to something more maintainable and are really drawn to the F# language and Xamarin cross-platform support & ecosystem.

Am I too early?

Looking around, I found proof that it's possible, but few examples that had all the pieces needed. Having been through this, I know the devil is in the details, and the details include:

• phone-sized / tablet screen size detection, rotation detection, pixel density
  
• can display rich text on an area of the screen (e.g. for an on-screen html-based help file, or markdown or similar)
• can read data files from the app's assets, can write and read new status files
• works reliably with the OS-provided pop-up keyboard to capture user input
• has event reporting and stack crash logging to a 3rd party service, e.g. Splunk > Mint
• can communicate with an http[s] web server to fetch and post a file in the background
• has in-app purchase support for at least non-consumables, with price display (including Amazon IAP)
• integrates Facebook enough to:
  
  • allow integrated login if the user has FB on their device
  • trigger the FB "invite a friend" overlay
• has some native UI (e.g. navbar with iOS back & corresponding Android back-arrow support)
• supports a "graphic screen area" where something like OpenGL can be used
• mostly core/shared code

Does anything jump out as "He's dreaming!" ?   Or stupid or wrong?   (We could easily get sidetracked into a discussion about "how much should be native?". I'll try and sidestep that by noting that in my current apps, about 99.5% of the code is shared between iOS & Andoid. I've recreated some basic elements like navbars, dialog boxes & similar and draw them on the OpenGL window. Fonts create some memory management issues, but apart from that it all works well enough, because they're game-like apps and can get away with not being purely native).

I'll happily spend some company money to build a "template app" that does these things, and then place it into the public domain (or MIT license or similar) for others to use and improve.  (Although I've been programming on and off for 30 years in multiple languages, I haven't used F# yet, nor done any serious coding in a functional language, so I need a running start to keep the timeframe reasonable!)  Experience suggests that tooling/integration/similar issues will be at least 50-80% of the battle, not the code itself.  (Looking at the survey I'm a little scared that so few people are using OSX - it's effectively impossible to do iOS development without that. And how are 20% running Macs but 85% running VS2012+?  But I digress, and libGDX has some of the same problems).

I'd like to know if:

1. this sounds feasible yet, or if I'm too early
   
2. if this is interesting to others in the F# community (or perhaps mobile is swimming upstream in the F# river)
3. someone is interested in building this as a paid task
   

Thanks in advance for your patience with this Noob!

cheers, Michael @ EggheadGames.com

[Daniel Fabian]

For our F# -> GPU compiler we made a few samples that run on Windows, Mac OS X and Linux, including CUDA computation combined with OpenGL rendering without change. That said, there are definitely some painful parts with trying to have a cross-platform (multiple IDEs, I mean) solution. The F# compiler itself is probably the least of your problems. Some issues you might encounter during setting up the project with Xamarin. I am not quite sure of the state of the refactoring support on Xamarin for F#, but I'd guess it is behind VS. As for Xamarin mobile tools; I have no idea, didn't deal with that.

--
--
To post, send email to fsharp-o...@googlegroups.com
To unsubscribe, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource
---
You received this message because you are subscribed to the Google Groups "F# Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensou...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Fabian]

oh and btw, as for build tool chain, I'd definitely look into FAKE and paket.

[James Moore]

I suppose it depends on what you mean by 'too early' - we shipped our first app using F# + Xamarin on iOS last year - https://itunes.apple.com/us/app/switchvox-softphone/id905124827?mt=8 (completely uninteresting if you don't have a Switchvox phone system to attach to, FYI) - and I don't think we were even close to the first shipping F# app on iOS.

From your list of details, though, I think think there's a bit of misunderstanding of what Xamarin is doing.  When you're using Xamarin, you're making calls to native toolkit code; there's not a shared UI layer.  You're using 100% native code, you're just doing it from F# instead of Java or Objective C.  The names are changed to look more like dotnet names, but it's eventually calling into Android/iOS native code.  My day today was spent hooking up standard Android RecyclerViews to dotnet IObservables fed by F# mailbox agents, for example.

(Well, there is something called Xamarin Forms that's trying to be a cross-platform UI layer, but it's entirely optional - we're not using it for anything.)

--

James Moore
ja...@restphone.com
http://blog.restphone.com/
http://www.linkedin.com/in/jamesmmooreiv

[mi...@eggheadgames.com]

On Thursday, April 23, 2015 at 10:34:48 PM UTC-7, James Moore wrote:

From your list of details, though, I think think there's a bit of misunderstanding of what Xamarin is doing.  When you're using Xamarin, you're making calls to native toolkit code; there's not a shared UI layer.  You're using 100% native code, you're just doing it from F# instead of Java or Objective C.  The names are changed to look more like dotnet names, but it's eventually calling into Android/iOS native code.

Thanks James, I had half-figured out that this was the case. That's very similar to my current cross-platform Java codebase. Everything is drawn using the OpenGL layer provided by both Android and iOS and the libGDX library wraps other native pieces in a common interface (everything from file IO to screen size & density detection to rotation detection to playing sounds). As I write that list off the top of my head, and based on what you're saying, I realize that there would be a bunch of stuff like that needed!

From your response and reading around, it sounds like it's fairly feasible to build a native app (as you've done congrats!), but it might be pushing the envelope to go cross-platform with a lot of shared code -- even if sticking to only graphics via OpenGL.  However, if there are a few people interested in pushing that envelope together, it could get interesting!

cheers, Michael

[Mark Rathwell]

You also might want to take a look at MonoGame [1] and CocosSharp [2] game frameworks.  MonoGame is an open source replacement for the XNA framework, is actively developed and is fairly similar to LibGDX.  CocosSharp is a port of the Cocos2D variants (Cocos2D, Cocos2D-x) built on top of MonoGame.  Both integrate well with Xamarin, and I believe they have starter tutorials for both on their site, not sure how old they are though.  I've never tried, but you should be able to use both with F#.  A quick Google search yielded this sample [3].

Overall Xamarin is nice, but has its quirks.  I haven't used it in about 5 months, but the last project I used it with literally every upgrade broke my app in some way.  A lot of issues like that but overall pretty nice.

[1] http://www.monogame.net/

[2] https://github.com/mono/CocosSharp/wiki

[3] http://jmgomez.me/hello-cocossharp-from-fsharp/

--

[Andy Dent]

As I said over in the Xamarin forums and with more detail in email to Michael:

I'm very interested in this project as I think it's an interesting direction and aligned with the tools I'm using for my messaging startup. I'm doing a rich interactive layer with Cocos2D-X and trying to do everything else in F#.

I'm doing the GUI using Xamarin Forms where possible and native platform UI if forced to, for things like management screens and lists of contacts.

I have a very heavy schedule leading up to WWDC and will be in SF from 6th to 19th June (I live in Perth, Western Australia)

Most of my time between now and then will be working in F# doing the backend work, some UI and completing the integration with Cocos2D-X. I had already intended to release some samples to the community once this was done.

I evaluated MonoGame over a year ago and considered CocosSharp again quite recently. I rejected CocosSharp after an exchange on the Xamarin forums made it clear that I would have to wait to make direct use of OpenGL shaders and I didn't feel happy with the extra layers involved "as a small caveat, keep in mind that as CocosSharp is built upon MonoGame, your shaders would need to be first written in HLSL and then the underlying MonoGame content tools would generate a GLSL version of your custom shaders in the cases where you were targeting iOS/Android devices."

Ironically, that's the opposite of what's happened in Cocos2D-X. They cleaned up the model dramatically and made it very clean, modern C++11 then did a deal with Microsoft. For iOS and Android, Cocos2D-X works natively in OpenGL. For Windows Phone, Microsoft helped them by contributing with the ANGLE project to have OpenGL shaders compile to DirectX. MS Dev relations have been explicit about supporting third-party game engines being very important.

So, Cocos2D-X is more native on iOS and Android.

Whilst I have some test devices, I'm not promising to deliver our product or this sample on Windows Phone but will know more in a couple of months if any dragons encountered.