Google provides an API so that you can use one set of game services cross-platform on iOS and Android:
I’m wondering - how tough is this to get working in Oxygene? Are there any roadblocks? I haven’t gotten there yet, but cross-platform games is something in my plan for using Oxygene. As I haven’t used Oxygene at all with iOS, I can’t tell if this is easy or impossible or something in-between.
Should be smooth sailing; just run the library thru FxGen and use it.
Thanks, Marc!
If some code distributer for iOS as a static library, all is fine. If code distributed as .framework, you should build small XCode project to recompile it as a static library! Not a big deal.
Not sure I really get what you’re trying to say.
It’s just my horrible English! 
Some parts of google’s code can be distributed as .framework stuff! Oxygene can not use .frameworks for iOS (only OSX or use core SDK via frameworks for iOS). Actually .framework is a package with dynamically linked library plus some headers. So it can not be linked with iOS app, because iOS did not allow to use dynamic binding except for base SDK stuff. So you need to make some static library from framework (see comment in end of FXGen article in wiki).
I appreciate your explaining more. And please, no smiley face since your English is FAR better than my Spanish-of-a-five-year-old. 
So just to be sure, this is the wiki article you mean:
http://www.elementswiki.com/en/Importing_an_Objective-C_Library_for_Use_with_Oxygene_for_Cocoa
Reading that and your comment, you are saying I’d have to create an Xcode static library project that just contained the .framework stuff. I’d then link that library into my Oxygene-created application. Does that sound right?
I wonder when “We are planning to add full support for consuming third party and custom frameworks for your OS X applications, in a near future update” stop being “near future”. Hopefully before I need to use this stuff.
Yes, you got the point.
One minor note: if some component for iOS is distributed in form on pure sources (.h + .m), and in readme you see that you should “just copy sources to your project” - this is another case when you need to start Xcode and make static library project!
Actually I ll be happier when all this stuff can be automated for Oxygene)
Yeah, I know they don’t have infinite time but I agree. Especially since iOS is such a big platform for them to target (it’s not like we’re talking Windows Phone or something). The more steps you have to put between typing your code up in Oxygene and running it on your iDevice, the more likely people are going to decide Oxygene is a leaky abstraction.
note that this is for OS X only. (non-SDK) frameworks are not supported on iOS, at all. By Apple. ie you cant use em.
So Oxygene/RO C# is cut out of the loop when it comes to mobile development and these technologies?
Maybe I just don’t understand what you are trying to say.
Using dynamic-linked code is forbidden on iOS by Apple - the only thing you can link dynamically is SDK. Same for Oxygene/ROC#.
Framework is a way to package dynamically-linked code, so if RO will make frameworks work with Oxygene/ROC#, it will be OSX only.
No?
What i’m saying is that Apple does not support .frameworks for iOS development. you cannot build an iOS app that links to and embeds-inside-the-.app a .framework. That’s true whether you are using Xcode, or Elements, or anything else. Your iOS application must be a single binary inside the .app bundle, so you can only use static libraries — ie .a files. [that is aside from the core os .frameworks of course, such as UIKit, which are on the device, and not embedded in your application.
Now, some iOS components come as a .framework, but thats really just a trick to make it easier to use from Xcode. It’s not a real framework, somewhere inside there is a static library (.a) and header files (.h) that can be used form Elements like any other static library.
By contrast, on OS X, you can use custom .frameworks, which are essentially .dylibs in a special package, and just embed those .frameworks inside your .app. That scenario we don’t currently support in Elements (because it’s pretty rarely used these days, and most our users focus on iOS, it has not been a priority). The workaround here is to rebuild the code from the .framework as a static library (.a), but we are looking to properly support this feature eventually.
I hope this makes sense.
I feel like I’m getting some of the little chunks, but the confusing part is the big picture. Google is building this library so people can use it on iOS game development with Xcode. So people can use it with Xcode just fine, right? That’s where I get confused. Why can people use it with Xcode but apparently I can’t with Oxygene. Maybe you were going off onto a tangent and weren’t talking about the Google API anymore?
who says you can’t use it with Oxygene? you should be able to, if it’s an iOS static library (which is has to be, to use it form Xcode, too).
I am now utterly confused.
By what part?
By your mention of “note that this is for OS only. (non-SDK) frameworks are not supported on iOS, at all. By Apple. ie you cant use em.” Were you talking about something other than anything I’d posted about (i.e. the Google Play Game Services)? I thought it was supposed to somehow be apropos of that. I’m still wondering if the “We are planning to add full support for consuming third party and custom frameworks for your OS X applications, in a near future update” statement will apply to this one.
only if you’re building Mac apps where you wanna use third party frameworks.
All iOS libraries are static libraries (even if disguised as .frameworks), so they’ll work with our current support for importing static libraries.
Ugh, how did I miss the “OS X”? I think it didn’t help me figure it out when you left out the “X” above (“this is for OS only”). I think my brain autocorrected your statement to “for iOS only”.