Regarding announced iPhone support

The Apple licences texts state that one shall use C++ or Objective-C and the XCode tools, without any other intermediate language or virtual machine. The future MoSync version with iPhone support will generate an XCode project written in both C++ and Objective-C, in order to respect Apple's licences.
Regarding the UI, a native UI framework is in development and will be included asap in the MoSync SDK, which means that the look-and-feel of each supported platform will be respected, including iPhone.
I hope this answers your question, and feel free to ask more if you need.
Cheers,
Romain

I'm a little curious of the native UI framework. Would I have to specify the looks of every UI component for every platform myself or will this be taken care of by the MoSync SDK automagically?

This will be handled automagically

Hi.

Any ETA for the UI framework?

Also, would it be interchangeably via MAUI? Meaning, can I start working on MAUI, and then switch to the new UI framework?

Thanks.

Hi, yes you should be able to start with MAUI, and the build process for MAUI will replace the each MAUI control with its native equivalent.

Sorry to drag up an old topic..

If the visuals of a program are all unique pictures (as it quite common in games I think), and the only MAUI components used are layouts, it is still necessary to switch over to using NativeUI to satisfy the Apple T&Cs?

Many thanks,

Felix

Its never really possible to try and predict what will get through and what won't, but I wouldn't expect to have any problems in this instance.

There are no apps that _have_ to use native UI, especially not immersive games. Games are usually best made using either the simple maDrawX() functions, OpenGL or the Framebuffer API.

But when it comes to apps with traditional user interfaces, including various lists, buttons, navigation etc, it's probably a very good idea to use native UI, unless you manage to provide a really superior experience with your own UI code. However, in my experience, despite being a graphics programmer of old who used to enjoy developing 3d engines and UI systems, it's usually not worth the hassle It's better to make use of the stuff that Apple has spent enormous resources on polishing and perfecting, and settle for customizing it!

Thank you for your answers! I'm still in the process of writing my first app

Given my app is entirely 2D (mostly composed of images), is there likely to be any significant performance differences between the various methods of drawing? I am using less than 20 sprites, and the only time that frames are required to be rendered quickly is when one of the widgets (and never more than one) is being dragged and following the user's touch.

I have been under the impression that OpenGL ES was only necessary for 3D drawing, and up till now I have been using the MAUI system for its useful contains() function!

Yeah, definitely go for OpenGL ES, in my opinion. Even if it feels like an overkill at this point, the experience you will get will help you in the future if you decide to make more complicated games. Better to learn it now with a simple game.

I kind of concur with Iraklis. If you use MAUI, or even the underlying maDrawImage() etc functions, the rendering is often happening in software, not taking advantage of graphics hardware. This might lead to less-than-spectacular performance for a game. However, to be pragmatic, you should just test it on actual devices. If it's fast enough, it's fast enough