5 ms·

Having been building a decent size app (tens of thousands of lines) in Xamarin this really reflects our experience. One particular point is that the memory mana

Having been building a decent size app (tens of thousands of lines) in Xamarin this really reflects our experience. One particular point is that the memory management is fairly complex under the covers with bridged objects and multiple memory management mechanisms working in parallel, this occasionally rears its head. Another important point is they do provide a single automation test framework that targets both platforms. If I was starting the app again I'd be very conflicted whether to use Xamarin vs native, though ReactNative looks very interesting too and doesn't have the complexity of running the full .net stack.

mwcampbell 12y ago
I wonder if RubyMotion is much better when it comes to memory management. According to the website, RubyMotion objects are platform native objects (ObjC objects for iOS/Mac, java objects for Android), so each platform's native memory management scheme applies, rather than having two GC's or GC plus reference counting. I'd probably use RubyMotion for an upcoming project at work if it had a port to WinRT for Windows universal apps.
- badlogic 12y ago
  Judging by the docs [1], RubyMotion does indeed not seem to use a GC on iOS but instead relies on ref counting, reusing auto-release pools. That means cyclic refs are an issue. You have to explicitely use weak references throughout your code. They are not on Android, where RubyMotion uses the Dalivk/ART GC. So, your cross-platform Ruby code has to deal with two different types of memory management systems. I'm not sure this qualifies as a better option to what Xamarin provides. [1] http://www.rubymotion.com/developers/guides/manuals/cocoa/runtime/ http://www.rubymotion.com/developers/guides/manuals/cocoa/ru...
  - mwcampbell 12y ago
    Doesn't seem like a problem to me. The occasional weak reference to break cycles wouldn't hurt anything on Android, would it?
    - badlogic 12y ago
      I guess not. But it's going to be tough to use normal Ruby gems on iOs that aren't aware of the ref counting.
- candl 12y ago
  Here's a recent extensive benchmark against popular cross-platform toolkits: https://medium.com/@harrycheung/cross-platform-mobile-performance-testing-d0454f5cd4e9 https://medium.com/@harrycheung/cross-platform-mobile-perfor... (including memory usage)

mwcampbell 12y ago

I wonder if RubyMotion is much better when it comes to memory management. According to the website, RubyMotion objects are platform native objects (ObjC objects for iOS/Mac, java objects for Android), so each platform's native memory management scheme applies, rather than having two GC's or GC plus reference counting. I'd probably use RubyMotion for an upcoming project at work if it had a port to WinRT for Windows universal apps.

badlogic 12y ago
Judging by the docs [1], RubyMotion does indeed not seem to use a GC on iOS but instead relies on ref counting, reusing auto-release pools. That means cyclic refs are an issue. You have to explicitely use weak references throughout your code. They are not on Android, where RubyMotion uses the Dalivk/ART GC. So, your cross-platform Ruby code has to deal with two different types of memory management systems. I'm not sure this qualifies as a better option to what Xamarin provides. [1] http://www.rubymotion.com/developers/guides/manuals/cocoa/runtime/ http://www.rubymotion.com/developers/guides/manuals/cocoa/ru...
- mwcampbell 12y ago
  Doesn't seem like a problem to me. The occasional weak reference to break cycles wouldn't hurt anything on Android, would it?
  - badlogic 12y ago
    I guess not. But it's going to be tough to use normal Ruby gems on iOs that aren't aware of the ref counting.
candl 12y ago
Here's a recent extensive benchmark against popular cross-platform toolkits: https://medium.com/@harrycheung/cross-platform-mobile-performance-testing-d0454f5cd4e9 https://medium.com/@harrycheung/cross-platform-mobile-perfor... (including memory usage)